Defame1297/holocron
0
0
Fork 0
Code Issues 14 Pull Requests Actions Packages Projects Releases 3 Wiki Activity
Files
ffcbed6c41c3807da14dc0976ce89d251cfa4d1c
holocron/docs/adr/0016-apm-agent-primitive-drops-provider-specific-fields.md
Defame1297 620f20b0fd refactor(kyberforge)!: merge skill-audit and agent-audit into factory-audit 
Why

The two audit skills carried 1,724 lines of byte-identical duplication: the ADR-0020 boundary
resolver (1,061), vale-wrap.sh (526), the Vale style rules (44) and the Contributing-files parser
(93). Nothing shared them — they were held in sync by a 413-line pre-push gate and its 797-line
test suite. Sync-by-gate had already failed once: at 484357a the two parser copies drifted into
different spellings of the bullet loop while a docstring asserted they were identical. That drift
was behaviour-neutral and was re-unified by hand at 598a7c3, so the copies were identical at merge
time — but nothing had caught it, and the next drift need not be neutral.

Implementation Notes

Self-containment binds BETWEEN skills, not within one. The agentskills.io spec forbids reaching
across skill directories, which is why two separate skills needed embedded copies; two files inside
ONE skill may source a third. That is the whole reason the merge removes duplication rather than
relocating it.

The union of both bodies measured 1,532 words against BODY_MAX_WORDS=900, and only 211 of those
words were shared, so SKILL.md is a dispatch body. Step 0 resolves the flow from the target path
before any validation, and its table mirrors validate.sh's detection exactly: a directory holding
SKILL.md or a SKILL.md file (skill); a *.agent.md, or a .md directly under an agents/ directory
(agent); anything else stops without running a validator. Steps 1-3 live in
references/skill-flow.md and references/agent-flow.md, and gotchas that apply to one flow live in
that flow's file, since it is loaded on every invocation anyway. If validate.sh reports on the
other artifact type, the body restarts at Step 0.

Named factory-audit rather than forge-audit because forge is a live skill, and a family prefix that
matches a live sibling reads as ownership rather than membership.

