[design] Standing policies — let the Lead keep repos true instead of reporting that they aren't

[serge-ivo]

Design ticket — for assessment before implementation. Same treatment as #279.

The observation

The Coder Lead now observes well. Verified against the repos on 2026-08-06: branch, dirty-file
counts, run timings and outcomes were all exactly right, and it volunteered the flags unprompted
("FAS and FGS both have uncommitted working tree changes").

But it only ever acts when asked. A real session looks like:

"Give me an update on all of the agents that report to you."
"Focus on FAS platform. Can you clean it up?"
"Okay, next agent."

Every one of those is the user doing the supervising. And the state being reported — a two-day-old
fix sitting untracked, a repo parked on a merged feature branch, three uncommitted files — is
exactly the state a manager would simply fix.

This is the only proposal on the board that reduces the operator's workload rather than adding
a surface to check.

The primitive: a policy keeps something TRUE. A goal makes something HAPPEN.

That distinction is the whole design, and it is what stops this becoming "an agent that does
whatever it feels like on a timer".

Goal (delegate_goal, today)	"fix issue #36" — one-shot, user-initiated, arbitrary
Policy (proposed)	"this repo stays on its default branch with a clean tree" — standing, recurring, restorative

A policy may only restore a declared invariant. It may never decide what to build. "Fix bugs" is
not a policy; it is a goal, and it stays a goal.

Closed vocabulary, not free text

A policy is chosen from a registry, the same way connectors, pipeline steps, behaviour fields and
(proposed) stats sources are:

repo.on_default_branch      violation → report | open PR | switch back
repo.tree_clean             violation → branch + commit + push, or report
repo.no_stale_pr(days)      violation → chase | report
repo.builds                 violation → report  (never auto-fix: that is a goal)

Free-form policy text would hand an agent an open-ended standing instruction to act on real repos
unattended. Every other extension point in this platform is a closed, reviewed vocabulary; there is
no reason for the one that acts on its own schedule to be the exception.

Boundaries, all of which already exist

