-
Gitea user account used by Claude Code with Gitea MCP to manage repositories: read/write issues and PRs, comment on changes, and perform merge/review actions with appropriate permissions.
- Joined on
2026-06-20
Process step 2 still tells the orchestrator to check the Hard rules for "secret indirection," but that Hard Rule bullet was deleted from the Hard rules section in this same PR's fix commit (e16c3dc), leaving a dangling reference to a rule that no longer exists.
ADR-0015 states "CONTEXT.md's Plugin/Skill/Plugin-marketplace glossary entries remain accurate as written until issue #90 actually executes — this ADR does not update them," but this same PR's fix commit (e16c3dc) edited CONTEXT.md's Plugin and Plugin marketplace entries to add an ADR-0015 forward-pointer sentence.
All findings addressed in e16c3dc (pushed). Threaded replies 405'd on this Gitea instance's API, so consolidating responses here instead of inline.
Fixed:
- [ADR-0015 Decision/Consequences…
Ran a full multi-agent PR review (/code-review high) against PR #91, which implements this issue's three artifacts. Posted 10 inline findings there: https://git.dev.rkdr.net/Defame1297/holocron/p…
This Decision bullet states 'This directly supersedes ADR-0001' as a present-tense fact, but the Consequences section (line 63) says 'ADR-0001 is superseded once issue #90 executes' — a future, conditional event. The same document licenses opposite conclusions depending which section a reader lands on. Pick one framing (recommend: conditional, matching Consequences) and make the Decision bullet match it.
This says CONTEXT.md's Plugin/Skill/Plugin-marketplace glossary 'remains accurate as written until issue #90', but neither CONTEXT.md nor ADR-0001 gets any status marker or forward-pointer to this ADR. CONTEXT.md is mandated reading 'at the start of every session' per AGENTS.md, and this repo's own convention elsewhere (e.g. ADR-0007/ADR-0010) is to add an inline 'Superseded by' / 'Update' note on the older doc. Without that, an agent consulting CONTEXT.md or ADR-0001 directly has no signal a foundational change is pending and will keep hand-authoring plugin.json/marketplace.json exactly as this ADR says is being phased out.
The rationale for rejecting a standalone plugins/apm/ plugin claims this tooling's scope is 'specifically converting this repo's marketplace, not standing up a reusable generic apm toolkit' — but the shipped apm-install/apm-workflow SKILL.md files are fully generic, repo-agnostic APM CLI documentation with essentially no holocron-specific content. The stated justification doesn't match what was actually built, which will make the placement decision look post-hoc to a future reviewer.
Attributes the .agent.md extension to the future APM conversion ('needs revisiting once agents move under .apm/agents/ with the .agent.md extension'), but .agent.md is this repo's pre-existing Copilot-pairing convention (ADR-0005/ADR-0010), already in use by this very diff's own apm-orchestrate.agent.md. Whoever executes #90 could read this as license to redesign an already-settled, orthogonal naming convention that has nothing to do with the APM move.
This Hard Rule governs 'any apm.yml content this orchestrator writes or edits', but the agent declares only tools: Bash, Read (line 6) and its own Scope (line 13) states it 'does not decide manifest content yourself, you delegate' — it has no Edit/Write tool and never touches apm.yml directly. The rule it exists to enforce has no code path that ever fires; it reads as an active safety gate but is dead text. Either grant the capability this rule assumes, or move the rule to wherever manifest content actually gets written.
The compile-manifest-check operation has no corresponding apm CLI command anywhere in apm-workflow's references or the shipped microsoft-apm research docs (verified by grep across both). An executing agent dispatched this operation has to invent behavior since nothing documents what to actually run.
add-package and add-marketplace are never mapped to their underlying apm marketplace package add / apm marketplace add commands anywhere in this file, despite this same file's Hard Rule insisting these two directions must 'never guess from context alone.' An executing agent has no explicit mapping table and could plausibly invert them — exactly the mix-up the adjacent rule was written to prevent.
apm-orchestrate.md and apm-orchestrate.agent.md duplicate ~95% of their content verbatim and have already drifted on the Output section: the .md version gives an explicit JSON schema with enumerated error codes (not_confirmed
Documents a raw git add/git commit/git tag/git push --tags chain as the literal release step. AGENTS.md's 'Prefer plugin skills over raw shell' section states commits/remotes are owned by git:git-commits/git:git-remotes and to fall back to raw shell 'only when no skill covers it' — an agent following this reference verbatim shells out directly in a repo that already has dedicated skills for exactly this operation.
This and the other three apm-workflow reference files (compile.md, audit.md, marketplace.md) restate their sibling research docs under docs/research/docs/microsoft-apm/ nearly verbatim (same command lists, same caveats, same CI YAML block in audit.md) — two sources of truth for the same facts. An upstream apm flag/behavior change applied to the research doc (the stated source of truth) can be missed here, leaving the actionable skill guidance silently stale while looking equally authoritative. Consider having these reference files point at the research docs rather than duplicating their content.
Full review findings (10 inline comments) — mainly the ADR-0015 self-contradiction (Decision vs. Consequences on when ADR-0001 is superseded) and the undocumented apm-orchestrate operations (compile-manifest-check, add-package/add-marketplace) that aren't grounded in apm-workflow's actual CLI verbs anywhere. Submitted as COMMENT rather than REQUEST_CHANGES — Gitea disallows self-review rejection since author and reviewer are the same account here. Treat the ADR contradiction and the dead Hard Rule (apm-orchestrate.md line 23) as should-fix before merge; the rest are lower-severity consistency/maintainability notes. Details inline.
This says CONTEXT.md's Plugin/Skill/Plugin-marketplace glossary 'remains accurate as written until issue #90', but neither CONTEXT.md nor ADR-0001 gets any status marker or forward-pointer to this ADR. CONTEXT.md is mandated reading 'at the start of every session' per AGENTS.md, and this repo's own convention elsewhere (e.g. ADR-0007/ADR-0010) is to add an inline 'Superseded by' / 'Update' note on the older doc. Without that, an agent consulting CONTEXT.md or ADR-0001 directly has no signal a foundational change is pending and will keep hand-authoring plugin.json/marketplace.json exactly as this ADR says is being phased out.
The rationale for rejecting a standalone plugins/apm/ plugin claims this tooling's scope is 'specifically converting this repo's marketplace, not standing up a reusable generic apm toolkit' — but the shipped apm-install/apm-workflow SKILL.md files are fully generic, repo-agnostic APM CLI documentation with essentially no holocron-specific content. The stated justification doesn't match what was actually built, which will make the placement decision look post-hoc to a future reviewer.
Attributes the .agent.md extension to the future APM conversion ('needs revisiting once agents move under .apm/agents/ with the .agent.md extension'), but .agent.md is this repo's pre-existing Copilot-pairing convention (ADR-0005/ADR-0010), already in use by this very diff's own apm-orchestrate.agent.md. Whoever executes #90 could read this as license to redesign an already-settled, orthogonal naming convention that has nothing to do with the APM move.
Full review via /code-review high (multi-agent, independently converged across 3+ passes then re-verified against the actual files). This diff is all-markdown (ADR-0015, apm-orchestrate agent pair, apm-install/apm-workflow skills, research docs, 2 plugin.json bumps) — no executable code, so findings are documentation self-contradictions and interface gaps rather than crashes. 10 inline findings below, grouped: (1) ADR-0015 internally disagrees with itself on when ADR-0001 is superseded and on its own stated scope-rationale; (2) apm-orchestrate's operation vocabulary (compile-manifest-check, add-package, add-marketplace) isn't grounded in apm-workflow's actual CLI verbs anywhere; (3) a Hard Rule in apm-orchestrate.md can never fire given the agent's declared tools; (4) apm-orchestrate.md and apm-orchestrate.agent.md have already drifted on the Output contract; (5) apm-workflow's reference docs duplicate the research docs and one recommends raw git shell instead of this repo's own git-commits/git-remotes skills; (6) CONTEXT.md's glossary and ADR-0001 get no forward-pointer to ADR-0015 despite both being living documents this ADR claims are affected. None of these are blocking code bugs, but several undermine the PR's own acceptance criteria ("internally consistent with the microsoft-apm research docs") and one (the dead Hard Rule) is a safety-relevant correctness issue in an agent definition. Requesting changes rather than approving outright given the ADR self-contradiction and the undocumented orchestrator operations — both are cheap to fix and load-bearing for issues #89/#90 that build on this.