The description carries one arrow per boundary target, because ADR-0020 resolves only the first
target after an arrow. It drops the quoted "audit this skill"-style phrases, which restated
"audited" in a second register (ADR-0020's duplicate-register rule). 241 characters, Gotchas 16%
of the body: no size SUGGESTIONs.

The boundary resolver stays embedded in two files rather than imported: a cache-installed plugin
cannot read outside its own directory, and the repo-root hook resolves via .pre-commit-hooks.yaml
where entry[0] is the only token pre-commit rewrites, so no single file is reachable by both.
tests/test-adr0020-contract.sh hashes both copies for byte-identity, and asserts validate.sh sources
the resolver and that no third copy exists.

The entry scripts classify the target from its resolved parent directory, so a bare agent filename
typed inside agents/ works; resolve SCRIPT_DIR CDPATH-safely; and exit 2 when a lib-*.sh is
missing, rather than dying with exit 1, the tier the flows relay as real findings.

The provenance run functions stash their findings code in KYBERFORGE_PROV_RC and
return 0, so validate-provenance.sh calls them UNTESTED. Testing a function's
status (`f || RC=$?`) disables errexit for its entire body, and no subshell or
`set -e` inside can re-arm it once the call sits in a condition context
(measured, both spellings). Their error paths use `exit`, which is unaffected
either way; this keeps errexit armed for anything added later.

Case 0's readability guard reads the file instead of asking `[[ -r ]]`. `-r` is
access(2), which answers yes for uid 0 even on a mode-000 file, and this repo's
dev environment is root -- so the guard could never fire where it exists to fire.
A read attempt is also the stricter question, catching EIO. This is the reasoning
scripts/check-vale-style-sync.sh carried before this commit deleted it; the
hazard did not go with it.

All three entry scripts are CDPATH-safe, vale-wrap.sh included: both of its cd sites are cleared,
the --config resolution and the directory-mirror walk, where an exported CDPATH would otherwise
print a decoy path into the -print0 stream and build the mirror from the decoy's files. The two
remaining bare cd calls take absolute paths, which CDPATH is never consulted for.

Impact

BREAKING: skill-audit and agent-audit no longer exist as invocable skills. kyberforge goes to
2.0.0 (catalog 0.4.7).

Check logic is unchanged: differential runs of the old and new validators across every skill and
agent produced byte-identical stdout, stderr and exit codes, and the reconstructed Python payloads
differ only in comments and the references/field-inventory.md -> agent-field-inventory.md rename.
One doctrine governs the tiers: exit 0 is audited and clean, exit 1 is audited with findings OR a
target present but unreadable, exit 2 is that nothing was audited at all. Edge paths DID change,
deliberately (full table in ADR-0025):
- a missing target exits 2 (never ran), not 1, under its own "does not exist" message; detection is
  by path shape, so a shape-matching path that is simply absent used to reach the validator and come
  back as a FAIL against a file that never existed;
- an unshaped target exits 2 under the generic "matches neither" message, and a directory with no
  SKILL.md under a third, distinct one -- three exit-2 messages, not one;
- a dangling symlink or a symlink loop stays exit 1: it is present but broken, which is a finding
  about the artifact rather than a usage error;
- a SKILL.md file path is audited as its skill directory instead of refused;
- a .md agent outside an agents/ directory is refused rather than audited;
- a missing script library, a missing python3, a missing PyYAML, and no argument at all each exit 2.
  validate-provenance.sh already exited 2 for the last two; validate.sh now matches it.

.pre-commit-hooks.yaml is a published contract consumed by external repos. Both hook IDs and both
files: regexes are unchanged; only entry: and description: moved.

scripts/check-vale-style-sync.sh (413), scripts/sync-vale-styles.sh (21),
tests/test-check-vale-style-sync.sh (797) and agent-audit/scripts/README.md (47) are deleted. The
checker made 17 assertions: 6 compared the two Vale copies and are moot; 10 are rehomed into
tests/test-vale-wrap.sh (case 0, cases 28-31, and the suite's Vale-absent skip); and the
cross-manifest files: agreement check, which selected hooks by entry: and so could not survive both
hooks sharing one, is ported as case 33 pairing hooks by id:. Cases 28, 30 and 33 carry mutation
self-tests; narrowing the local skill prefilter to 6 of 38 SKILL.md files now fails the suite.

Skills go 39 to 38. Pre-push goes 9 repo-authored hooks to 8.

ADR: 0025
BREAKING-CHANGE: the skill-audit and agent-audit skills are removed. Both flows are served by
  factory-audit, which auto-detects whether it was handed a skill directory or an agent file.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YR2CjVumUbEGWcMikcoXBD
2026-09-16 09:13:57 +00:00

176 lines
12 KiB
Markdown
Raw Blame History

# Plugin-scope agent-author omits `tools:` and all Claude-only fields from `.apm/agents/*.agent.md`
This ADR is a narrower, downstream consequence discovered while designing issue #89's
implementation under ADR-0015's broader direction (Microsoft APM replaces hand-authored
plugin/marketplace authoring). It does not restate ADR-0015's rationale — see that ADR for
the parent decision.
## Context
APM's agent primitive (`.apm/agents/<name>.agent.md`) has no per-target integrator in
`apm compile` — confirmed via APM's own Python source (`integration/targets.py` and related
files, cited in `plugins/kyberforge/docs/research/docs/microsoft-apm/agent-primitive-schema.md`).
Compilation does a naive verbatim copy of the whole frontmatter and body to both the Claude
Code and Copilot CLI targets. This is unlike:
- The **skill** primitive, which is also a straight copy (confirmed in the same research doc)
but has no field semantics to conflict — `SKILL.md`'s content is target-agnostic already.
- The **prompt**, **instructions**, and **hooks** primitives, which each get real per-target
reconstruction through a dedicated integrator (field allowlisting, key renaming, dropped-field
warnings).
Because the agent primitive ships the same frontmatter unchanged to both harnesses, two
concrete incompatibilities surface:
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. *(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
At **plugin scope only** (destination package has an `apm.yml` at its root — an APM producer
package compiled via `apm compile`), `.apm/agents/<name>.agent.md` carries only `name`,
`description`, `model`, and the prose body. No `tools:` field, no Claude-only fields, at all.
*(Narrowed by the 2026-08-14 amendment below: `disallowedTools` is admitted as a fifth allowed
field. `tools:` and every other Claude-only knob remain excluded on the reasoning given here.)*
Absent `tools:` means inherit-all-tools on both harnesses — the one value that is never wrong
on either target, unlike a present, harness-specific value that is guaranteed wrong on at least
one of them.
`agent-audit`, at plugin scope, is intended to flag — as a **SUGGESTION**, not a FAIL, since
this is an upstream schema limitation rather than an authoring mistake — any agent whose
description or body implies a need for tool restriction or a Claude-only behavior the
frontmatter can no longer express. This would give visibility into the gap without pretending
the schema can do something it can't. **Not yet implemented**: `check_apm_agent_file()` in
`validate.sh` currently validates only the field allowlist, `name`, `description`, and
body-emptiness/length — it has no heuristic for this case. Tracked as follow-up work.
### Scope boundary
This decision applies to **plugin-scope `agent-author` only**. Project scope (`.claude/agents/`
+ `.github/agents/`) and user scope (`~/.claude/agents/` + `~/.copilot/agents/`) are not APM
packages — neither goes through `apm compile` — so both keep today's dual-file Claude+Copilot
pair model exactly as ADR-0005 and ADR-0008 already describe. Those two ADRs remain fully
authoritative for project and user scope; only their plugin-scope clauses are affected by this
ADR (see the update notes appended to each).
## Considered options
**Pick one harness's vocabulary and accept breakage on the other (rejected).** E.g. always
write Claude's space-separated `tools:` string. Rejected because it ships a value that is
silently wrong (or possibly a hard error) on Copilot, and which harness "wins" would be an
arbitrary, undocumented asymmetry.
**Same as above, but `agent-audit` flags the cross-harness breakage as a tracked finding
(rejected).** Rejected for the same core reason — it still ships a wrong value to a real
harness. Tracking the breakage doesn't prevent it, and the chosen decision already gets
equivalent visibility (a SUGGESTION finding) without ever shipping the wrong value in the first
place.
## Amendment (2026-08-14): the write fence comes back as a denylist
The decision above generalised from `tools:` to "no tool restriction at all". That over-reached.
The unportability argument is specific to the **allowlist**: Claude Code reads `tools:` as a
delimited string of its own tool names, Copilot CLI reads it as a list drawn from its
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. 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. 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.
**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
`plugins/kyberforge/.apm/skills/agent-audit/references/field-inventory.md` (now
`factory-audit/references/agent-field-inventory.md`, see ADR-0025), and that line now reads
`name description model source_keys disallowedTools`. `disallowedTools` also stays in that file's
`claude-code-only-fields` list, which is not a contradiction — that list governs whether a field
may cross the CC/Copilot boundary in a real project/user-scope *pair*, a different question from
whether a field is safe under verbatim copy in a single vendor-neutral file.
## Consequences
- Every plugin-scope APM agent loses per-agent tool *allowlisting* and any Claude-only capability
(isolation, maxTurns, effort, memory, permissionMode) until APM ships a real per-target
integrator for the agent primitive. This is a known, accepted regression, not an oversight.
Tool **denial** is not part of that loss — see the 2026-08-14 amendment above.
- **ADR-0005 is partially superseded** — its plugin-scope clause ("directory containing
`plugin.json` is plugin scope → both files land in `<root>/agents/`") no longer applies.
Plugin scope is now "directory containing `apm.yml` → single vendor-neutral file lands in
`<root>/.apm/agents/`." Project and user scope, and the rest of ADR-0005, are unaffected.
- **ADR-0008 is partially superseded** — its counterpart-derivation/pair-validation mechanism
no longer applies at plugin scope; `agent-audit` takes the single file directly there. Project
and user scope, where a real pair still exists, are unaffected.
- **ADR-0009 is not superseded.** The mechanism it established — `agent-audit` reading field
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 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.
Reference in New Issue View Git Blame Copy Permalink