• Irreversibility → the per-repo merge policy ([safety] Nothing decides whether an agent may merge to main — three unattended merges already happened #314). A tree_clean policy under pr commits
  and opens a PR; under none it commits and stops. The policy does not get its own merge rights.
• Spend → the delegation budget ([coordination] Autonomous work budget — bound spend across every unattended entry point #184), unchanged — a policy run is a delegated run.
• Concurrency → the single-flight claim (claimDelivery / runDueTriggers / claimSessionDriver)
  so a policy cannot start a second run on a repo already being worked.
• Escalation → when a policy cannot be satisfied (merge conflict, failing tests), raise a
  needs_human board item. That status and column already exist; retrying forever does not become
  an option.

Observe-first is not optional

A new policy starts in observe and must be explicitly promoted to act. It reports what it
would have done, on the board, for as long as the user wants.

Without this the feature's first act is a surprise commit at 3am, which is exactly the reaction
#314 exists to prevent — three unattended merges that nobody chose and nobody saw. Earning the
promotion with a week of accurate observations is cheap; losing trust on day one is not.

Do not build a second scheduler

Triggers already do cron → action (runDueTriggers, per-minute, with an atomic claim). A policy is
a trigger whose action is evaluate a condition against observed state, and act only on violation.

Strongly prefer extending that over a parallel sweep. A second scheduler would be a second set of
claim semantics, retry rules and failure reporting to keep consistent — and the delivery outbox
(#239) is the standing evidence of how subtle that gets.

Visibility is the acceptance criterion

Every autonomous action lands on the board and in the run log, attributed to the policy that
caused it. "Why is there a new branch?" must be answerable without reading a diff.

This is the lesson of #314: three merges happened, correctly, on instruction — and were invisible
until someone read a run detail string days later.

Open questions for assessment

1. Scope: per-repo, per-agent, or a fleet default on the Lead with per-repo overrides? Fleet
   default is less to configure and more to get wrong.
2. Cadence: evaluate on a schedule, or only after a run finishes (when state actually changed)?
   The second is cheaper and more precise; the first catches drift caused outside the platform.
3. Who owns the policy — the subscriber, or may the agent propose one? If the latter, it should
   be an offer, on the same reasoning as [design] Agent-mediated transfer — "transfer me to that agent", seamlessly, in hands-free #279's user-requested-vs-agent-initiated split.
4. Does a policy violation belong on the subordinate's board or the Lead's? The work happens
   on the subordinate; the responsibility is the Lead's.

[serge-ivo]

Decision (owner, 2026-08-07): responsibility sits with the SUBORDINATE

"Responsibility is on subordinate, he drives the terminal."

Settles open question 4, and it is the right cut — it follows the platform's own ownership model
rather than the org chart. The subordinate owns the repo (surfaceOptions.coding.repos: "single",
and #255 made that ownership explicit in its prompt), and it is the only thing with a Pilot and an
engine. The Lead cannot touch a terminal; it delegates. Responsibility should sit where the
capability is.

What this settles beyond question 4

A violation is a board item on the subordinate. No new board plumbing on the Lead, and a
needs_human escalation lands where a human would actually go to fix it — the repo's own agent,
next to its runs and its terminal. The Lead already sees subordinate board state through
subordinate_status, so it observes without owning.

The Lead's role stays exactly what it is: observe, report, delegate. It does not accumulate a
work queue of other agents' problems, which would have made it a second place to look for the same
information.

The consequence worth noticing: policies do not need a Lead at all

If the subordinate owns the invariant, then the subordinate evaluates it — on its own schedule, not
because a supervisor poked it. Which means a standalone Repo Coder with no Lead can keep its own
repo tidy.

That is a better shape than the ticket as filed:

• Supervision becomes an observer of policies, not a prerequisite for them. A user with one
  Coder and no Lead gets the feature.
• It removes a dependency between two subsystems that do not otherwise need each other.
• It matches how every other per-instance concern already works — behaviour, settings, triggers,
  board columns are all properties of the instance, not of who supervises it.

This also narrows question 2 (cadence): it is the subordinate's own scheduled evaluation, via
the existing trigger machinery on that instance. Not a Lead-driven sweep across the fleet.

What is still open

Question 1 (scope) becomes: policy declared per-repo on the subordinate — with, optionally, a
fleet default on the Lead that subordinates inherit and may override. That is the same resolution
shape as behaviour (creator default < subscriber override) and the proposed stats schema, so it is
familiar rather than novel. Worth deciding whether the inherited default is wanted at all in v1, or
whether four explicit per-repo policies is simpler than an inheritance chain nobody asked for.

Question 3 (who may set one) is unchanged: subscriber sets, agent may offer — the
user-requested-vs-agent-initiated split from #279.

[serge-ivo]

Assessment: the primitive is right; three of the four boundaries it leans on do not hold, and the vocabulary has to be closed at the hands, not at the name

Design deliverable, same treatment as #279. The policy-vs-goal distinction is the correct primitive
and I would keep it exactly as stated. But I tested the four things the ticket leans on for safety,
and three of them are not there. The version of this that can ship safely is materially smaller
than the one described — in particular, the policy the ticket wants most (repo.tree_clean) is the
one that can do the least.

---

What I tested, and what it showed

1. Repo state is only observable through a live runner. There is no cloud path.

repoStateForInstance returns null the moment getBoundRunnerConn fails
(lib/repo-state.ts:166-184), and subordinate_status only probes ids where
connectivity.canWork && connectivity.requiresRunner (lib/connectors/supervision.ts:221-225). The
read itself is one relay RPC to the owner's machine — callRunner(conn, "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/coding/git", {cmd:"status"})
(repo-state.ts:153). Nothing reads tree state from D1, from GitHub, or from a cache.

Consequences the ticket should absorb:

• A scheduled sweep observes nothing while the machine is off, and the code is careful that
  absence reads as unknown, never as clean (repo-state.ts:136-139). So a policy must treat
  unknown as "do nothing", which means its observability is conditional on the very machine whose
  state it is policing.
• That weakens the ticket's own argument for question 2. "A schedule catches drift caused outside the
  platform" is only true while pags up is running — and when it is, a post-run evaluation is
  nearly as timely and strictly cheaper.

2. There is no write-capable git path on the runner at all

// packages/browser-runner/src/coding/inspect.ts:40
export type GitCmd = "status" | "diff" | "diff-stat" | "log" | "ls-files";

Fixed argv per enum, execFileSync with no shell, paths only after a literal --, resolveInside
blocking traversal and symlink escape (inspect.ts:20-37, 42-63, 90-100). The design rule is stated
in coding-inspect.ts:11-12: reads belong to the Co-pilot, writes belong to the Engine.

So a policy that acts has exactly two possible actuators:

(a) A new closed write surface on the runner — checkout <branch>, add -A, commit -m, each a
fixed argv, same shape as the read whitelist.

(b) Delegate a goal to the subordinate's Pilot → Engine — which is what "a policy run is a
delegated run" implies.

(b) breaks the ticket's own central promise. "A policy may only restore a declared invariant. It
may never decide what to build" is guaranteed only if the actuator is constrained. Handing "commit
the working tree" to a general coding agent means the vocabulary is closed at the name of the
policy and wide open at the hands — and those hands are claude --dangerously-skip-permissions
on the owner's own machine (stated at coding-authority.ts:41-44). That is precisely "an agent that
does whatever it feels like on a timer", arrived at through the front door.

This is the most important recommendation in this comment: close the vocabulary at the actuator.
A policy remediation must be a fixed argv the runner executes, or it is not a policy.

3. The merge-authority boundary is, for the median repo, no boundary

// lib/coding-authority.ts:78
export const DEFAULT_MERGE_POLICY: MergePolicy = "merge";
// :129-130
case "merge": return new Set();   // forbids nothing

The ticket says "a tree_clean policy under pr commits and opens a PR; under none it commits and
stops." But a repo that has set nothing resolves to merge, where the forbidden set is empty
(resolveMergePolicy, :112-114; repo column default '' = inherit, 0091:11).

And even under a restrictive policy, none of the three layers is a hard gate — the module says so at
:25-44:

layer	what it is	limit
authorityInstruction	text in the Pilot's prompt	advisory
screenInstruction	regex over the Pilot's outgoing English, only on action.kind === "message" (coding-loop.ts:150)	heuristic; only on the Pilot→Engine path
unauthorizedActs	observed tool_use acts checked after the fact	ACT_REPORTING_ENGINES = new Set(["claude"]) (:260) — sees nothing on Codex or Grok

Conclusion: a standing policy cannot inherit its irreversibility bound from #314. It has to carry
its own. An unattended policy must run under an explicit ceiling that defaults to restrictive,
independent of DEFAULT_MERGE_POLICY. #314's reason for its permissive default — do not silently
change behaviour owners already rely on — does not apply to a feature that does not exist yet.

4. "A policy is a trigger plus a scope" is not expressible today — and the outbox would hurt it

Two concrete gaps and one active hazard:

• Triggers have no condition. filter is not in TRIGGER_CONFIG_KEYS (trigger-config.ts:26-48)
  and parseConfig is a reconstruct-from-scratch whitelist (triggers.ts:176-216), so an unlisted
  key is silently dropped. The matchesWhere predicate language (steps.ts:248-289) exists only on
  connection config (connections.ts:113-149). A trigger cannot express "only when X".
• No trigger action can touch a repo. The closed union is create_task | add_knowledge | log_event | sync_connector | run_pipeline | insert_record | run_browse (trigger-types.ts:22).
  None of them reads or writes a checkout; run_browse starts a browser task, and pipeline steps are
  the steps.ts vocabulary, which never drives a runner.
• A failed trigger is replayed with a stale payload. dispatchTrigger enqueues failures into the
  shared delivery outbox (triggers.ts:410-421), retried on [60, 300, 900, 3600, 10800] seconds
  with MAX_ATTEMPTS = 5 (connection-deliveries.ts:23-34). That ladder is correct for its purpose —
  waiting out someone else's outage — and wrong for a policy: an action that failed at 09:00
  would be retried at 12:00 against a repo whose state has since changed. A policy that misses a tick
  must re-observe next tick, never replay.

So the honest scope is: a policy needs one new fact source, one new trigger action, a
condition on triggers, and — if it acts — a new closed runner write surface. Four things, not
"a trigger plus a scope". That is still much cheaper than a second scheduler, and I agree with the
ticket's core instruction: do not build one.

5. Two precedents that make the observe half nearly free — and one that is exactly right

• runDeployWatch (lib/deploy-watch.ts) is already a bounded per-minute sweep with
  DEPLOY_WATCH_BATCH = 20 and, critically, decideDeployNotification's rule that first sight of a
  repo must never notify. Copy that rule verbatim in spirit: on the deploy after this ships, every
  repo in the fleet already has a stale branch or a dirty tree, and a policy that acted on whatever it
  found first would open a burst of branches nobody asked for.
• upsertWorkCard (lib/work-card.ts:16) already writes a board card to any instance cloud-side,
  no runner, which is how recordAuthorityViolations lands a needs_human card
  (coding-authority.ts:355-369). Question 4's escalation half is therefore free.
• run_browse already models the right non-failure: a 503 (runner offline) or 409 (run in progress)
  is recorded as {skipped: true, reason} and is not a failure (triggers.ts:333-359), so it
  never enters the retry ladder. That is precisely the semantics "cannot observe right now" needs.

---

How a standing policy avoids re-litigating #276 — and where it cannot

lib/repo-state.ts:11-16 writes the #276 decision into the code:

THE POLICY THIS ENCODES: a delegated run starts from wherever the repo was left, and is TOLD
where that is. It is deliberately not "reset to the default branch first". Git cannot distinguish
leftover junk from a fix somebody still wants… So: report it everywhere, refuse nothing, discard
nothing.

The escape is narrow and it is real: #276 refused DISCARDING. It did not refuse PRESERVING. A
remediation that only ever adds — create a branch, commit the tree onto it — destroys nothing and
is reversible locally. That is a categorically different act from checkout . / reset --hard /
clean -fd / stash drop, and the platform already names those: KNOWN_KINDS in engine-acts.ts
classifies reset.hard, clean and file.delete as irreversible. So the policy vocabulary should
be defined as the complement of that set, and the destructive half should not exist at all — not
"gated", not "behind a setting", absent, so nothing can reach it.

But "push" is not additive, and that is the ticket's blind spot

Committing is local and reversible. Pushing is a disclosure that cannot be recalled. An unattended
add -A && commit && push runs over an unreviewed working tree — and it is unreviewed by
construction, because if anyone had reviewed it, it would not be dirty. A .env, a key dump, a
scratch file with a customer's data: once pushed, it is in a remote's history and the remediation is
a credential rotation, not a revert.

So my recommendation is narrower than the ticket's: repo.tree_clean may commit locally. It may
not push. That leaves the tree clean, the work preserved, the history local and recoverable, and a
board card telling the human there is a branch waiting for them. It is genuinely useful and it is
much less than "branch + commit + push".

Two shipped instructions currently say the opposite, and would have to change

This is not a prompt-tuning detail; it is the platform contradicting itself in two places at once:

• the supervisor legend — "never instruct an agent to clear a working tree you did not put there"
  (connectors/supervision.ts:262);
• the run-start injection into goal.specialInstructions — "You did not create this state. Do NOT
  revert, stash, reset or discard anything you did not write yourself…" (workflows/coding-session.ts:522-537).

Whatever ships must edit both to draw the preserve/discard line explicitly, or the Lead will be told
to do a thing it is simultaneously told never to do. Worth naming as a deliverable rather than
discovering it in review.

---

The policy the ticket under-rates, and an ordering constraint it misses

repo.on_default_branch is the one that can safely act. git checkout <configured|trunk> loses
nothing and is undone by git checkout -. But it has a hard precondition: git carries uncommitted
changes across a checkout, so switching branches on a dirty tree silently relocates someone's work
onto the trunk — the exact harm #276 exists to prevent, arrived at from a different direction.

So: never switch branches while the tree is dirty, and prefer requiring the current branch to be
pushed as well. Which means the two policies interact, and turning several on at once is not a
neutral convenience. That is a direct argument against question 1's fleet default.

Two more corrections to the proposed registry:

• repo.no_stale_pr(days) has no data source today. There is no pull-request observation anywhere
  in the API worker — github-issues.ts is issues-only and deploy-watch polls Actions. Worse,
  parseBranchHeader parses and deliberately discards the ahead/behind counts
  (repo-state.ts:100), so even "unpushed commits" is not currently a fact the platform holds. This
  policy is a new connector read, not a new policy.
• repo.builds is the only one that works while the machine is off, because Actions runs and
  issues are both readable cloud-side via the GitHub App (deploy-watch.ts, coding-inspect.ts:78-100).
  The ticket has it as report-only, which I agree with — and that combination makes it the cheapest
  first ship and the best way to earn the observe→act promotion, since it can accumulate a week of
  accurate observations without depending on anyone's laptop.

---

The open questions

1. Scope. Per-repo, and no fleet default in v1. Fleet default is "less to configure and more
to get wrong", and the tree_clean/on_default_branch interaction above is exactly the way it gets it
wrong. Four explicit per-repo settings beat an inheritance chain nobody asked for. If a default is
added later, it should follow #314's three-level resolver shape, which already exists.

2. Cadence. After a run finishes, plus a bounded sweep restricted to instances with a live
relay. The post-run hook already exists — coding-session.ts:598-621 reads repo state at run end
and already upserts a repo-dirty-${repoId} / coding.uncommitted card, closing it when the tree is
clean. That is the observe half of tree_clean, shipped. The sweep is deploy-watch-shaped. Note
the cron grammar's floor: normalizeSchedule enforces a 5-minute minimum and rejects */N
(triggers.ts:67-98), so "evaluate every minute" is not on the table anyway.

3. Who owns it. Subscriber sets; agent may offer — #279's rule, and the reason is sharper
here than it was there. A policy is the one thing that acts with no human in the loop, so an agent
that can create one converts a single prompt injection into a standing, recurring capability. The
Lead reads agent-authored subordinate summaries and untrusted repo text every turn. That is the
difference between a bad turn and a persistent one.

4. Whose board. Already settled (the subordinate's), and the machinery is free — upsertWorkCard
writes cross-instance cloud-side today.

One question the ticket does not ask: whose money? DEFAULT_LIMITS is {costMicros: 5_000_000, delegations: 50, maxDepth: 4} per tree and DAILY_CEILING_MICROS is 50_000_000 across the account
per 24h (delegation-budget.ts:38-42, delegation-budget-store.ts:83-84), with the ceiling derived
from the owner's own p95 spend × 25 runs (openBudget). If policy runs draw on the same pool as
interactive delegation, a quiet night of policy work can exhaust the budget the human needs in the
morning — and the failure will look like "the Lead refused to delegate", not like "the policies spent
it". A policy needs its own budget, or at minimum its own sub-limit.

---

What I would not build

1. tree_clean that pushes. Commit locally, or observe only. The credential-disclosure argument
   above is not hypothetical and it is not recoverable.
2. Any remediation whose actuator is the Engine or the Pilot. If the hands are a general coding
   agent, the closed vocabulary is decorative.
3. Any destructive verb at all — checkout ., reset --hard, clean -fd, stash drop, branch
   deletion. Not gated: absent from the vocabulary, so no setting, prompt or objective can reach
   them.
4. A fleet default in v1 (question 1), for the interaction reason above.
5. repo.builds acting. Agreed with the ticket; noting that this makes it report-only and the
   only runner-independent one, which is a feature.
6. A second scheduler, a second claim, a second retry policy. Agreed with the ticket, and
   additionally: a policy must opt out of the existing delivery outbox ladder. Reusing it looks
   like reuse and is actually a correctness bug, because it replays a stale observation up to
   ~4h20m later.
7. Free-text policies. Agreed with the ticket, no argument to add.
8. Promotion from observe to act by anything other than an explicit owner action, per policy
   per repo. Not a settings value an agent can write, and not fleet-wide.

Suggested slices

1. Observe only. repo.builds (cloud-side, works with the machine off) + on_default_branch +
   tree_clean observation, landing as board cards on the subordinate, attributed to the policy.
   Most of tree_clean's observation already exists at coding-session.ts:598-621. No acting, no
   promotion path yet.
2. on_default_branch acting, via a new fixed-argv runner command, guarded on a clean tree and a
   pushed branch, behind an explicit per-repo promotion.
3. tree_clean committing locally, if 1 and 2 have earned it. Never pushing, never discarding.

Leaving this open — design-assessed, not implemented. The observe half is close to free and I
would ship slice 1 without waiting for the rest of the design to settle; it is the part that is
unambiguously correct and it is the only way to earn the trust the acting half needs.

[serge-ivo]

Second assessment: the policy is already composable today, and that is the argument against building it as described

There is an assessment on this ticket from 2026-08-07. I re-tested its four claims against main
at db8a2af and three of them still hold verbatim — the runner has no write-capable git path,
DEFAULT_MERGE_POLICY still forbids nothing, and a failed trigger is still replayed with a stale
payload. I am not going to re-argue those; they are correct and the evidence has not moved.

Two things HAVE moved, and they point in opposite directions.

#374 landed this morning (db8a2af). It is the reason one of the previous assessment's harder
conclusions has softened: a gated autonomous actuator now exists where before there was only an
ungated one. The Coding tab's Loop no longer drives the engine from the browser past the budget, the
driver claim and merge authority — it presses the same POST /loop everything else does. §2 works
through what that does and does not buy a policy.

And I found the thing nobody has said yet: a standing policy — cron, observation, condition,
delegated remediation, human gate — is expressible today, in configuration, with no new code.
Not approximately. Literally, through the existing pipeline runner. Which means this ticket is not
asking for a primitive. It is asking for a constraint layer over one that already shipped and is
currently unconstrained, and that is a better ticket than the one filed.

---

1. Is "policy" a new primitive? No — and it is worse than "nobody has composed it yet"

A pipeline step dispatches through runRegistryTool:

// lib/pipeline.ts:389
const registryCtx = { env: ctx.env, userId: ctx.userId, instanceId: ctx.instanceId, traceId: ctx.traceId };
// :400, :408
const r = await runRegistryTool(step.tool, registryCtx, input);

and supervision is a registry connector like any other (connectors/registry.ts:88-97). So
subordinate_status (connectors/supervision.ts:440) and delegate_goal (:484, scope: "write")
are pipeline-callable tool steps. subordinate_status already carries repo state — branch,
dirty, changedFiles, note — because repoStateForInstances is attached at
connectors/supervision.ts:277-282. filter/matchesWhere is a dotted-path predicate over that
(steps.ts:248-289). create_ticket (tool-registry.ts:291) raises the human gate, and approving
it runs the declared action (actionable-ticket.ts:32, TICKET_ACTIONS).

So this pipeline, attached with PUT /v1/instances/:id/pipelines/:name and fired by a cron trigger
with action: "run_pipeline", IS the ticket:

subordinate_status  →  filter [{field:"repo.dirty", op:"truthy"}]  →  slice  →  forEach delegate_goal

The mechanism is there. Every property the ticket says makes it safe is not. The objective
handed to delegate_goal is a free string in a JSON blob, so the vocabulary is closed at nothing.
There is no observe stage and no promotion. There is no attribution: agent_loop_runs.delegated_by
records the Lead instance (loop-drivers.ts:98, :223), so a policy-caused run is indistinguishable
from the Lead deciding, and "why is there a new branch?" — the ticket's own acceptance criterion —
is unanswerable. And there is no idempotence: the pipeline fires every tick for as long as the
condition holds.

That reframes the ask. The deliverable is not a scheduler and not an actuator. It is the
constraint layer. Naming that is worth more than any single policy in the registry.

2. What a timer-initiated action bypasses TODAY — the gate-by-gate answer

Start from what is no longer true. Until this morning the Coding tab's Loop bypassed all three of
budget, driver claim and merge authority, because the browser drove it. db8a2af moved it onto
POST /loop, so it goes through loopDriverFor(caps) → codingDriver, which opens the budget
(routes/tools.ts:791), claims the driver (loop-drivers.ts:193), opens the agent_loop_runs row
not best-effort (:214-233), and resolves merge authority in the Pilot. That is the shape a
policy's remediation should take: not a new actuator, the existing one, entered by the one door that
carries the gates.

Against the pipeline path, the gates split cleanly:

capabilities.tools — BYPASSED. toolNamesFor is applied at agent-think.ts:657,
instance-tool-policy.ts:123 and supervision-capability.ts:35. It is not applied in
pipeline.ts. A stored pipeline can call any tool in the registry, declared or not.

The per-tree delegation budget (#184) — BYPASSED. RegistryToolCtx.budgetId exists
(connectors/types.ts:55) and delegate_goal forwards ctx.budgetId ?? undefined, but
pipeline.ts:389 never sets it — so delegateToInstance falls to openBudget(...)
(delegate-instance.ts:72) and each tick opens a fresh pool. The bound designed to stop a tree
running away is inert on precisely the path a policy would use. What is left is the account circuit
breaker in reserve — $50 charged or 250M tokens per rolling 24h
(delegation-budget-store.ts:214-236).

The driver claim (#208) — NOT bypassed. claimSessionDriver (loop-drivers.ts:193) 409s tick
N+1 while tick N is still running. This one holds, and it is the only thing between the loop below
and a pile-up.

Merge authority (#314) — not bypassed, but mostly not present. A repo that has set nothing
resolves to merge, whose forbidden set is empty (coding-authority.ts:78, :129-130), and layer 3
sees nothing on Codex or Grok (ACT_REPORTING_ENGINES, :260).

Write consent (#90) — NOT bypassed, and weaker than it looks. delegate_goal is write-scoped,
so it needs supervision write consent (tool-registry.ts:398-414). But consent is a standing
per-instance row (connector-consent.ts:14-24), not a per-call decision. One click covers every
3am tick forever.

And the hole worth stating plainly: tmux_run_command (connectors/tmux.ts:79, scope: "write")
is a registry tool that types an arbitrary command line into a session on the owner's machine. It is
pipeline-reachable. Today reaching it needs three deliberate owner acts — author the pipeline, grant
tmux write consent, create the cron — so it is an escape hatch rather than a defect. But it means
"an agent that does whatever it feels like on a timer" is already a supported configuration,
and this feature's real job is to be the safe version of something that already exists in an unsafe
one.

3. The concrete failure, and it is a loop, not a merge

The previous assessment's push argument is right and I will not repeat it. Here is the one it did
not reach, which I think is the more likely first incident.

A tree_clean policy that remediates by delegating fights two shipped strings. Every coding run
gets this injected verbatim into goal.specialInstructions:

// workflows/coding-session.ts:586
`… You did not create this state. Do NOT revert, stash, reset or discard anything you did not
 write yourself. If your objective needs a clean tree or a different branch, say so and stop
 rather than clearing it.`

and the Lead's own tool description says "never instruct an agent to clear a working tree you did
not put there" (connectors/supervision.ts:355).

So the run is told to clean the tree and told not to touch it. The likely outcome is not a bad
commit — it is a refusal, correctly, followed by the tree still being dirty, followed by the
next tick. normalizeSchedule floors cron at 5 minutes (triggers.ts:81, :99), so that is 288
delegated runs a day, each opening a fresh budget pool per §2, each burning BYOK Claude on the Pilot
and engine tokens, until the account circuit breaker trips. And then the failure the human sees at
9am is "the Lead refused to delegate" — the breaker firing on the work they actually wanted,
with nothing anywhere saying a policy spent it. That is the whole incident: no irreversible act, no
merge, no push, and the account is still dead.

Fixing it needs three things the ticket does not list: edit both of those strings to draw the
preserve/discard line explicitly (a deliverable, not a detail); make a policy's remediation
idempotent against its own previous attempt, so "I tried this and it did not work" suppresses
the next tick rather than reissuing it; and give a policy its own budget or sub-limit so it cannot
eat the interactive one.

On the acting half more generally I reach the same place the first assessment did, by a different
route: repo.tree_clean may commit locally at most, and I would rather it did not act at all in v1.
An unattended add -A runs over a tree that is unreviewed by construction — if anyone had
reviewed it, it would not be dirty — and the only thing between it and a credential is a
.gitignore that a half-finished change is exactly the kind of change not to have updated yet.

repo.on_default_branch is the one that can act safely, with a hard precondition: git carries
uncommitted changes across a checkout, so switching branches on a dirty tree silently relocates
someone's work onto the trunk — #276's harm reached from the other side. Never act on branch while
dirty. Which means the two policies interact, and turning several on at once is not the neutral
convenience a fleet default implies.

4. The smallest honest implementation

Slice 1 — observe, evaluated where the state is already read. No scheduler, no new actuator, no
new trigger action, no new runner surface.

tree_clean's observation is already shipped: coding-session.ts:666-693 reads repo state at run
end and upserts a stable repo-dirty-${repoId} card, closing it when the tree comes back clean, and
upsertWorkCard (work-card.ts) writes cross-instance cloud-side with no runner. What is missing is
a per-repo declaration of which invariants this repo claims, and attribution — the card and the
event saying which policy raised it. That is a column, a resolver, and a card title.

Cadence: evaluate at run end (the hook above) plus a deploy-watch-shaped bounded sweep restricted
to instances with a live relay. Copy decideDeployNotification's first-sight rule verbatim in
spirit: on the deploy after this ships every repo in the fleet is already dirty or off-trunk, and a
policy acting on what it finds first would open a burst of work nobody asked for. Note also that
observation is conditional on the machine being up — repoStateForInstance returns null the
moment getBoundRunnerConn fails (repo-state.ts:170-174), and subordinate_status only probes
where canWork && requiresRunner (connectors/supervision.ts:281). Unknown must read as do
nothing, never as clean; repo-state.ts:136-139 already takes that care and a policy must inherit
it. run_browse's {skipped:true, reason} (triggers.ts:352-359) is the right precedent for
"cannot observe right now" — it is explicitly not a failure and never enters the retry ladder.

Slice 2 — on_default_branch acting, if slice 1 earns it. A new closed write surface on the
runner: fixed argv, same shape as gitArgv (packages/browser-runner/src/coding/inspect.ts:40-63),
in a separate module so the read enum stays read-only. Guarded on a clean tree and a pushed branch,
behind an explicit per-repo promotion that only a human can set.

The cost nobody has priced: slice 2 ships in the runner, which means a CLI version bump and a
publish, and until a user upgrades their global @proagentstore/cli the policy silently cannot act.
That is the stale-runner problem, and a policy that looks enabled and does nothing on an old runner
is the failure mode the trigger-config validator exists to prevent, arrived at from a different
direction. Budget for a version floor and an honest "your runner is too old" message, or do not ship
slice 2.

Slice 3 — tree_clean committing locally. I would not schedule this. If it ever ships it never
pushes and never discards.

Two corrections to the proposed registry that still stand: repo.no_stale_pr(days) has no data
source — nothing in the API worker observes pull requests, and parseBranchHeader deliberately
discards the ahead/behind counts (repo-state.ts:100), so even "unpushed commits" is not a fact the
platform holds. And repo.builds is the only one that works with the machine off, which makes it
the cheapest first ship and the best way to accumulate a week of accurate observations without
depending on anyone's laptop.

5. What I would not build

1. A policy trigger action, or a policy scheduler. Both already exist as run_pipeline + cron,
   and a second one would be a second claim, a second retry ladder and a second failure report.
2. A remediation whose actuator is a free-text objective. That is the whole feature undone: the
   vocabulary closed at the name and wide open at the hands, which are
   claude --dangerously-skip-permissions on the owner's machine (coding-authority.ts:41-44).
3. Any destructive verb at all — checkout ., reset --hard, clean -fd, stash drop, branch
   deletion. Absent from the vocabulary, not gated: no setting, prompt or objective can reach what
   does not exist. engine-acts.ts:52-80 already names that set; define the policy vocabulary as
   its complement.
4. A fleet default in v1. The tree_clean/on_default_branch interaction in §3 is exactly how
   an inheritance chain nobody asked for gets it wrong.
5. Reuse of the delivery outbox for a policy dispatch. triggers.ts:425-437 enqueues a failed
   dispatch onto the shared ladder — [60, 300, 900, 3600, 10800]s, MAX_ATTEMPTS 5
   (connection-deliveries.ts:23-34). That ladder is correct for waiting out someone else's outage
   and wrong for a policy: a 09:00 observation replayed at 12:00 against a repo that has since
   changed. A policy that misses a tick re-observes next tick and never replays.
6. Promotion from observe to act by anything other than an explicit human action, per policy per
   repo. Not a settings value an agent can write. A policy is the one thing that acts with nobody
   present, so an agent that can create or promote one converts a single prompt injection into a
   standing capability.

Recommendation

Build the reduced version: the constraint layer, observe-only, evaluated where the state is already
read. Decline the acting half of tree_clean outright — not defer, decline; it is the one policy
that cannot be made safe with the actuators that exist, and saying so now is cheaper than a slice 3
that lingers on the board looking half-promised. Keep on_default_branch acting as a real later
slice with the clean-tree precondition and the runner-write surface priced honestly.

Where a maintainer could reasonably disagree with me: if you read §1 as "it already works, ship
the pipeline and write a doc", that is a defensible call — it costs nothing and it is true today.
I think it is wrong because the properties that make it a policy rather than a cron job that
delegates are exactly the ones composition does not give you, and a documented recipe would spread
the unconstrained version faster than the constrained one could catch up. But that is a judgement
about which risk is worse, not a fact, and the code supports both readings.

And the one thing I would add that the ticket does not ask for: attribution first, before any
policy exists. Nothing today can answer "which policy caused this run" — delegated_by records an
instance, not a cause. Without it, the ticket's own acceptance criterion is unmet even for the
observe-only slice, and with it, the observe slice becomes genuinely useful on its own.

---

Two things I noticed in passing that are not this ticket's, filed here so they are not lost: the
capabilities.tools allowlist is not enforced on pipeline steps (pipeline.ts:400/:408 call
runRegistryTool with no toolNamesFor gate), and PipelineRunCtx (pipeline.ts:364-370) carries
no budgetId though RegistryToolCtx declares one (connectors/types.ts:55), so a pipeline's
delegate_goal opens a fresh per-tree pool on every call. Both may be intended; neither is written
down anywhere I could find.

Leaving this open — design-assessed, not implemented.

[serge-ivo]

Shipped: the constraint layer, observe-only — cce72cc

Slice 1 of the second assessment's own recommendation, and nothing beyond it. A repo now declares
which invariants it claims; they are evaluated at the run-end hook that already reads its state;
a violation lands as a board card attributed to the policy that raised it.

• lib/repo-policies.ts — the closed registry. RepoPolicyMode is off | observe; act is
  absent rather than gated, so no setting, prompt or objective can reach one.
• Migration 0106 — coding_repos.policies, validated by a whitelist over both key and value
  before it is written, so the column cannot hold a policy the code does not implement.
• PUT /v1/instances/:id/coding/repos/:repoId takes policies. An unrecognised name is refused,
  not dropped — a policy that silently never applies is indistinguishable from one that is holding.
• Evaluation in workflows/coding-session.ts's existing repo-state-end step.

No actuator, no scheduler, no new trigger action, no runner write surface. The acting half is
not deferred-with-a-plan, it is declined for tree_clean: an unattended add -A runs over a tree
that is unreviewed by construction, and the only hands available are
claude --dangerously-skip-permissions on the owner's machine. on_default_branch acting remains a
real later slice with its clean-tree precondition and a CLI version floor priced honestly.

Behaviour on the day it deploys: unchanged

• repo.tree_clean defaults to observe — [bug] Delegated runs leave repos on feature branches and with uncommitted edits — and subordinate_status reports neither #276's card ships unconditionally today and defaulting
  it off would have retired a shipped capability. It keeps that card's id (repo-dirty-<repoId>),
  type, title and subtitle, so cards open in production right now still close.
• repo.on_default_branch defaults to off. A checkout parked on a feature branch is frequently
  intended — [bug] Delegated runs leave repos on feature branches and with uncommitted edits — and subordinate_status reports neither #276 says so outright — and claiming it is opt-in rather than a fleet-wide burst.
• While nothing claims the branch invariant, the dirty card still carries the branch clause exactly
  as it does now. Once something claims it, the fact moves to that policy's card instead of being
  reported twice.
• Unknown is not held. An unobserved policy leaves whatever card exists exactly where it is. The
  one case that resolves without an observation is a policy the repo has stopped claiming: its
  card is retired whether or not the machine answered, because turning a policy off with the laptop
  shut is exactly when someone does it.

Verified live in production

PUT …/coding/repos/:id  {"policies":{"repo.fix_everything":"observe"}}
  → 400 unknown policy `repo.fix_everything` — known policies: repo.tree_clean, repo.on_default_branch
PUT …/coding/repos/:id  {"policies":{"repo.tree_clean":"act"}}
  → 400 policy `repo.tree_clean` must be one of: off, observe
PUT …/coding/repos/:id  {"policies":{"repo.tree_clean":"observe"}}  → 200; GET reads it back
PUT …/coding/repos/:id  {"policies":{}}                             → 200; GET reads `null`

(on fws/platform, using the policy whose stored value and default are identical, then reverted —
the row is back to policies: null.)

Plus typecheck (11 projects), 6760 tests (35 new), biome, design tokens, agents allowlist, qa
config, file size, migrations --require-history, test isolation, docs drift; CI green including
Playwright. Deploy API Worker green with 0106 applied.

On the motivation, corrected

The live stale-verdict evidence this was handed as its concrete defect does not survive:
stores/fds reading ready is correct (~/dev/stores is itself a work tree, and #405 chose
git rev-parse over a .git test on purpose), and pas/platform reading error is #440 — a
transport failure stored as the repo's clone status, plus the missing clone_checked_at. Nothing
here writes clone_status, so the two do not race for that column and this does not duplicate that
fix.

The ticket's own observation never depended on that evidence and still stands: the Lead reports repo
state accurately and only ever acts when asked.

Not built — named so none of it reads as an oversight

1. A console control. The declaration is an API field today; the defaults are what make the
   feature land without one. Worth a follow-up on the repo settings sheet, beside merge authority.
2. A fleet default. The tree_clean/on_default_branch interaction is exactly how an
   inheritance chain nobody asked for gets it wrong.
3. repo.builds (needs a cloud-side Actions read) and repo.no_stale_pr (has no data source
   at all — parseBranchHeader deliberately discards ahead/behind).
4. Anything acting, per above.

Leaving this open for the acting half and the console control. The observe half is done.

[serge-ivo]

Shipped: the acting half — c5d5f79 (hands) + dbf82e2 (brain)

Slice 2 of the second assessment's plan, to its letter: repo.on_default_branch can act, through a
fixed argv on the runner, on a clean tree only, behind an explicit per-repo human
promotion, with the CLI version floor priced honestly. repo.tree_clean acting stays
declined, not deferred.

The vocabulary is now closed at the HANDS, not at the name

packages/browser-runner/src/coding/repo-write.ts is a separate module with a one-member enum:
switch-branch → ["checkout", <validated branch>, "--"]. No commit, no push, no checkout ., no
reset, no clean, no stash — absent from the enum rather than gated, so no setting, prompt
or objective can reach one. inspect.ts's rule (reads belong to the Co-pilot, writes belong to the
Engine) keeps its read-only whitelist intact; this is the single deliberate exception, and the
assessment's central recommendation is what it implements: a policy remediation must be a fixed argv
the runner executes, or it is not a policy.

Three smaller decisions inside it:

• -- terminates the argv, so a branch sharing a name with a file cannot become a FILE checkout —
  which would discard work.
• The branch name passes a character allowlist first. execFile has no shell to escape, but git
  still reads a leading - as an option, and that is the one injection this argv shape is open to.
• The repo test is .git at this path, not git rev-parse --is-inside-work-tree — deliberately
  the opposite of [bug] A local repo is marked "ready" without anyone checking it exists — an empty checkout reports success, and the agent invents the code it cannot see #405's choice for the read side. rev-parse answers yes from a subdirectory, so a
  workdir sitting inside a larger checkout (~/dev/stores is one) would have its enclosing repo
  switched by a policy declared on something else.

Not enforced: "and the branch is pushed", which the assessment preferred. Leaving an unpushed
branch loses nothing — the commits stay on it and the printed undo returns to it — and requiring a
remote would make the policy inert on exactly the local-only branches it is most useful on.

tree_clean acting is refused at the door, with the reason

PUT …/coding/repos/:id {"policies":{"repo.tree_clean":"act"}}
  → 400 policy `repo.tree_clean` must be one of: off, observe — `repo.tree_clean` has no actuator:
        there is no way to satisfy it that does not decide, unattended, what happens to unreviewed work

A policy takes act only if it declares an actuator, and the error says why rather than listing
what it takes: "act is not in the list" reads as a gap somebody should close. Committing to a policy
branch was considered and rejected — it still decides that unreviewed work is now a commit, and the
human who has to undo it has to find it first.

Five outcomes, and only one of them may say the repo changed

#408's standard, because a write on somebody's real checkout deserves at least it. confirmed
requires the write to return and an independent read-only git status to agree — the write
reads HEAD back itself, but a card that says "done" on the writer's own account of its work is
exactly what #408 is about. unconfirmed / unsupported / refused / failed all leave the
violation card open and say the repo was not changed. A confirmed switch names the branch it came
from and prints git checkout <that branch>, which is this ticket's acceptance criterion — "why is
there a new branch?" answerable without reading a diff — and the act also lands in the run log as
agent_events coding/policy.act, so the answer survives someone closing the card.

Two refusals are decided in the cloud before anything is asked, and both are said on the card so
a policy that cannot fire is visible rather than silently inert: a dirty tree (git carries
uncommitted changes across a checkout, so acting would relocate the work #276 exists to preserve) and
a repo with no declared branch (off-trunk is judged against main/master, which is enough to
report and not enough to act — picking one would be inventing the target). The machine re-checks the
dirty rule for itself, because the observation is seconds old by the time the write lands.

Nothing was promoted, and an agent cannot promote anything

Both fallbacks are unchanged (tree_clean: observe, on_default_branch: off), so the deploy changed
no repo's behaviour. Promotion is per repo, per policy, through PUT …/coding/repos/:repoId, and
repo-policies.test.ts now asserts over the source that exactly one route accepts the field and
that no MCP tool constructs its path. That absence is the deliverable: a policy is the one thing that
acts with nobody present, so an agent able to promote one converts a single prompt injection into a
standing capability — and an invisible invariant is one new tool away from being undone.

Two more properties held on purpose:

• It never acts on a stale verdict. The trigger is a finding computed from a read taken moments
  earlier in the same run-end step; clone_status — which [bug] A repo has been marked broken for five days by a dropped WebSocket — a transport failure is stored as the repo's state, and no verdict is ever re-taken #440 showed can hold a five-day-old
  transport failure — is not consulted at all, and an unreadable checkout is unknown, which acts on
  nothing.
• It never replays, and it is not suppressed either. A "tick" here is the end of another run — a
  fresh observation of a repo something has just worked in — and the attempt is one local git call
  with no model spend, so it draws on no budget an interactive delegation needs. The comment asking
  for idempotency-against-its-own-last-attempt is answered by re-observation, not by a suppression
  window that would hide an invariant that still does not hold.

Verified in production

PUT …/coding/repos/:id {"policies":{"repo.tree_clean":"act"}}         → 400, with the no-actuator reason
PUT …/coding/repos/:id {"policies":{"repo.on_default_branch":"fix-it"}} → 400 must be one of: off, observe, act
PUT …/coding/repos/:id {"policies":{"repo.on_default_branch":"act"}}  → 200; GET reads it back
PUT …/coding/repos/:id {"policies":{}}                                → 200; GET reads `null`

(on fws/platform, then reverted — the row is back to policies: null.)

The actuator itself is NOT yet exercisable in production, and the reason is the one this slice
budgeted for: the connected machine reports runnerVersion: 0.4.47, and /coding/git-write ships
in 0.4.48 (published by CI on c5d5f79). Until that machine upgrades and restarts pags up, a
promoted policy reports unsupported — "this machine's runner has no switch-branch endpoint — CLI
0.4.48 or newer, then restart pags up" — rather than claiming success. That is the stale-runner
failure mode named in the assessment, behaving as designed. I did not promote a policy on a real
checkout to force an end-to-end run: switching a branch in somebody's live work tree is not a thing
to do unasked.

Local bar: typecheck (11 projects), 7526 tests (54 across the two policy suites, 20 of them new),
biome, design tokens, agents allowlist, qa config, file size (19506/19507, unchanged), migrations
--require-history, test isolation, docs drift. CI green on both commits; Deploy API Worker green.
Playwright not run — nothing here touches store/ or agents/coder/web beyond one openapi prose
block. No migration: the acting half is a new accepted value in a column 0106 already holds.

Still open, and deliberately

1. The console control. The declaration is still an API field; the defaults are what make it land
   without one. It belongs on the repo settings sheet beside merge authority — and the promotion
   control there has to be an explicit human toggle, not a value anything else can write.
2. repo.tree_clean acting — declined. Recorded as a decision so it stops reading as a gap.
3. repo.builds (needs a cloud-side Actions read) and repo.no_stale_pr (no data source at
   all — parseBranchHeader deliberately discards ahead/behind).
4. A fleet default. The tree_clean/on_default_branch interaction is exactly how an inheritance
   chain nobody asked for gets it wrong.