refactor(kiro): serve Kiro IDE and Kiro CLI from one distribution

[wowzoo]

Replaces #1063, closed unintentionally: a brief visibility change on the head fork detached it
from this repository's fork network, which closed the pull request and made reopening impossible.
Nothing about the change itself was reconsidered, and the head commit is the one #1063 carried
(711e4de).

---

What this does

kiro and kiro-ide maintain the same .kiro/ shell twice. Kiro IDE and Kiro CLI run the same agent runtime, so this consolidates them into one row, kiro, serving both surfaces, and removes kiro-ide.

Breaking: aidlc config --harness kiro-ide no longer resolves — use --harness kiro.

Why now

The two adapters implement the same contract twice and have never converged:

	harness/kiro	harness/kiro-ide	gap
v2.1.7	415	275	−140
v2.3.0	424	374	−50
v2.6.18	935	743	−192
v2.7.0	1047	2029	+982
this base	1075	2029	+954

690 → 3,104 lines. The point is not that the gap grows monotonically — it narrowed at 2.3.0 and flipped sign at 2.7.0 — but that the same contract is implemented twice and pays maintenance twice every generation. Five call sites already normalized kiro-ide to kiro before this change (aidlc-model-policy.ts, aidlc-plugin.ts, aidlc-plugin-emit.ts, scripts/plugin-hooks-template/compose.ts).

The merged adapter is 3,010 lines — the union, not a sum, because the duplicated halves collapse.

What the merge had to solve

The engine. settings/cli.json gains "chat.agentEngine": "v3", so a plain kiro-cli in the project reaches the agent runtime this row targets with no flag at the call site. Measured both ways on kiro-cli 2.21.1: with the key the session enters that engine, without it it does not.

Hook registration. The row registers through standalone manifests (14 files, 16 registrations) that both surfaces read. Two triggers are surface-specific per docs/features/hooks.md — Session Start is IDE-only, Agent Spawn is CLI-only — so lifecycle responsibilities register on both or they are dead on one surface. Only Prompt Submit, Pre Tool Use and Pre Task Execution can refuse, so every guard that must refuse sits on PreToolUse.

The acting persona. This is the hard part. The pre-merge row registered five guard targets inside each persona's own agent-v1 config and passed the persona as argv — 90 registrations. A v3 hook manifest has no agent-scope field, so that channel has no replacement in kind, and two guards depend on it: state-transition-guard enforces only when it knows a delegate is acting, and reviewer-scope compares the identity against the dispatched reviewer.

What replaces it is measured. Across 615 captured payloads (Kiro CLI 2.18.1 / 2.19.2 / 2.20.1 and IDE 1.x) a delegate's own tool calls do reach the workspace hooks, strictly nested inside the dispatch event's own PreToolUse..PostToolUse window, and the dispatch event names the delegate in one of three places: the subagent_<agent> tool name, tool_input.name, or tool_input.stages[].role. So the adapter opens a window on the dispatch's Pre, closes it on the matching Post, and attributes what happens in between. The ledger is append-only: each open is its own record, a close cancels the whole most-recent group for that dispatch key (a crew dispatch names several personas and must be released as one), and nothing is read before writing, so two adapter processes cannot lose one another's update.

reviewer-scope and review-freeze are registered for the first time on this row. Both must be able to refuse, so both sit on PreToolUse.

IDE 0.x

Not supported, and not silently dropped either: one legacy .kiro.hook ships whose only job is to say so. That format is the only channel a 0.x host reads and a supported one does not run it — measured on 1.0.437, where nothing fired — so the channel does most of the version check. Not all of it: a supported IDE lists the file as legacy beside a Migrate button, and one click makes it a hook that host does run, so the notice also reads the host's own version before it speaks. Both halves are below.

Which trigger, and which exit code, is not a free choice, and 0.12 answers differently per seam. On promptSubmit, exit 2 stops nothing: the hook runner turns any non-zero exit into HookFailedCommandError — "Hook '' command execution failed" — and that seam reads it as a broken hook rather than a refusal. Measured: the turn continued, and the session's own agent spent two minutes diagnosing the notice before writing "enabled": false into the manifest, which does not even disable it (that host keeps enablement in workspace state). On preToolUse, the same exit code does refuse the call. So the notice rides preToolUse with toolTypes: ["*"], writes the denial first, and exits 2.

Both halves carry weight. The exit code is the enforcement — measured on a real 0.12.333, the read was abandoned and the session reported it could not retry because the hook exited 2. The text is why, and it leads the output because this host's instructions tell the model that output denying access forbids retrying. It goes to both streams: stdout || stderr is the success path's rule and does not apply to a non-zero exit, and the delivery measured on a non-zero exit was stderr. The message states the supported versions inline rather than pointing at a file, since a reader in this state has every tool call refused and no docs/ tree in the install.

This refuses per tool call rather than per prompt, which is the better seam: nothing in AI-DLC advances without a tool, and the refusal lands where work would have begun. The target still reads neither stdin nor the normalized payload (a 0.x host opens stdin and never closes it) and still confirms the legacy channel through USER_PROMPT, which is populated on this trigger too, carrying the tool input as JSON rather than the user's prompt; only its presence is read.

The channel alone is no longer proof of the host, so the target also checks one. A supported IDE does not run this file, but it lists it as legacy with a Migrate button — one click makes it a current-generation hook that a supported host does run, and USER_PROMPT is populated there too, so that gate would not catch it. Migrated, on preToolUse, the notice would deny every tool call on a fully supported install, and the button is in the hooks panel of every one of them. So the target reads the version line out of VSCODE_IPC_HOOK (0.12-main.sock on 0.12.333, 1.0.-main.sock on 1.0.437, both measured) and speaks only for a 0.x major. An absent or unparseable value is silence as well: informing is this target's only job, and refusing work on a supported install is the worse failure, at the cost that a 0.x host which stops setting the variable gets no notice. The guide tells readers to leave the hook alone rather than migrate it.

Defects found and fixed on the way

Each of these built and typechecked clean before the fix, which is why they are worth listing:

