Complete ADR refactoring for issue #15: ## Changes 1. **Triage archival** — deleted chunk-era ADRs (0001–0003, 0006–0011, 0013); kept active decisions (0004, 0005, 0012, 0014+) 2. **ADR-0004 rewrite** — now reflects plugin-based skill distribution (`plugins/<name>/skills/` + `claude plugin install`) instead of monolithic `.agents/skills/` deployment 3. **Renumber to 0001–0009** — sequential clean slate after archival; all cross-references updated 4. **Content audit** — verified all 9 remaining ADRs for alignment with plugin model, removed stale chunk/deployment language Kept ADRs: 0001–0009 - 0001: Skills distributed via plugins - 0002: Two-tier CLAUDE.md (always-on + on-demand) - 0003: AGENTS.md as provider-agnostic entry point - 0004: INFO finding level in skill-audit - 0005: agent-author dual provider scaffold - 0006: Plugin version parity (version in both manifests) - 0007: Gitea as exclusive issue tracker - 0008: agent-audit single-file invocation - 0009: agent-audit field inventory reference All decisions are active and aligned with current repository state (marketplace/plugin model). Closes #15 (ADR section of acceptance criteria) Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
1.7 KiB
Add INFO as a third finding level in skill-audit reports
skill-audit shipped with two finding levels: FAIL (blocks shipping) and
SUGGESTION (optional improvement). Provenance validation introduced observations
that are worth surfacing but not actionable: a references/*.md file with no
source_keys when sources.md is present, and a skill-level source slug absent
from upstream research docs. Folding these into SUGGESTION would imply they
should be fixed — but retroactive source backfill after a reference file is
written is unreliable and not expected practice. A third level, INFO, is therefore
introduced: observational, no action implied, never changes the pass/fail verdict.
Counted separately in the result block as · P info.
Considered options
SUGGESTION with softer language (rejected) — describe the finding as "worth noting" rather than "should be fixed." Rejected because SUGGESTION already carries an established meaning in the report; softening the language creates ambiguity without changing the semantic level. Downstream consumers (humans, skill-improve) would need to infer intent from prose rather than a stable token.
Suppress entirely (rejected) — omit findings that have no fix. Rejected because the observations are useful for a human reviewing provenance completeness. Silent omission loses information without reducing noise.
Consequences
- Report format gains a third token: FAIL, SUGGESTION, INFO. INFO findings do not
affect pass/fail; counted as
· P infoin the result block. skill-improvecurrently ignores anything below FAIL — that behavior remains correct; INFO findings are not forwarded to it.- Future soft observations should use INFO rather than SUGGESTION when no fix is actionable.