docs: finish reconciling the agent write fence across the toolchain

The previous round taught agent-audit's validator to permit disallowedTools but
left the skill that writes agents still forbidding it, in six places. Running
agent-author on any of the three fenced orchestrators would have stripped the
fence, and nothing would have caught it: the validator's allowlist is a permit
list, so an absent field passes. The template was the worst of them, since its
comment is copied verbatim into every new plugin-scope agent.

Where a list had to be restated it is now a pointer to field-inventory.md's
apm-agent-allowlist instead -- the same data validate.sh reads -- because a
roster copied into a template goes stale one step further out than the roster
itself. Where the text has to teach something it teaches the shape rule rather
than the exception: tools is an allowlist whose vocabulary differs per harness,
so verbatim copy makes one value wrong on one target; disallowedTools is a
denylist, where an unrecognised name denies nothing, so the worst case is a
missing fence rather than a wrongly granted capability.

ADR-0016's amendment claimed an unrecognised key is inert on Copilot while the
same ADR's Context says that behaviour is unconfirmed by research -- asserting
as settled the exact thing it flags as unknown, and justifying it with apm's
compile-time behaviour, which says nothing about Copilot's runtime. It is
rewritten into labelled tiers: confirmed for Claude Code with citations,
inferred by analogy for Copilot with the analogy's limits stated, unverified
where it is unverified, and the residual risk accepted explicitly with its
blast radius. It also no longer claims to restore a write sandbox: the denylist
does not deny Bash, which these agents inherit and legitimately need.

docs/hooks.md called the old root hooks.json a stale sync artifact -- it was
added in the plugin's creating commit and pointed at by main's Copilot manifest
-- and claimed both ecosystems now resolve hooks/hooks.json. Copilot does not:
its hooks field has no default and no compiled manifest declares one, so it
resolves nothing. Recorded as the gap it is, with re-injection noted as a
follow-up rather than asserted away. Its event list is marked partial.

Also: new-agent.bats asserted a hardcoded four-field allowlist and would have
rejected a scaffolded agent carrying the field the ADR now blesses; it reads
field-inventory.md too. And ADR-0016's premise that Claude's tools: is
space-separated was wrong -- it takes a comma-separated string or a YAML list.
The incompatibility with Copilot is the vocabulary, not the punctuation.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01X7GvKuJfy2WrdBmUttV4DT

docs/adr/0015-apm-replaces-plugin-marketplace-authoring.md