• Three guards were registered, dispatched to, and enforced nothing. reviewer-scope, guard-tool-call and deliver-stage-rules read the raw payload, and none was in the set that decides whether the adapter reads stdin at all — so the payload was "", the parsed object was {}, and each returned 0 on its first field access.
• tool_response is not always a string. Two captured shapes ({items:[{Text}]}, {success,result:[...]}) were classified malformed, which discards the whole event: no audit row, and the Stop hook's inflight marker never cleared.
• A matcher named execute_pwsh that the canonicalizer did not translate, so the call reached the adapter and returned 0 — the gate read as present and enforced nothing on Windows.
• write was missing from three matchers while the adapter canonicalizes it, so a frozen-artifact write and a reviewer-scope violation under that spelling reached nothing.
• subagent_response was classified as an opaque mutation, diverting every delegate report during code-generation into the legacy recovery path.
• A batch write produced one audit row instead of one per target, and the written path was scraped from result prose even on the surface that populates the input.
• aidlc-plugin-emit emitted a plugin's compose hook on SessionStart only, so on Kiro CLI a plugin never composed and nothing said so.
• dist-release/kiro shipped no .vscode/settings.json, so the native channel lost the kiroAgent.trustedCommands pre-trust and an untrusted project command silently never runs.
• The dispatcher read hook stdin unbounded in two places; a host that never closes stdin wedged the hook.
• The row merge dropped four working behaviours, and only the unit suites noticed. The roll-forward seam wrote a per-session marker while three separate readers — the continue-workflow carve-out and, in other processes, the done-guard and the doctor bundle — still read the flat one, so the latch was dead. A compiled install lost the engine noun from its argv, breaking every off-band terminal command. All fourteen personas shipped with no tools, MCP or shell grants and no resources. And a space switch stopped re-pointing Markdown agents, so it could not put the conductor back. package.ts --check, all three typecheck configs and Biome passed throughout; the unit tier is what failed, and each of the four now has a regression test.
• One correction lands in the shared onboarding skeleton, so every row's generated file changes. Three bullets told the reader to type a command that cannot exist (the runtime invocation token where the user-facing skill token belongs), the DocumentKB paragraph shipped twice with the two copies disagreeing, a hook claim was true of no row, one cross-reference pointed the wrong way, and both section slots glued their first heading to the preceding paragraph. Claude Code, Codex, Copilot, Cursor, Kiro and OpenCode outputs all move as a result; the alternative was correcting one row and leaving the same text wrong in five.
• Deleting a row deletes the fixes that landed in it. fix: bind Plan Approval to content and attempt, add human-only exits, guard Kiro IDE's Windows shell; feat: Change Control #1000 and fix: restore Plan Approval forwarding and harness hook execution #1097 hardened harness/kiro-ide/ while this branch was open, and none of what they added is IDE-0.x-specific, because this row still ships the legacy Plan Approval axis. Six things move here. The shell tool is named execute_bash, execute_pwsh (Windows) or shell, and ten branches tested a literal — one predicate now backs every shell decision, because an unrecognised name failed open on that host. The unattributable-mutation refusal is gated on an active Code Generation window, so the next that starts the loop is no longer refused with no workflow. The safe-read set gains the names the runtime actually sends. Legacy mediation records the planned workspace source, without which core refuses the decision and nothing is recorded at all. A failed mediation step is a refusal with a reason on stderr rather than a silent drop that left the write window latched. And source drift before approval no longer dead-ends: the canonical planning write — the remedy — stays permitted, and the refusal says to re-present the plan. The guide and the reference prose state that contract for one row rather than two, and the conductor's own skill carries the legacy contract it has to execute: which tools may write before approval, that the directive's protected choices are shown verbatim and mapped back to canonical answers and never copied into shared files, and that recovery needs an exact human Recover Plan Approval.
• Folding the rows turned a harness-name check into dead code, and a guard went silent. retainedTransportForCurrentState skipped its reuse path for the legacy window by name (installedHarnessName() === "kiro-ide"). One row makes that literal permanently false, so a live legacy window took the reuse path and the publication that rotates its protected choices never happened: next answered run-stage where ownership had to refuse (t327 went 4/0 → 2/4). The carve-out exists because of the window, not the row, so it now asks the window — a derived legacy session whose host record matches, the same predicate the file already used a few hundred lines above. Reading the environment alone would have caught a supported IDE 1.x session and a CLI run from a VS Code terminal, both of which keep the reuse. core/ is left with no "kiro-ide" literal anywhere, which is the state that makes this class of silence impossible rather than merely absent. Typecheck and the build never object to a literal like this; the suite is what caught it.
• Every dispatch leaked a delegation window, and the comment asserting otherwise was the only thing checking it. The ledger write ran for every input target on the reasoning, stated in its own comment, that a repeat for the same event was "a no-op rather than a double count". It is not: opening mints a fresh group per call while a close cancels only the most-recent group for that key, and dispatch tools match two ledger-writing targets on PreToolUse against one on PostToolUse. So every dispatch opened two groups and closed one, and the leftover window kept the lifecycle guard refusing the main session's own verbs with a finished delegate named as the caller — measured on a live run, twice, where the only way forward was editing the ledger by hand. One target owns the ledger now: the only one registered on both edges of a dispatch. Typecheck, Biome and package.ts --check are all blind to this; the regression test delivers one dispatch event to both targets and asserts one close releases it.
• The row ships two keyless HTTP MCP entries instead of four uvx launchers. The merged row inherited Claude's registry, where four of the five entries spawn a local process from a floating @latest package. That is a heavier default than a row serving both surfaces wants, and the AWS documentation case it existed for is covered over plain HTTP, so the registry is now context7 plus aws-knowledge-mcp-server, both type: http and both disabled. Claude keeps its five deliberately: the two harnesses provision MCP differently, and the guide and glossary prose describing the five is Claude-framed, so it stays true and is untouched. Two consequences the type checker does not see — the shared config diagnostics resolved its shipped-server list per harness, because one list would report a false defaults-drift on whichever harness ships fewer; and the persona frontmatter grants one token per entry, so all fourteen personas move from five grants to two.
• Deleting a row deletes the fixes that landed in it — a second time, and one of them I first mis-inventoried. Rebasing replayed this PR's deletion of the IDE row over four upstream changes to it, none IDE-0.x-specific. disclose_context joins the Plan Approval safe-read set, because denying it stopped a Windows customer mid-workflow and it has no write surface. Two hook manifests match all three shell spellings rather than execute_bash alone, since the engine verbs arrive through whichever one the host sends and a missing spelling silently stops that hook. fix: restore native Kiro IDE Plan Approval recovery and mediation #1111's new native-recovery suite pointed at the deleted row's dist, so its coverage moved to the merged row rather than disappearing. And its legacy spawns now route through the compiled binary's own subcommand: I had recorded that helper as "already covered here" on the strength of a grep count for the environment variable it reads, but those hits were elsewhere, and on a compiled install passing a source path to the binary makes the recovery fail closed. A grep count is not evidence that a code path uses what it counts.
• The skill claimed there is no statusline. The row wires none, which is what the sentence meant, but as written it is false on a CLI where a human configured one — and the renderer ships in this row's tools. Narrowed to "this row wires no statusline", keeping the part that matters to the conductor explicit: a statusline reaches it through nothing, so position still has to be surfaced in prose.

Tests

t331 is new and encodes the wiring contract rather than the current file list: every required responsibility on every trigger it needs, a refusing responsibility only on a blocking trigger, a single-surface trigger always paired, every manifest target existing in the adapter, and every matcher covering the tool names the canonicalizers translate. That last assertion is what caught the execute_pwsh and write gaps.

t147 (36 → 42 cases) keeps its live-captured payload fixtures and gains regression cases for the delegation window: one crew dispatch is one window however many personas it named; two identical dispatches need two closes; reviewer-scope still enforces when a second persona is inflight; a crew with no review in flight leaves the drop log clean; a dispatch record naming a delegate that is not inflight is recorded as a drop; the 0.x notice fires only on the legacy channel.

