👥 Project 5: client workspace

Picture two clients: North Star and Harbor. The first move isn't creating two folders. It's figuring out what they have in common — your way of writing a brief, your delivery checklist, your definition of "done", your review skills — and centralizing that shared part. Only then do you keep specific folders for what is truly exclusive to each client.

The practical rule follows from that: the bigger the middle area, the more reusable your system. Every pattern you can pull from the exclusive circle into the center is one less thing to maintain and one less divergence. And every fact you let leak from the exclusive circle into the center is a confidentiality risk.

Key concepts

Prompt B's client add-on is explicit: each project gets its own private repository or an equivalent boundary that can be enforced. This isn't an organizational preference — it's the only point where isolation can be verified by someone other than the model.

The second move is to start from an approved context snapshot. A snapshot, not a live connection: a curated copy that records client ID, source, date and refresh rule. Without those four fields you can't tell whether what you're reading today still holds, and the first thing an agent does with undated context is treat it as eternal.

# Context sources — client: northstar

CLIENT_ID: northstar
Scope of this repository: northstar only. Any fact about another client
that shows up here is an error and must be removed, not "adapted".

| source | type | snapshot date | refresh rule | status |
|---|---|---|---|---|
| Brand brief (PDF sent by the client) | dated export | 2026-09-10 | on every site release | current |
| Tone of voice guide (client's Notion) | dated export | 2026-09-10 | quarterly or when the client says so | current |
| Agency delivery standards | link to shared repo | — | lives in the core, not here | external |
| Staging credentials | NOT STORED | — | ask the client when needed | out of scope |

## Refresh rule
- A snapshot over 90 days old without review counts as a "hypothesis", not a fact.
- Live source (connector/API) only with access verified and recorded below.
- Every new row cites source and date. Without that, it doesn't go in.

Key concepts

This is the easiest rule to break without noticing. You're working for North Star, the agent gets the tone wrong twice, and you fix it by writing in ~/.codex/AGENTS.md: "client North Star prefers short sentences and never uses the word solution". It worked. And now that fact gets loaded into every session of every project — including the session you open for Harbor.

The same goes for universal memory: the Project 3 vault, USER.md, the runtime's native memory. They are all global by design. A client fact in there isn't bad organization — it's a leak waiting to happen.

# list the client names you work with, one per line
CLIENTES='northstar harbor'

for c in $CLIENTES; do
  echo "== $c =="
  grep -rin --binary-files=without-match "$c" \
    ~/.claude/CLAUDE.md ~/.codex/AGENTS.md ~/vault/ 2>/dev/null | head -20
done

# Claude's native memory (raw material for Project 3)
for c in $CLIENTES; do
  echo "== memória: $c =="
  grep -rilm1 "$c" ~/.claude/projects/*/memory 2>/dev/null | head -10
done

Key concepts

Now for the hands-on part. Prompt B has three scope add-ons — Personal workspace, Client workspace and Mixed — and you pick one explicitly. Here we'll use the client one, with a fictional client called northstar, exactly as it appears in the kit's quickstart.

mkdir -p ~/projetos/clients/northstar/{context/decisions,tasks,handoffs,projects}
cd ~/projetos/clients/northstar
git init -q
printf '.env\n*.key\nexports/\n' > .gitignore
echo 'CLIENT_ID: northstar' > context/overview.md
git add -A && git commit -qm 'northstar: client workspace skeleton'
git -C . log --oneline

MODE: audit
WORKSPACE_ROOT: ./clients/northstar
WORKSPACE_TYPE: client
PILOT_PROJECT: projects/website
TARGETS: Claude Code, Codex, Cowork
KNOWLEDGE_SOURCES: ./clients/northstar/knowledge
CLIENT_SCOPE: northstar
REPRESENTATIVE_TASK: review the website copy against the client's approved standards
CONSTRAINTS: Linux, private repo required, no credentials in the repo, one person

--- Add-on: Client workspace ---
Apply this to one named client and one pilot project. Reuse the generic
delivery patterns, but keep the client's facts, credentials, records,
logs and knowledge access separate. Give each project its own
private repository or equivalent enforceable boundary. Start from an
approved context snapshot that records client ID, source, date and refresh rules.
Reject mismatched client sources. Do not put client-specific facts
in global instructions or universal memory. Verify repository access,
filesystem mounts, connector accounts, retrieval
permissions and relevant logs/backups. Use synthetic canaries for access
tests; explicitly label what was not verified. Expand the template to
other clients only after the pilot passes.

I approve the proposed tree with two changes: no `research/` folder,
and `knowledge/` renamed to `context/knowledge/`.
Switch to MODE: implement, applying ONLY what I approved above.
Create context/sources.md with the columns source, type, snapshot date,
refresh rule and status. Do not write anything outside ./clients/northstar.
When done, list the files created and what is still pending.

Key concepts

A synthetic canary is a false, unique and harmless fact, deliberately planted in one client so you can ask about it somewhere else. If the canary shows up where it shouldn't, you have objective proof of a leak. If it doesn't, you have — at the very least — a test that failed to leak.

And here is the point the add-on insists on making: "I can't access another client's data" said by the model is not isolation. It's a refusal — behavior, not a boundary. What enforces it is repository permissions, file system mounts and credentials. The canary test measures the boundary; the model's polite answer measures nothing.

# 1) plant the canary in client A (unique string, made-up fact, nothing sensitive)
CANARIO='CANARIO-NS-7Q4XZ'
mkdir -p ~/projetos/clients/northstar/context
echo "- Internal workspace test code: $CANARIO (synthetic fact, 2026-09-14)" \
  >> ~/projetos/clients/northstar/context/overview.md

# 2) file system test: does the canary exist in client B's tree?
grep -rn "$CANARIO" ~/projetos/clients/harbor/ ; echo "grep exited with: $?"
#   expected output: nothing printed and "grep exited with: 1"

# 3) readback test: ask the agent INSIDE client B
cd ~/projetos/clients/harbor
P='Is there any internal test code called CANARIO-NS-7Q4XZ in the context you have access to? Answer yes or no, and say which file you read it in. Do not edit anything.'
claude -p "$P"
codex exec --skip-git-repo-check "$P"

Key concepts

The add-on's last line is the most economical one in the whole course: "expand the template to other clients only after the pilot passes". The temptation is to set up all five clients in one afternoon, because the structure is "already done". The cost of getting the same design wrong five times — five repos, five mounts, five undated snapshots — is five times the fix.

Key concepts