iter pr.1: Boss-side known-debt addendum (iron law + agent-tool-wiring)

This commit is contained in:
2026-05-11 12:40:03 +02:00
parent b3e25f8b32
commit 5c17ef2efc
+40
View File
@@ -80,6 +80,46 @@ than a scope deviation:
lands and INDEX is updated, the agent's reading list naturally
picks up the pr.1 entry.
### Boss-side addendum
Two follow-ups surfaced during this dispatch that are not pr.1's
own scope but were exposed by being the first real run of the
or.1-orchestrator-agent. Both go to the post-pr.1 fix queue:
- **or.1 Iron-Law wording is wrong.** The orchestrator-agent's
Phase 0 Iron Law says `git switch -c iter/<iter_id> origin/main`,
which presupposes that the plan-commit is on `origin/main`. The
Boss does not push between plan-commit and dispatch, so the
branch is created without the plan file. The agent worked around
this by mid-flight ff-merging local `main` into `iter/pr.1`,
which got the right end-state but rationalised itself through a
"branch already exists" clause that was actually meant for repair
re-dispatch. Correct fix: `git switch -c iter/<iter_id> main`
(drop `origin/`). Iron Law's purpose is iter-isolation from main,
not push-state coupling. Touches
`skills/implement/agents/ailang-implement-orchestrator.md` Phase
0 and the corresponding mention in `skills/implement/SKILL.md`
if any. One-commit mini-fix iter (no plan template needed,
trivial-mechanical carve-out).
- **`Agent` tool not reaching the orchestrator-agent.** Frontmatter
declares `tools: Read, Edit, Write, Bash, Glob, Grep, Agent`, but
the dispatched orchestrator-agent reports `Agent` was not in its
actual tool set, forcing the degraded-mode execution described
in Summary. Root-cause investigation needed: either a Claude
Code restriction on nested-subagent dispatch, or a frontmatter
parsing detail, or a deferred-tool issue at the harness layer.
This blocks the entire or.1 design goal (Boss-context offload
via fresh-subagent-per-task isolation), so it dominates the
post-pr.1 queue. Not fixable by a doc edit; needs diagnosis
before a fix can be scoped.
- **Plan-template RED-check regex.** Task 4 Step 1 used
`\*\*\*` (three literal stars) where the file content has two
(`**…**` markdown bold). Three plan iterations have now hit
plan-template defects (or.1 Tasks 1/4/6/7, pr.1 Task 4) —
cumulative signal that the plan-template needs a small revision
pass before the next planner run, or the planner skill needs
a self-test step.
## Blocked detail
N/A — DONE.