friction(dev-team-orchestrator): gate inbox mishandled — does not park, and rm/overwrites the human's inbox file

[bronz3beard]

Summary

During a live L-sized run (email-verification flow task, Gemini 3.1 Pro,
Continue/MCP), the orchestrator mishandled the .dev-team/inbox.md gate channel
in two related ways. Both concern Phase 4 (Tech-Lead Interview at Gates) and the
treatment of the inbox as the human's channel.

Deviation 1 — Posts questions but does not park

Expected (Phase 4): When the orchestrator batches questions to
.dev-team/inbox.md, the lane should PARK at its gate and wait. Per the skill:
"If unanswered, the lane PARKS at its gate."

Observed: After writing two gate questions (a Cognito error-branching
research decision and a feature-flag decision), the orchestrator did NOT park.
It continued issuing Phase-0-style discovery commands
(find ... | xargs grep -l "getSignUpWithEmailPassword", etc.) instead of
halting to await answers. The human had to manually instruct it to stop
discovery and consume the inbox.

Deviation 2 — Destroys and rewrites the human's inbox file

Expected: The inbox is the human's channel. The human edits their answers
inline and saves. The orchestrator should READ the answers in place — it must
not delete or overwrite the human's saved file.

Observed: After the human saved their answers into .dev-team/inbox.md, the
orchestrator ran rm .dev-team/inbox.md and then recreated the file
(cat << 'EOF' > .dev-team/inbox.md) with its own paraphrased version of the
answers. The rewritten content was semantically equivalent, but:

• it destroyed the human's exact wording (risking loss of nuance the human
  intended — e.g. precise failure-screen copy),
• it is fragile: if the paraphrase step drops or alters a decision, the human's
  original intent is gone with no record,
• it treats a human-owned file as agent-writable, violating the channel
  contract.

Deviation 3 — Silently bypasses the reflexion plan gate on tool failure

Expected: For L/XL tasks the plan gate should be reflexion-hardened
(recommended for L, mandatory for XL). If the reflexion_loop tool fails, the
orchestrator should retry or PARK and ask the human whether to proceed with an
un-hardened plan — especially for high-risk (auth/payments) tasks.

Observed: The reflexion_loop MCP tool call failed/timed out. The
orchestrator responded by writing "Reflexion loop timed out. Bypassing
reflexion loop to proceed directly to manual planning and execution." into
.dev-team/inbox.md and continuing — silently skipping the plan-hardening gate
for a Risk-2 auth task, notifying rather than asking.

Proposed prevention: On reflexion_loop tool failure, the orchestrator must
NOT auto-bypass. It should retry once, and if still failing, PARK and ask the
human in the inbox whether to proceed un-hardened. Bypassing a quality gate
because a tool errored is a form of cognitive surrender the system exists to
prevent. For Risk-2+ tasks, un-hardened proceed requires explicit human
approval.

Additional note: the reflexion_loop MCP tool timed out twice in this run,
making the L-task plan gate effectively unavailable via MCP. The reflexion loop
has now shown instability across three surfaces (cloud runner, CLI, and now the
MCP tool). Root-cause the loop's reliability — this is the second core-feature
reliability gap (cf. the cost-tracking stub). Until fixed, L/XL plan hardening
via the tool can't be relied on, and the fallback must be a human plan-review
gate.

Deviation 4 (root cause) — reflexion_loop MCP tool is structurally too slow for a synchronous tool call

The reflexion_loop MCP handler (handleReflexionLoop) runs the FULL loop
synchronously in one tool call: engine.ts does up to maxRevisions+1 generate
calls + maxRevisions critique calls + 1 adjudicate = ~7 sequential LLM calls,
each 10-30s, with NO internal timeout/abort. IDE MCP clients impose a per-tool-
call timeout (~60-120s), so the client kills the call before the loop finishes.
This is why it times out via MCP but works via the CLI and cloud runner (which
have no short tool-call timeout).

Fix options: (a) make the MCP tool asynchronous — start the run, return a
run-id immediately, resume/poll via the existing resume machinery; or (b) run
ONE revision per MCP call and let the agent drive successive revisions across
calls. Until fixed, MCP-invoked plan hardening is unreliable by design; use the
CLI or cloud runner for reflexion, and a human plan-review gate as the IDE
fallback.

NOTE: two more items — "agent edits via generated regex patch.js scripts rather than reviewable direct edits (fragile, silent-failure-prone, no diff)" and "lane worktree/branch created silently; Lane Ledger not updated with worktree path, so the human can't tell where edits are landing." Both are real, both fit the orchestrator-hardening theme.

Impact

• Human cannot tell whether the run is waiting on them or still working (Dev. 1).
• Tokens wasted on continued discovery while the lane should be idle (Dev. 1).
• Human's authored gate answers are deleted and replaced by an agent paraphrase,
  with no preservation of the original (Dev. 2).
• Both undermine the "human appears only at gates" contract and the inbox as a
  trustworthy human channel.

Skill involved

.ai/skills/dev-team-orchestrator.md — Phase 4 (Tech-Lead Interview at Gates).
Also check the .agents/workflows/dev-team.md workflow copy for the same gaps.

Reproduction

1. Hand an L/XL task with a genuine open question (ambiguity = 2) to the
   dev-team-orchestrator in an IDE/MCP agent.
2. Let it batch questions to .dev-team/inbox.md.
3. Observe Deviation 1: it keeps running discovery/search commands instead of
   parking.
4. Fill in answers inline and save the file.
5. Observe Deviation 2: it rms the saved inbox and rewrites it with a
   paraphrase rather than reading the human's answers in place.

Rework count

1 gate — required manual intervention to stop discovery, and the human's saved
file was destroyed and rewritten.

Proposed prevention class

Skill hardening (Phase 4). Make two rules explicit:

1. Park is a hard stop. After writing questions to the inbox, the lane MUST
   stop all commands (no further searches, reads, or edits) and yield until the
   inbox answers are filled and the human signals continue. The park is an
   enforced halt, not advisory.
2. The inbox is read-only to the agent once populated. The orchestrator may
   CREATE the question block, but once the human has saved answers it must READ
   them in place and MUST NOT rm, overwrite, or rewrite .dev-team/inbox.md.
   If it needs a normalized copy for parsing, it should read into memory, never
   destroy the human's file. Preserve the human's authored answers verbatim.

This pairs with the Execution-Discipline / discovery-budget hardening already
drafted for this skill (the same run also exhibited unscoped-grep timeouts and
pre-sizing discovery churn). All three should land in the same
fix/orchestrator-guardrails PR.

Labels

friction