Defame1297
05bb9d6e9f
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>
33 lines
1.7 KiB
Markdown
33 lines
1.7 KiB
Markdown
# 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 info` in the result block.
|
|
- `skill-improve` currently 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.
|