t245 and t148 were rewritten onto the Markdown shape — the properties they pinned (no blanket shell trust, no nested delegation, no model pin, every registration reaching this row's adapter) all still matter. t245's expected registration table is now generated from the shipped manifests so a matcher change cannot leave it stale by hand.

Three tests pinned the absence of enforcement this row now has (reviewer-scope registration, review-freeze registration, the doc-parity claim) and were inverted rather than deleted. The matching carve-out in stage-protocol-reviewer.md — "on a harness without reviewer-scope enforcement (Kiro IDE today), do not write the record" — is gone with them, after checking every shipped row's registration: no harness lacks it now.

Verified

bun install --frozen-lockfile          ok
bun scripts/package.ts                 ok
bun scripts/package.ts --check         deterministic across two builds, all six rows
bun run typecheck                      0 errors (all three configs)
dist/kiro doctor                       0 problems
aidlc-graph.ts compile --check         exit 0

bun tests/run-tests.ts --smoke --unit, on this head with upstream/main a0ee4415 merged in — 305 files, 8,321 assertions, one failing assertion.

That failure is t150-codex-packaging, in the case that asserts doctor enforces Codex 0.145.0 as the compact-session reload floor. It is a 5,000 ms timeout: the doctor child process returned status −1 rather than 0, and the runner reported "killed 1 dangling process". The same file passes 13/0 in isolation on the same tree, in 9.47 s for the whole file, so the single case is under the limit when it is not competing for the machine. This branch does not modify that test, and while it does touch harness/codex/manifest.ts, the failing case checks a version floor in doctor rather than anything the manifest carries.

The two suites the earlier body named as environment-sensitive both pass in this run: t255-workspace-sync and t314-source-freshness-receipts. That is the first completed tier in which they pass together, which is what the earlier explanation predicted. The published figures before this run (297 files, 8,195 assertions) came from before the rebase, and the sentence that explained them blamed "the machine under --parallel 8" — wrongly, because the runner pins every smoke and unit file to serial execution, so that flag creates no concurrency in either tier. Bare bun test tests/unit still does not complete on this machine, which is why per-suite numbers come from isolated runs; the totals above come from the repository's own runner.

The merge itself is clean — 0 conflicts — even though the overlap with upstream/main has grown from six files to nine, three of them files this repository's own merged PRs changed (#1158 and #1160: core/aidlc-common/protocols/stage-protocol-reviewer.md, tests/unit/t266-review-class.test.ts, tests/unit/t279-reviewer-turn-budget.test.ts). On that merged tree typecheck, lint and package.ts --check are clean. t279's per-harness assertion needed no roster edit because HARNESS_MATRIX is discovered from the tree rather than hardcoded; all six shipped rows carry the reviewer clause, and kiro-ide is absent by design.

Isolated suites on the merged tree above: t266 15/0 · t279 15/0 · t271 47/0 · t239 13/0 · t331 25/0 · t147 45/0.

Isolated suites measured earlier, before upstream/main was merged in (counts have since grown where upstream added assertions): t245 43/0 · t148 16/0 · t218 74/0 · t221 64/0 · t243 84/0 · t244 0 fail · t68 7/0 · t264 · t265 · t293 · t294.

Replayed on throwaway fixtures with real captured payload shapes: dispatch Pre → the window holds the persona; the delegate running aidlc-orchestrate.ts next → exit 2 naming it; dispatch Post → window empty and the same command passes; orchestrate_subagent Pre → the window holds stages[].role; two distinct personas inflight → exit 2 naming both; the 0.x notice → exit 0 with no output on a supported host, exit 2 with the notice when USER_PROMPT is set.

Attribution inside a parallel delegation window, every branch measured on a throwaway fixture and pinned by a test in t147:

inflight	dispatch record	result
two delegates	names one of them	that identity is forwarded, the guard refuses (exit 2), and the possible false refusal of the other delegate's call is recorded as a drop
two delegates	names a delegate that is not inflight	fail open, recorded as a drop
two delegates	none — the ordinary state of a crew stage	fail open, and nothing is recorded
one delegate	—	the window alone is the identity; no record is consulted

The 0.x notice, on a real Kiro IDE 0.12.333. Installed the shipped kiro tree into an empty project, opened it in that build, and asked for a file read. The hook fires at the tool call, the agent abandons the read, relays the notice, and does not try to work around it. Two earlier shapes were measured on the same host and rejected: promptSubmit + exit 2 arrived as a failed hook, and the session's own agent then spent two minutes diagnosing it and wrote "enabled": false into the manifest — the same request now completes in ten seconds. Also measured there: the "enabled" field in a .kiro.hook does not gate execution (that host keeps per-hook enablement in workspace state), so editing it neither disables the notice nor is a supported way to.

And on a supported one, IDE 1.0.437. The same tree, the same request: the read succeeds and no legacy hook runs — confirmed by two silent .kiro.hook probes that would have recorded a firing to a file, and by the shipped notice staying quiet. "The legacy channel does not fire on a supported host" is therefore measured on the current generation, not inherited from an older one. What that host does do is list the file as legacy with a Migrate button, and it populates USER_PROMPT for a runCommand hook exactly as 0.x does — so the notice reads the host version from VSCODE_IPC_HOOK and stays silent unless the major is 0. Verified against the running host's real socket path rather than a fixture literal.

The same session is incidental evidence for the row itself on the IDE surface: session-start, record-human-turn, terminal-command, enforce-approval-gate, plan-approval-guard, reviewer-scope and continue-workflow all fired from the standalone manifests, the engine advanced its turn counter and created the intent record, and .drops stayed empty.

A guarded call inside a parallel delegation window, on Kiro CLI --v3. Three delegates opened before any of them closed, and guarded calls landed inside that window:

12:41:19.694  PreToolUse   subagent_aidlc-quality-agent        window 1
12:41:27.258  PreToolUse   subagent_aidlc-developer-agent      window 2  (2 inflight)
12:41:27.796  PreToolUse   execute_bash                        guarded, 2 inflight
12:41:36.838  PreToolUse   subagent_aidlc-devsecops-agent      window 3  (3 inflight)
12:41:37.437  PreToolUse   execute_bash                        guarded, 3 inflight

No delegate closed between those rows, so the concurrency is the capture's own ordering rather than an inference. execute_bash and fs_write calls continued to land with two or three delegates inflight for the rest of the window. That is the combination the second Not verified bullet said had only been replayed on a fixture, and it is now on the ledger of a live run.

The branch that window feeds was exercised with it. Three delegates inflight and no reviewer dispatch record is the ambiguous case: the adapter resolves no identity, the core hook fails open, and — because a recordless crew is the ordinary state of that stage rather than a failure — nothing is written to .drops. The run has no kiro-adapter.drops file at all, which is what the unit case for that branch asserts.

The reviewer read-scope bound, enforcing, on both surfaces. Two live runs from this shipped tree reached CONSTRUCTION and ran per-unit reviews, which is what writes the dispatch record the guard needs. The record is written as the protocol specifies:

.aidlc-reviewer-dispatch.json
  reviewer  aidlc-architecture-reviewer-agent
  stage     functional-design
  unit      shared-kernel
  exempt    7 paths — the declared upstream artifacts plus the stage file

The guard then refused, and the refusals are on the ledger as REVIEWER_SCOPE_BLOCKED rows:

surface	refusals	units	what was refused
Kiro CLI	7	shared-kernel, identity-access, ordering-session, customer-web	Bash, target <project-dir> — and one with target <record-root>
Kiro IDE	1	auth-foundation	Bash, target <project-dir>

The first refusal is representative: the reviewer ran cd <project-root> && git status --porcelain, which reaches every unit's artifacts, and the hook stopped it — that row has a PreToolUse with no PostToolUse, so the refusal is the hook's exit, not a tool result. One later refusal names <record-root> rather than the project root, so the bound is not merely a project-root check.

What passed in the same window is the stronger half. Six cd <record>/inception && … commands ran unrefused during those reviews — reading stories.md, requirements.md, the story map and specific FR blocks. All of them are on the dispatch record's exempt list. The guard therefore discriminates: declared upstream reads pass, sweeps of the record root or the project root do not.

No workaround followed a refusal. After the block the reviewer read its own review file, returned its verdict, and the stage advanced (log review → state unit complete --wave --unit shared-kernel). There is no later call that reaches the same breadth through another tool.

One limit, stated because the ledger cannot show it otherwise: every refusal so far is on Bash. The guard also matches the search and listing tools, and those matchers have not been exercised — not because the reviewer avoids them (the runs use grep_search 25 times, list_directory 16, and file_search 7) but because inside these review windows the reviewer routes its searching through the shell instead: 53 execute_bash calls against 1 grep_search in one window, and 741 against 25 across the run. So the Bash matcher carries the load here, and the search matchers remain covered by tests rather than by this run.

Not verified — please weigh this

• No completed end-to-end /aidlc run is included here. Two runs from this shipped tree — a Kiro CLI --v3 project and an IDE 1.x project — have carried a workflow through IDEATION and INCEPTION and into CONSTRUCTION. On the CLI surface five units have been through functional-design with their own per-unit reviews, two of them across a NOT-READY → revision → READY cycle; on the IDE surface two units have. Every standalone hook fires, the rituals run, and one run surfaced a real defect in this row that is now fixed with a regression test (see the delegation-ledger bullet). What remains unverified is the tail of CONSTRUCTION — code-generation, build-and-test and ci-pipeline — rather than the phase or the wiring.

Release metadata

Deliberately absent: no aidlc-version.ts bump, no README badge change, no CHANGELOG heading — following the maintainers' "we will bump version when releasing". AGENTS.md and CONTRIBUTING.md currently say the opposite; that divergence is worth settling separately and is not this PR's to decide. The entry a release would need:

Consolidate the two Kiro distributions into one. kiro now serves Kiro IDE and Kiro CLI from a single .kiro/ tree; the kiro-ide distribution is removed. Breaking: aidlc config --harness kiro-ide no longer resolves — use --harness kiro. Upgrade: an existing kiro-ide install becomes a kiro install by re-running aidlc config --harness kiro; a manual copy must first delete the retired surfaces an overlay cannot remove (.kiro/agents/aidlc.json, .kiro/agents/aidlc-*-agent.json, and the .kiro/hooks/aidlc-*.kiro.hook files other than the 0.x notice) — see the cleanup block in docs/guide/harnesses/kiro.md. Kiro IDE 0.x is not supported.

Follow-ups this PR does not take

• The row carries two permission vocabularies. The conductor declares capability globs (permissions), the personas declare tool-settings regexes (toolsSettings). Both are supported — docs/features/custom-agents.md states existing JSON keeps working unmodified and the newer fields are optional — so each file keeps the shape it shipped with before the merge rather than being rewritten here. Unifying them is a separate, mechanical change.
• The other native rows now route through the same dispatcher, and this PR does not touch them. fix: route native Copilot and Cursor hooks through the adapter dispatcher #1065 moved Copilot's and Cursor's native hooks onto the adapter dispatcher, which is the shape this row already had and the reason its two adapters could be folded into one. Whether the three dispatchers should share more than a shape — a common entry point rather than one adapter per row — is worth asking once this lands, and is deliberately out of scope here.

Review history

Reviewed adversarially five times before submission (Codex, in a separate harness). The last round's five blockers — crew-dispatch window accounting, the two missing matcher names, reviewer-scope failing open under ambiguity, and a check-then-truncate race in the ledger — are fixed here with regression tests. I am the reviewer on other PRs in this repo; treating my own work the same way seemed like the minimum.

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the project license.

[rafaelgsr]

Thanks for consolidating the Kiro CLI and IDE distributions.

I reviewed the current head 4c5c2cf7094f20462c0a6089cf0e957ed808d2ea against base a517a06166448a456d3934d68a216b627b65547a.

The direction aligns with the project's one-core/many-harness architecture and replaces PR #1063's scope. I found three issues:

1. [P1] Preview-release lifecycle checks still include kiro-ide. .github/workflows/preview-release.yml:440 and :574 invoke a distribution that this PR removes. The command exits 4, so both Windows and Unix preview-release jobs will fail. Please remove that row and add coverage that keeps preview and stable release rosters synchronized.

2. [P2] Persisted machine defaults are not migrated. core/tools/aidlc-init.ts:4170 compares default-harness directly without applying the retired-distribution successor map. A machine retaining kiro-ide cannot configure a fresh project without explicitly passing --harness kiro. Please normalize or migrate the saved default and cover this upgrade path.

3. [P3] Plugin documentation still calls .kiro ambiguous. docs/harness-engineering/10-authoring-a-plugin.md:577 still distinguishes Kiro CLI from Kiro IDE. Please update it for the unified distribution.

I made no changes to the author branch.

Validation performed:

• bun scripts/package.ts --check — passed
• TypeScript checks — passed
• Focused Kiro adapter, manifest, MCP, smoke, and diagnostic tests — passed
• Current remote CI — all required checks green
• Both blocking upgrade/release failures reproduced manually on the current head

One remaining risk is that a completed live Kiro workflow tail has not been independently verified.

[leandrodamascena]

Thanks for consolidating the Kiro IDE and CLI distributions and for carrying the upstream fixes into the merged row.

I reviewed the current head 4c5c2cf against current main 891669aa9, with merge base a517a061. The repository already treats both Kiro surfaces as the same .kiro runtime, so the consolidation matches the current architecture. I found three blocking compatibility and release defects.

1. P1: Preview publication still invokes the retired distribution. .github/workflows/preview-release.yml:440 and :574 still include kiro-ide. Both lifecycle jobs invoke aidlc config --harness kiro-ide, which now exits 4. The next scheduled or manually dispatched preview will fail before publication. Remove the retired entry from both lists and add coverage for the preview workflow inventory.

2. P1: Previously valid model settings prevent migration. core/tools/aidlc-settings.ts:199-212 now rejects kiro-ide in per-agent model maps. The previous release accepted that key. During aidlc config --harness kiro, settings are resolved before the project stamp changes, so the command exits 4 with unknown harness "kiro-ide". Read the retired key as a compatibility alias for kiro, define the conflict behavior when both keys exist, and add an upgrade regression test.

3. P2: Read-only configuration and the interactive setup walk reject retired project stamps. selectedDiagnosticHarness, prepareModelsSection, and runSetupWalk pass the persisted kiro-ide identity directly to modelHarness, which now rejects it. I reproduced exit 2 from both config providers --show and config models --show. Apply the one-way successor mapping when reading existing project identity and when matching --harness kiro, while continuing to write kiro.

Validation performed on a local merge with current main: bun run typecheck passed, bun scripts/package.ts --check passed, reviewer-scope tests passed 120/120, and the focused Kiro/configuration suites passed 117/117. The current GitHub CI is green. The disclosed absence of a completed end-to-end Construction tail remains a release risk after these blockers are fixed.

[wowzoo]

Thank you both — the reproductions made these quick to confirm, and five of the six turned out to share one cause.

The first cut of the upgrade path fixed the places that perform the upgrade and left every place that reads an identity a previous release wrote. So a user holding the retired row was refused before reaching the upgrade at all — the worst shape this could take, and I had scoped it that way deliberately: I left the read-only sections alone on the reasoning that they should keep reporting the id the project actually carries, and wrote that reasoning into a comment. Reproducing your exit 2 settled it.

Current head is bff9376d, CI green, and it also absorbs 891669aa (#1179) so the branch is not behind.

@rafaelgsr 1 / @leandrodamascena 1 — preview publication invokes the retired row. Removed from both shells in .github/workflows/preview-release.yml. release.yml had already been updated and this one had not, which is exactly how it stayed invisible, so t332 now reads the PowerShell list, both bash lists, and the shipped roster and requires all three to match.

@leandrodamascena 2 — previously valid model settings block migration. normalizeHarnessModelMap reads the retired key as its successor instead of throwing. Conflict behaviour, since you asked for it to be defined: the current key wins, the retired one applies only in its absence, and the outcome does not depend on which key the file lists first. A key that never existed is still a hard error, named as the user wrote it.

@leandrodamascena 3 — read-only configuration and the setup walk reject retired stamps. Resolved at the gate rather than at the call sites: modelHarness maps a retired id to its successor, which covers selectedDiagnosticHarness, prepareModelsSection and runSetupWalk together. Patching call sites is what produced this round's defect — I picked four and missed three — and the returned type still has no retired member, so every write keeps emitting kiro.

@rafaelgsr 2 — persisted machine defaults are not migrated. The configured default is normalized, so a machine that recorded the retired row configures a fresh project without an explicit --harness.

@rafaelgsr 3 — plugin documentation still calls .kiro ambiguous. Updated; .aidlc (Copilot vs OpenCode) is now the only ambiguous root named.

The successor map moved to aidlc-runtime-paths.ts. It began local to aidlc-init.ts, which is why none of the consumers you found ever saw it — and worth flagging since it is visible in the history: my first move put it in aidlc-model-policy.ts, which turned a compile-time import type in aidlc-settings.ts into a runtime import and broke every spawned-hook suite, because aidlc-lib.ts loads settings and that module is not one of the siblings a hook pulls in. CI caught it. Adding it to that sibling list would have gone green while widening what every hook loads, which is the opposite of where #1180 is taking high-frequency hooks, so it now lives beside legacyDistribution and harnessIdentity in a module that imports nothing from this project and is already on the lib path.

On the residual risk you both named. It is real and I am not going to claim it away. I do not think this PR is the right place to close it: validating a full Construction tail takes days of wall clock, main moved five times while this round was open, and each move costs this branch another absorption — waiting does not buy confidence so much as it guarantees the branch is never reviewed at a version that is still current. My plan is to validate the tail against a preview release once this lands, which is what that channel is for, and to bring anything it surfaces as focused follow-up pull requests rather than as more commits here. That is already how the last few went out (#1163, #1171, #1186). A gated Classic-scope run is under way locally in the meantime, on a tree built from this exact head, and I will report what it shows either way.

[apackeer]

Thanks for the fast turnaround on the first round and for the reproductions in the reply — the six items are fixed where you said they are, and moving the successor map into aidlc-runtime-paths.ts is the right home for it.

I reviewed the current head 130f5d4ff3efd4d3f8a09bba4dddca5d9696a615 against d8f8c0c3d81614ed9f6ed9be71713ea84a4d0bdc (merge base identical). Alignment rests on @rafaelgsr's and @leandrodamascena's reviews; the delta since 4c5c2cf7 stays within that scope. The findings below were reproduced on bff9376d against dist/kiro built from that head; the only change since is the upstream #1186 merge, which touches none of the cited files.

Blocking

1. P1 — A refused dispatch leaks a delegation window and wedges the main session.
harness/kiro/hooks/aidlc-kiro-adapter.ts:1432-1449 opens the ledger group on log-subagent's PreToolUse edge before any sibling guard has decided. When plan-approval-guard refuses the dispatch (exit 2 on subagent_aidlc-developer-agent before a Plan Approval receipt exists — its designed job), Kiro blocks the tool and emits no PostToolUse, so the close at :1445-1446 never runs and the open lives until DELEGATION_TTL_MS (:279, 6 h). state-transition-guard (:1963-1968) then forwards the stale persona as agent_type, and the main session's own aidlc-orchestrate.ts next is refused with Delegated agent "aidlc-developer-agent" cannot run aidlc-orchestrate.ts next …. Reproduced twice independently; a subsequent record-human-turn does not clear it. This is the same wedge the double-open fix addressed, re-created by any refused, cancelled, or interrupted dispatch. Please cancel the group when a dispatch is refused (or open only once the dispatch is accepted), and add a t147 case: refused dispatch + log-subagent Pre edge → main-session next still allowed.

2. P2 — guard-tool-call is not registered anywhere.
The first-next argument-fidelity guard is only referenced inside the adapter (:1296, :1549); no harness/kiro/hooks/*.json names it. All six shipped execute_bash PreToolUse guards accept a bare bun .kiro/tools/aidlc.ts engine orchestrate next after verb-intercept latched the user's arguments, while invoking the target directly on the same payload returns 2. t331 omits it from the required set, so the contract test stays green. Please register it (all three shell spellings) or fold its check into terminal-command-guard, and add it to t331.

3. P2 — doctor crashes on an unrefreshed kiro-ide project.
core/tools/aidlc-config-diagnostics.ts:2214 casts selected.distribution as ModelHarness without currentDistribution, so probeHarnessCli reads HARNESS_CLI["kiro-ide"] (removed) and throws TypeError: undefined is not an object (evaluating 'spec.command') at :778. Base doctor passes on the same project (52 passed / 4 warnings); head exits 1. Same root cause as the round-1 P2, one more reader. Please route it through the successor resolver and cover doctor itself in the retired-stamp regression (t243 currently checks providers/models --show only).

4. P2 — A failed write with a populated input path is audited as ARTIFACT_UPDATED.
The new input-path preference at aidlc-kiro-adapter.ts:2944-2963 makes rawPath non-empty, and the failure-prose classification sits inside if (!rawPath), so a str_replace failure (Caught an error while replacing string … found multiple times, or the structured {success:false,result:[…]} form) reaches the success path. Reproduced: file byte-identical, head emits ARTIFACT_UPDATED, base emits nothing. Please classify failure before choosing the success path; t218 F4d covers this prose only with empty tool_input.

5. P2 — enforce-approval-gate reads state from process.cwd(), not the resolved project.
aidlc-kiro-adapter.ts:1395-1405 uses process.cwd() for stateFilePath/humanActedSinceGate even though projectDir is resolved at :728 from --project-dir/AIDLC_PROJECT_DIR. The same guarded payload returns 2 from the project root and 0 from a foreign cwd; the pre-merge CLI guard-tool-call presence check returned 2 from the foreign cwd. Please use projectDir and audit the other merged process.cwd() branches (review-freeze in particular).

6. P2 — Source kiro installs fail config trust --check.
aidlc-config-diagnostics.ts:1911-1932 now requires .vscode/settings.json with aidlc engine * for every kiro install, but harness/kiro/manifest.ts ships that file in nativeRootIntegrations only and the source projection invokes Bun, not aidlc. An unmodified dist/kiro source projection returns exit 1 with kiro-ide-trust-unreadable; base returned 0; doctor on the same tree reports 0 problems, so the two diagnostics disagree. Please gate the check on the projection's command channel.

Non-blocking

• P2 (disclosure) Per-agent model/effort policy is no longer expressible on kiro (HARNESS_HONESTY.kiro → model:false, effort:false, core/tools/aidlc-model-policy.ts:136-142), and t293:801-827 was rewritten from "the model landed" to "inexpressible". The pre-merge kiro row expressed it and Kiro's agent configuration reference still lists model. Either restore it through the Markdown frontmatter writer or name it as a second breaking change in the release-note draft and warn from config models.
• P3 hook_event_name is compared exactly as "PreToolUse"/"PostToolUse" (aidlc-kiro-adapter.ts:1443-1446, :3133) while the repo's live-captured CLI fixtures (tests/fixtures/kiro-hook-payloads/payloads.json) spell preToolUse/postToolUse. Your v3 capture shows PreToolUse, so this is a fixture/code mismatch rather than an observed bypass — but t147 builds its own PascalCase payloads, so the suite cannot tell the two apart. Please normalize the comparison, drive one t147 case with the fixture spelling, and record which spelling each host emits in kiro-ide-hook-payload.md.
• P3 t332:372-393 applies the PowerShell roster regex to preview-release.yml only; release.yml:402 carries its own $harnesses = @(...) list that is unasserted (it matches today).
• P3 The body says t245's expected table "is now generated from the shipped manifests"; EXPECTED_V2_REGISTRATIONS (t245:47) is a hand-maintained constant.
• P3 Rename residue: duplicate rmSync(kiroProject…) at scripts/build-binaries.ts:1881-1882; the plugin.kind comment at scripts/manifest-types.ts:203-204 is truncated mid-sentence.

One question

Does IDE 1.0.437 populate USER_PROMPT for the v2 UserPromptSubmit shell hook (the body reports it does for runCommand)? If so, aidlc-kiro-adapter.ts:764-776 classifies the session as the legacy channel and record-human-turn writes the legacy Plan Approval host marker (:2463-2465) on a supported host — the 0.x notice already distrusts that signal and checks VSCODE_IPC_HOOK, while the channel classifier does not. Not filed as a finding because no host was measured here.

Validation

Temporary worktrees only; no changes to the branch. bun scripts/package.ts --check deterministic across all six rows; bun run typecheck 0 errors on all three configs; t147, t331, t332, t245, t148, t327, t68, t298, t293, t243 (retired), t221, t264, t239, t281, t294, t230, t252 green; t265 55/0 on 130f5d4f. Each blocker has a throwaway reproduction against dist/kiro; #3, #4 and #6 were diffed against a projection built from base 891669aa. Also confirmed: the six round-1 fixes; the managed upgrade from a real kiro-ide projection (twelve legacy .kiro.hook files removed, notice retained); all 14 personas carry tools/toolsSettings/resources and the two MCP grants in both channels; Claude's MCP diagnostics unchanged; shared core/tools changes gated to .kiro; release metadata untouched.

Remaining risk

No completed Construction tail on either surface — #1 sits exactly there. An unclean manual overlay leaves the twelve old .kiro.hook files in place and doctor does not flag them. CI on 130f5d4f is green.

Recommendation: changes requested for #1–#6.

[wowzoo]

Thank you — six reproductions with exact coordinates, and every one of them held when I re-measured it. Two of your six also overturned a judgement I had already written down, which I have said plainly below rather than quietly fixing.

Current head is 6ec8715f, base 9288f80f, CI 22 pass / 0 fail. One commit carries the six fixes; the two after it absorb #1166 and #1195.

1 (P1) — a refused dispatch leaked a delegation window. Confirmed exactly as described, including that a later record-human-turn does not clear it: I reproduced open → next refused → human turn → still refused → PostToolUse close → allowed. The window is now cancelled at the two places this adapter turns a refusal into Kiro's reject contract, rather than inside any one guard, so a guard added later inherits it. Cancelling alone was not sufficient: hook order across sibling registrations is not guaranteed, and the replay discarded a close whose open had not been appended yet — so liveDelegationOpens now counts a pending close, and the pending close consumes the whole group, since one dispatch names several personas and cancelling only the first left the rest live. t147 5d5 is your case (refused dispatch + the opening edge → main-session next still allowed).

Your walk of the other leak paths was more complete than mine, and I want to record what I did not fix: cancellation, a crash, a malformed PostToolUse, and a tool_input that differs between the edges (the key is a hash of it) all still leak until the TTL. A record-human-turn sweep would cover them, and the blocking-dispatch contract makes it safe, but it is a behaviour change beyond the refusal you filed, so I left it out of this round rather than smuggle it in.

2 (P2) — guard-tool-call is not registered. Confirmed, and I had the scope wrong in the narrower direction. My first reproduction had it return 0, because --scope on a project with no state file takes the engine pre-dispatch branch, which clears the forwarding latch; I concluded the exposure was limited to turns that write that latch. That is only half of it. The same target carries a second exit-2 branch — the same-turn roll-forward backstop, armed by any classified terminal command and by the --config pre-dispatch — which is independent of the forwarding latch, and t180 asserts both by invoking the target directly. So the tests were green while nothing enforced either one in production. Registered with the terminal-tool matcher, pinned in t331 (responsibility and matcher) and in t245 (manifest schema), and the roster in the Kiro harness guide now lists it.

Adding it also had to enter a roster neither of us named: t308 pins the matcher-bearing manifests by name, and the local tier caught that. Fixing the two rosters the change touched was not enough.

3 (P2) — doctor crashes on an unrefreshed kiro-ide project. Confirmed with your stack: exit 1 at aidlc-config-diagnostics.ts:778, while the base reports 0 problems, 3 warnings on the same fixture. Reading a stamp is a read, so it goes through currentDistribution like every other reader — and separately, the probe no longer throws on an id the CLI table does not know, because a diagnostic must not be the thing that crashes. The retired-stamp regression now runs doctor before the migration and requires a report rather than a stack trace; problems are allowed there, since the project genuinely has one until it upgrades.

4 (P2) — a failed write with a populated input path is audited as ARTIFACT_UPDATED. Confirmed, with a base control: the same payload writes nothing at the base and an ARTIFACT_UPDATED row at this head. Your diagnosis of why is what I would not have found quickly — an empty path had been standing in for "the write failed", and preferring the tool input silently retired that proxy. The classification now runs before the path is used at all. t218 F4g is the populated-input twin of F4d, and it also asserts no drop, since a refused write is the tool working correctly.

5 (P2) — enforce-approval-gate reads process.cwd(). You were right and my first pass was wrong about it. I reported to my own notes that the divergence "did not reproduce", when what actually happened is that my fixture never armed the floor: the test runner sets AIDLC_SKIP_HUMAN_PRESENCE_GUARD=1 globally, and humanActedSinceGate returns true on a ledger with no presence-tracking events at all. With the off-switch removed, a stage at [?], and an audit carrying a non-HUMAN_TURN event, the case fails at the parent exactly where you said it would. Fixed at all three sites — enforce-approval-gate, state-transition-guard and review-freeze — since your "audit the other merged process.cwd() branches" turned out to name two more, and the comment that justified reading the cwd is corrected. t147 5h drives the same payload from the project and from a foreign cwd and requires the verdict not to move.

One correction to my own test scaffolding, in case it matters elsewhere: the adapter's run() takes _extraArgs and never reads it, so --project-dir passed to the adapter directly is ignored. My earlier probe only worked because it also set AIDLC_PROJECT_DIR.

6 (P2) — source kiro installs fail config trust --check. Confirmed, and the disagreement between the two diagnostics is the part that decided the fix: exit 1 from trust --check and 0 problems from doctor on the same untouched tree. I gated it on the projection descriptor rather than on the running invocation — the release build adds .vscode/settings.json to rootIntegrations, a source projection does not — so the diagnostic reports on the project in front of it instead of on whichever binary is asking, and the native channel still reports both the missing entry and an unreadable file. t294 covers source-exempt and native-enforced on the same fixture.

One thing I did not do: deliver-stage-rules. I noticed it is also absent from every hook JSON and from t331, and nearly filed it alongside #2 as the same defect. It is not: t245 asserts that aidlc-deliver-stage-rules.json must not exist, the core hook explains that Kiro CLI gets stage rules through native resource preload and the IDE through always-included steering, and the steering file is inclusion: always. So the absence is a decision, not a gap. The comment above canonicalTool that says these targets are "engine- and shell-invoked … t331 names them" is stale in the same breath, since t331 did not name two of the three; that is a prose defect this branch introduced and I will correct it.

Non-blocking items. I verified all five and none of them is fixed in this round: the HARNESS_HONESTY.kiro disclosure (model: false, effort: false, with t293 rewritten to "inexpressible"), the hook_event_name casing against the captured fixtures (preToolUse/postToolUse, ten occurrences, versus the PascalCase comparison), t332 applying the PowerShell roster regex to preview-release.yml only while release.yml:402 carries its own unasserted list, the t245 claim in the PR body (EXPECTED_V2_REGISTRATIONS is a hand-maintained constant, so the body is wrong and I will fix the body), and the two rename residues (build-binaries.ts calls rmSync(kiroProject…) twice; the plugin.kind comment in manifest-types.ts breaks off mid-sentence). Your P2 disclosure is the one with a product decision in it, so I would rather answer it in the release note than pick a surface for it unilaterally.

Remaining risk. Unchanged from what I told @rafaelgsr and @leandrodamascena: no completed Construction tail on either surface, and I am not claiming it away. My plan is still to validate it against a preview release once this lands, and to bring what it surfaces as focused follow-up pull requests. Your point that #1 sits exactly there is fair — that is the failure a real tail would have hit, and it is the one blocker in this round that a test could not have found on its own.

[apackeer]

Thanks — four of the six are fixed and verified by reproduction (#2, #3, #5, #6), and the honesty about the leak paths you did not take is appreciated.

I reviewed the current head 6ec8715fe3665088ef65d78cac8c671a62a57519 against 9288f80f4c289891e362864c0f3055309648927b (merge base identical). The delta since 130f5d4f is 2b29e93e2 plus two upstream merges that carry nothing PR-authored. Everything below was reproduced on dist/kiro built from this head.

Blocking

1. P1 — #1 is only partially fixed: enforce-approval-gate still leaks the window.
aidlc-enforce-approval-gate.json has no matcher, so it fires on every dispatch; it returns 2 at harness/kiro/hooks/aidlc-kiro-adapter.ts:1415 before either cancelRefusedDispatchWindow site (:3350, :3452), and it is not in INPUT_TARGETS, so adding the call there alone would see no toolName. Reproduced: log-subagent open → gate refuses (2) → HUMAN_TURN appended → gate passes (0) → main-session next refused with Delegated agent "aidlc-developer-agent" cannot run aidlc-orchestrate.ts next; the ledger holds the open with no close, until the 6 h TTL. Please route every exit-2 on a dispatch-shaped PreToolUse through one cancel path (a single exit shim), and add the t147 twin of 5d5 with this guard as the refuser (armed gate, AIDLC_SKIP_HUMAN_PRESENCE_GUARD unset).

2. P2 — the pending-close accounting introduced in 2b29e93e2 fails open.
liveDelegationOpens skips a TTL-expired open at :2349 but still counts its close as pending at :2370-2372, and the next byte-identical dispatch's open is consumed at :2351-2356. So in a session that lives past DELEGATION_TTL_MS and repeats a byte-identical dispatch (a crew subagent/orchestrate_subagent with the same stages[] is the likely shape), the completed dispatch's close becomes a credit that swallows the new window, and the running delegate is invisible to state-transition-guard and reviewer-scope — delegate next → 0, control without ageing → 2. The same over-consumption is reachable inside TTL by any surplus close: a malformed-Pre refusal (close, no open) followed by a valid retry, or two guards refusing one event — which the fix for #1 will make live. Please match closes against expired opens, bound pending closes by DELEGATION_TTL_MS, and make the refusal cancel idempotent per event; add t147 cases for aged open+close → fresh identical open still attributed, and two refusals → later legitimate dispatch still attributed.

3. P2 — #4 still audits a structured failure with a populated path.
:788-789 read only the top-level toolSuccess/tool_success; collectToolResultText (:164-179) discards the nested success, so {success:false, result:['']} and any failure text without one of the four recognised prefixes reach the success path and write ARTIFACT_UPDATED for unchanged bytes (base emits nothing for the structured-empty shape). The fix comment says "the flag stays authoritative" — please make the nested flag authoritative too, and add the populated-path structured case to t218.

Non-blocking

• P3 shipsNativeTrustFile (core/tools/aidlc-config-diagnostics.ts:1919-1933) returns false on a missing or malformed descriptor, so a native install with .vscode/settings.json absent reports "trust configuration is clean for kiro". Report the unreadable descriptor as its own issue. trustFilesForHarness:1900-1902 still lists .vscode/settings.json for source projections in trust --show.
• P3 Two raw-stamp readers remain after Reorganized rules files to take up minimal space in context window #3: core/tools/aidlc-utility.ts:3610-3615 makes doctor prescribe aidlc config --harness kiro-ide (which exits 4), and core/tools/aidlc-doctor.ts:161 warns "unsupported harness policy surface: kiro-ide". Wrap both in currentDistribution and assert the fix text in the t243 retired-stamp case.
• Stale comment at aidlc-kiro-adapter.ts:1367-1368 (record-human-turn "process.cwd()"), plus the canonicalTool comment you already noted.
• The five round-2 non-blocking items are unchanged, as you said.

Verified

#2: manifest on PreToolUse for all three shell spellings; bare next → 2 through the emitted guards; verbatim first next, --config, --scope, --status paths → no false refusal; t331/t245/t308/t180 green. #3: report, not TypeError, on a real base kiro-ide projection. #5: no executable process.cwd() left; 2 from a foreign cwd with the presence guard armed at all three sites; _extraArgs unreachable from shipped wiring. #6 for the reported case: source → 0/0, release with settings → 0, release missing settings → 1. Crew release, identical-dispatch double close, two-process concurrency and reviewer attribution unregressed within TTL; deliver-stage-rules absence justified (steering inclusion: always + persona resources); guide row accurate; upstream merges clean. bun scripts/package.ts --check deterministic, typecheck 0 errors, t147 47/0, t218 F4 7/0, t243 retired 4/0, t294 28/0, t230/t252/t148 green.

Remaining risk

Unchanged — no completed Construction tail, and #1/#2 above sit in it. CI on 6ec8715f is green.

Recommendation: changes requested for the three blocking items.

[wowzoo]

Thank you — and the framing of #2 as a fail-open that my own fix introduced is exactly right. I have taken a different route than the one you proposed for #1, so I want to put that difference first rather than bury it.

Current head is 502cefed, base d378d0df, CI 22 pass / 0 fail.

#1 and #2 together, because the second is what rules out the obvious fix for the first

You proposed routing every exit-2 on a dispatch-shaped PreToolUse through one cancel path. I started there, and then #2 talked me out of it: a cancel path only works if a refusal can be written down as a fact, and this payload has no event identity to write it against. delegationKey is a content hash precisely because nothing in the payload distinguishes two dispatches — so "cancel the window this event opened" and "cancel the window some earlier identical event opened" are the same instruction. Any shim keeps that ambiguity; it just centralises where it is created.

So the window is no longer opened before admission. The log-subagent PreToolUse edge — the only target whose matcher is exactly the dispatch tools, and which already sees both edges — now decides whether a dispatch may start, and appends the open only if it may. A refusal appends nothing at all, which means there is no credit to spend and no ordering to reconcile: pendingCloses, cancelledGroups and cancelRefusedDispatchWindow are all gone, and an unmatched close is simply dropped.

Two consequences worth checking, since both are behaviour changes and not refactors:

• The human-presence floor is now one predicate (approvalFloorRefuses) with two callers, and the Plan Approval verdict on a dispatch comes from the same core hook the sibling guard would have run.
• Both matcherless gates now stand down on a dispatch shape. They have to: whoever refuses a dispatch must also be whoever decides to open its window, or the refusal strands what the other one opened — which is the wedge in your Kiro CLI support and multi-platform compatible architecture #1. enforce-approval-gate joins INPUT_TARGETS for that single purpose, since without the payload it cannot tell a dispatch from anything else. Every other tool it sees is still judged exactly as before.

The process.exit(2) you would have found next is also gone (guard-tool-call's argument-fidelity refusal now returns). It was the one exit that no wrapper could have caught.

t147 5d5 is rewritten to assert the new owner refuses and that both gates return 0 on the same payload; t147 5d6 is your aged-open case — it ages the ledger the adapter itself wrote rather than reconstructing the session hash, then requires a fresh byte-identical dispatch to still be attributed. Both fail on the round-2 adapter.

One test moved rather than being added: t218's "populated 1.x PreToolUse write and dispatch payloads are blocked before approval" asserted the refusal through plan-approval-guard. The contract it protects — a dispatch is refused before approval — is intact, so the dispatch half now goes through log-subagent, and the case also pins that the guard returns 0 on it. I checked that aidlc-log-subagent.json's matcher covers every spelling isDispatchToolName accepts, so nothing arrives at only the guard.

#3

Fixed, but deliberately not as a new rule about nested flags. The nested success now fills the same ide.toolSuccess the top-level one does, so the existing explicit-false branch decides it and no second policy is introduced. That also means a nested true gets the same standing the top-level flag already has against the prose heuristic. I stopped short of widening the failure-prose matching, which is the other half of what you saw: without a captured payload for those shapes I would be guessing at the transport's vocabulary. t218 F4h covers the structured-empty case with a populated path.

Non-blocking, all four

• shipsNativeTrustFile returns null on a missing or malformed descriptor, and the caller reports kiro-projection-descriptor-unreadable rather than treating it as "this channel owes nothing". Your case — a native install with the file deleted reporting clean — was the sharp end of collapsing those two.
• trustFilesForHarness applies the same channel test, so trust --show no longer lists .vscode/settings.json for a source projection.
• Both remaining raw-stamp readers go through currentDistribution: doctor was prescribing aidlc config --harness kiro-ide, which exits 4, and reporting a retired stamp as an unsupported policy surface — telling the user their install is unsupported when it needs the upgrade this release performs.
• Both stale comments are corrected, including the orphaned banner above canonicalTool whose claims about t331 were both false.

The five round-2 non-blocking items are still unchanged, and the HARNESS_HONESTY disclosure is still the one I would rather answer in the release note than decide unilaterally.

What I did not verify locally this round

I ran typecheck and relied on CI for the suites, rather than a local tier. That is a deliberate change of gate on my side — a full local tier takes longer here than CI does, and three of its failures (t244, t255, t314) reproduce at this PR's own base on this machine, so they say nothing about the branch. What I did keep local is the parent-failure proof above, since CI cannot do it. If you would rather see a specific suite run locally before you re-review, name it and I will.

Remaining risk

Unchanged, and your point stands: no completed Construction tail, and both #1 and #2 live in it. #2 in particular is a failure I introduced while fixing #1, which is the strongest argument yet that this area needs the tail rather than another round of reading. My plan is still to validate it against a preview release once this lands and to bring what it surfaces as separate pull requests.

[apackeer]

Thanks — the redesign is the right instinct: a refusal should never be a ledger fact, and the three round-3 blockers now have passing reproductions with failing round-2 controls (5d5, 5d6, F4h all fail on 6ec8715f).

I reviewed the current head 502cefed8ed26d352904481f6002255f428e3072 against d378d0df (merge base identical); origin/main has since moved to be94bde7 and the trial merge is clean — typecheck, package.ts --check, and t230/t147/t218/t243/t294/t331 (413/0) pass on the merged tree. Alignment unchanged. Everything below was reproduced on dist/kiro built from this head, with d378d0df and 6ec8715f controls.

Blocking

1. P1 — The stand-downs turn two independent refusers into zero. harness/kiro/hooks/aidlc-kiro-adapter.ts:1424 and :2636 return 0 for every dispatch shape unconditionally on whether the admitter ran. Reproduced four ways: (a) aidlc-log-subagent.json deleted → unapproved developer dispatch passes plan-approval-guard and enforce-approval-gate with 0 (base and 6ec8715f: 2). (b) tool_input:[] (or tool_response:42, top-level prompt:{}) sets malformedFields, which skips the admitter block at :1451 while :1424 still stands down on the name → the presence floor is bypassed at an ordinary [?] gate (6ec8715f: 2). (c) subagent_aidlc-developer-agent with tool_input.name:"aidlc-quality-agent": planApprovalRefusesDispatch :2401-2424 prefers the argument identity and asks core about the quality agent → 0, then openDelegation attributes the window to the developer from the suffix (6ec8715f refused via the generic mutation fallback). (d) With an unresolved opaque-write window (readPlanApprovalLegacyWindows), the guard arm :2649-2678 would refuse, but the dispatch returns at :2636 first and the admitter never consults the windows (6ec8715f: 2, "legacy write did not complete PostToolUse mediation").

The requirement, rather than a prescription: a gate must not fail open when the admitter did not run, and a refusal after admission must not strand the window. Making the admitter and the gates evaluate the same predicate on the same identity (suffix authoritative, the same kiroDispatch derivation the ledger uses, the same legacy-window check) is necessary but I do not think it is sufficient on its own: the core guard's admission path calls beginCodeGeneration (core/hooks/aidlc-plan-approval-guard.ts:1007-1037), which mutates state under withAuditLock — publishes the generation boundary, rebases the receipt, and throws on source drift or lock contention (core/tools/aidlc-testing-posture.ts:2461-2555) — so two separate evaluations of the "same" predicate are not atomic and the second can refuse where the first admitted. Whatever shape you choose, please test it under both hook orders (admitter first, gate first), with an intervening source change between the two evaluations under strict and relaxed Change Control, and with the two hooks running concurrently, and add t147 cases for (a)–(c). Note t147:1253-1260 and t218:1583-1585 currently pin the stand-down (weakened from asserting 2).

2. P2 — Admission depends on an exact PreToolUse spelling that the repo's own captures and Kiro's docs contradict. ide.event is the raw string (:815, :859); the admitter runs only at :1459 === "PreToolUse", :1424 stands down on the name alone, and :3304 gates the completion forward. tests/fixtures/kiro-hook-payloads/payloads.json (verbatim captures) and https://kiro.dev/docs/hooks/types/ spell preToolUse. On that spelling the floor has no owner for any dispatch, and the Pre-edge registration writes a SUBAGENT_COMPLETED row at dispatch time (including for a refused developer dispatch). Your live v3 and IDE 1.x runs opened windows, which means those hosts sent PascalCase — so this may be a fixture-era spelling; but e6b0c0a58 made the question load-bearing for a fail-open. Please normalise case at parse and drive one admission case with the fixture payload verbatim; the round-2 request to record the observed spelling per host in kiro-ide-hook-payload.md still stands.

3. P2 — planApprovalRefusesDispatch discards the core hook's output. :2414-2428 reduces runCoreHook to .code === 2. Refusal: the AIDLC-UNIT / AIDLC-TESTING-CONTRACT remedy is replaced by the generic line at :1481-1487, so the conductor has no deterministic retry (6ec8715f relayed it via :3544). Admission: under relaxed Change Control the core hook's beginCodeGeneration records CHANGE_ACCEPTED and prints the one-time "1 file changed since this plan was approved…" notice — recorded, never surfaced. Please relay stdout and stderr from the admission call.

Non-blocking

• P3 shipsNativeTrustFile (core/tools/aidlc-config-diagnostics.ts:1930-1938) casts parsed JSON: {}, [], 42, rootIntegrations:null with .vscode/settings.json deleted → trust --check reports clean. Malformed JSON and a missing file correctly fail.
• P3 isDispatchToolName accepts bare subagent_ (:2349-2354); the matcher subagent_.+ never delivers it, so both gates stand down and nothing admits. Not observed from a host.
• P3 No test for kiro-projection-descriptor-unreadable, trust --show omitting .vscode/settings.json on a source projection, or the doctor fix text (t243:4119-4121 asserts only no-TypeError).
• Round-2 non-blocking items unchanged, as you said. Behaviour change worth a line in the body: a non-developer direct dispatch during code-generation is now forwarded as Task+subagent_type and allowed where round 2 refused it as an unknown mutation-capable tool.

Verified

R3 #1/#2/#3 fixed with controls; retired-stamp doctor/providers --show/models --show on a real base-era kiro-ide install, then upgrade; source/native trust matrix; guard-tool-call exit 2 through both entrypoints on all three shell spellings; bounded stdin on the now-input-dependent gate; 502cefed byte-identical to the clean merge-tree of e6b0c0a58×d378d0df; merged-tree validation as above.

Remaining risk

Unchanged: no completed Construction tail, and #1 sits exactly where round 3's did. The author-admitted crash/cancel/malformed-Post leaks are neither better nor worse. CI on 502cefed is green.

Recommendation: changes requested for #1–#3.