@@ -118,8 +118,10 @@ correction) sorted what they document into three buckets:
   match.
 - ADR-0016 (a narrower decision discovered while designing issue #89) turned out to gate how
   issue #90 had to re-author plugin-scope agents: `.apm/agents/*.agent.md` compiles verbatim to
-  both Claude and Copilot, so those files carry only `name`/`description`/`model`/`source_keys` —
-  existing dual-file `<name>.md`+`<name>.agent.md` pairs could not be raw-moved, only re-authored.
+  both Claude and Copilot, so those files carry only the fields in the `apm-agent-allowlist` section
+  of `plugins/kyberforge/.apm/skills/agent-audit/references/field-inventory.md` (as amended
+  2026-08-14: `name`/`description`/`model`/`source_keys`/`disallowedTools`) — existing dual-file
+  `<name>.md`+`<name>.agent.md` pairs could not be raw-moved, only re-authored.
 - Two follow-up issues tracked the remaining work: #89 (`skill-author`/`agent-author` routing
   adaptation — closed, merged in #93) and #90 (the actual repo conversion, which also deleted
   `plugin-author`/`marketplace-author` — tracked through to merge; treat #90's own state as the

docs/adr/0016-apm-agent-primitive-drops-provider-specific-fields.md

@@ -22,13 +22,17 @@ Code and Copilot CLI targets. This is unlike:
 Because the agent primitive ships the same frontmatter unchanged to both harnesses, two
 concrete incompatibilities surface:
 
-1. **`tools:`** — Claude Code expects a space-separated tool-name string; Copilot CLI expects a
-   list drawn from its own alias vocabulary (`execute`/`read`/`edit`/`search`/`agent`/`web`). A
-   value correct for one harness is wrong for the other.
+1. **`tools:`** — Claude Code expects tool names drawn from its own vocabulary, as a
+   comma-separated string or a YAML list (`agent-definition.md:37`); Copilot CLI expects a list
+   drawn from a different alias vocabulary (`execute`/`read`/`edit`/`search`/`agent`/`web`). The
+   incompatibility is the vocabulary, not the punctuation: a value correct for one harness names
+   tools the other does not have.
 2. **Claude-only knobs with no Copilot equivalent** — `isolation`, `maxTurns`, `effort`,
    `memory`, `permissionMode`. Writing any of these means Copilot's copy carries frontmatter
    keys it doesn't recognize at all. Whether Copilot's agent loader ignores unknown keys or
-   errors on them is unconfirmed by research.
+   errors on them is unconfirmed by research. *(Still unconfirmed as of the 2026-08-14 amendment
+   below, which admits `disallowedTools` as an explicitly accepted risk rather than by resolving
+   this question.)*
 
 ## Decision
 
@@ -81,25 +85,61 @@ delimited string of its own tool names, Copilot CLI reads it as a list drawn fro
 alias vocabulary (`execute`/`read`/`edit`/`search`/`agent`/`web`), so one value is wrong on one
 harness. That reasoning stands, and `tools:` stays out of every plugin-scope agent.
 
-A **denylist** has no such conflict.
+A **denylist** has no such conflict. The evidence for that splits three ways, and this amendment
+states which part is which rather than asserting the whole as settled.
+
+**Confirmed — Claude Code honours it for plugin subagents.**
 `plugins/kyberforge/docs/research/docs/claude-code-plugins/agent-definition.md:39` documents
 `disallowedTools` as a "Denylist applied before `tools`… Takes precedence over `tools`", and — the
 part that matters here — it is **not** in that document's plugin-subagent ignore list. Line 99
 names exactly three fields plugin agents silently ignore: `hooks`, `mcpServers`, `permissionMode`.
-`disallowedTools` is absent from that list, so it is honoured for plugin agents. On the Copilot
-side, the same verbatim-copy behaviour that makes `tools:` dangerous makes `disallowedTools`
-harmless: an unrecognised frontmatter key is inert, and unlike a wrong `tools:` value it cannot
-grant or misroute anything — the worst case is that the fence is absent on that harness, which is
-the status quo the decision above already accepted.
+`disallowedTools` is absent from that list. Claude Code is also the harness where the fence is
+actually wanted, so the field earns its place on this evidence alone.
+
+**Inferred — the field is very likely inert on Copilot CLI, but by analogy, not by documentation.**
+`plugins/kyberforge/docs/research/docs/github-copilot-plugins/troubleshooting.md:50` and `:53`
+record Copilot *silently ignoring* two agent frontmatter fields it does not process (`mcp-servers`
+and `metadata` outside the cloud runtime) rather than erroring on them. That is a documented
+tolerance for *known-but-unprocessed* keys, which is adjacent to, not identical to, tolerance for
+an *unknown* key. No stronger evidence exists: a sweep of the vendored Copilot corpus
+(`agent-definition.md`, `api-reference.md`, `troubleshooting.md`, `configuration.md`) documents
+unknown-key handling nowhere.
+
+**Unverified — Copilot's loader behaviour on an unrecognised key.** Context item 2 above says this
+is unconfirmed by research and that remains true; nothing found since changes it. An earlier
+revision of this amendment claimed "an unrecognised frontmatter key is inert" as settled fact and
+attributed it to apm's verbatim-copy behaviour. That attribution was a non-sequitur — verbatim copy
+describes what *apm* does at compile time and says nothing about what *Copilot* does at load time —
+and the claim contradicted this ADR's own Context section.
+
+**So this is an accepted risk, stated as one.** Blast radius if the inference is wrong and Copilot
+errors on the key: the three affected plugin-scope agents fail to load under Copilot CLI. It is
+loud, not silent; it is confined to three agents in three plugins; no other primitive and no Claude
+Code path is affected; and the remedy is a one-line frontmatter deletion. What the denylist shape
+*does* rule out categorically — independent of loader behaviour — is the failure mode that motivated
+dropping `tools:` in the first place: a denied name the other harness does not recognise denies
+nothing, so a mis-shaped value can never grant or misroute a capability. The risk is a load failure,
+never a silent over-grant. That asymmetry is why the same verbatim copy that makes `tools:`
+unshippable makes `disallowedTools` worth shipping.
 
 So the read-only orchestrator agents regain their write fence: `gitea-orchestrate`,
 `apm-orchestrate` and `lint-runner` each carry `disallowedTools: Edit, Write, NotebookEdit` plus
 explicit prose in the body stating the agent does not edit files. `git-orchestrate` is deliberately
 excluded — it legitimately declared `edit` before the conversion and still needs to write.
 
-Net position: the allowlist stays dropped for the reason originally given; the specific capability
-that mattered (preventing a read-only orchestrator from writing) is restored by the one mechanism
-that is portable by construction. The consequence below is narrowed accordingly.
+**Residual — the fence is partial, and the prose is doing more of the work than the field is.**
+`disallowedTools: Edit, Write, NotebookEdit` denies exactly those three tools. It does not deny
+`Bash`, and at plugin scope these agents carry no `tools:` and therefore inherit it, so
+`bash -c 'echo … > f'` remains unfenced by frontmatter. Only the body prose covers that path. This
+is not a regression introduced here — the pre-conversion `tools:` allowlists also granted `Bash`,
+so the shell route was open then too — but the ADR should not credit the mechanism with more than
+it delivers. Closing it would need a `disallowedTools` entry for `Bash`, which these agents cannot
+take because they legitimately shell out.
+
+Net position: the allowlist stays dropped for the reason originally given, and the denylist is
+admitted as the portable-by-construction half of what was lost. It restores a real, Claude-Code-
+confirmed write fence against the tool-call path, not a complete write sandbox. The consequence
+below is narrowed accordingly.
 
 Enforcement follows the decision: `agent-audit`'s plugin-scope validator reads its allowlist as
 data from the `apm-agent-allowlist` section of
@@ -126,7 +166,9 @@ whether a field is safe under verbatim copy in a single vendor-neutral file.
   lists from `references/field-inventory.md` rather than hardcoding them, with a `source_keys`
   provenance chain — survives and is reused. Only the *content shape* changes for plugin scope:
   `field-inventory.md` shifts from two side-by-side CC-only/Copilot-only blocklists to one
-  vendor-neutral allowlist (`name`/`description`/`model`/`source_keys` — the last for provenance
-  tracking, validated separately by `validate-provenance.sh` against `sources.md`, not a
-  provider-specific field) for plugin-scope agents, while
-  continuing to serve its original two-blocklist role for project/user-scope validation.
+  vendor-neutral allowlist for plugin-scope agents, while continuing to serve its original
+  two-blocklist role for project/user-scope validation. That file's `apm-agent-allowlist` section
+  is the authoritative list and is read as data by `validate.sh`; as amended on 2026-08-14 it holds
+  `name`/`description`/`model`/`source_keys`/`disallowedTools` — `source_keys` for provenance
+  tracking, validated separately by `validate-provenance.sh` against `sources.md` rather than being
+  a provider-specific field, and `disallowedTools` per the amendment above.