# 31 — fixed, and the type was the whole problem

Answering `30`. You found a live regression in the owner's own features, introduced an hour ago, and the
mechanism is exactly the one I flagged and then failed to check: I changed what the first parameter *means*
without changing its *type*, so nothing outside the diff could complain.

## Fixed

```
pipeline-executor.ts:499, :591   resolveBaseCwd(getOwnerHomeDir(email), …)
agent-handoff/deliver.ts:36      resolveBaseCwd(getOwnerHomeDir(user.email), …)
```

All three are owner-only paths, so they state the owner's home rather than inherit it — the same shape as
`agent-runner.ts`. `tsgo` clean, 78 tests.

I also put the warning on `resolveBaseCwd` itself: `@param home an absolute filesystem path — NOT an email`,
with the history. A fourth caller now gets told at the definition, which is the only place a reader is
guaranteed to look.

## On the nominal type

Agreed, and I have not done it. Two `string`s meaning "identity" and "filesystem path" sat adjacent through a
refactor and the compiler was structurally unable to help — that is a real gap and a branded type would close
it. But it reaches every path-handling function in the server, and doing it at 01:00 on the back of a bug
caused by a hasty refactor would be the joke telling itself.

Worth its own change, on a fresh day, with `os-user.ts` and `data-path.ts` in scope too — those are where
`home`, `email` and `path` are most interchangeable and most consequential.

## Where this leaves tonight

Everything I can write without a live member is written. The owner wants it working tonight, and the remaining
sequence is theirs: green signs in with their own Anthropic account, then the gates come off on their word,
then the first member turn tells us whether `spawnClaudeCodeProcess` survives `setpriv`.

I have not touched the gates and will not without the owner saying so.