docs: triage v0.4.0 release truth

CHANGELOG.md

@@ -20,7 +20,7 @@ This project has a published GitHub Release line, but no stable support or API g
 - Added a read-only security and supply-chain evaluation record for CodeQL, private vulnerability reporting, Dependabot, Scorecard, and GitHub Actions pinning.
 - Added a non-required Python 3.13 compatibility CI job without changing the protected Python 3.12 required check name.
 - Added a local post-release audit script for repeatable maintainer verification.
-- Documented the v0.3.0 post-release audit findings and v0.3.1 maintenance hardening target.
+- Documented the v0.3.0 post-release audit findings and the earlier maintenance hardening target; the current release boundary is now v0.4.0 because current main includes the new `dedupe` and `conflicts` command surfaces.
 
 ### Changed
 

docs/POST-AUDIT-ACTION-PLAN-CURRENT-MAIN.md

@@ -148,11 +148,11 @@ Minimum core files to include:
 
 ### H-01: SECURITY-SUPPLY-CHAIN-EVALUATION action versions are stale
 
-Status: open.
+Status: closed by PR #121.
 
 docs/SECURITY-SUPPLY-CHAIN-EVALUATION.md still mentions older GitHub Actions versions, while current workflows include actions/checkout@v7 and actions/download-artifact@v8.
 
-Required phase:
+Completed phase:
 
 - docs/sync-supply-chain-evaluation-action-versions
 
@@ -165,11 +165,11 @@ Acceptance criteria:
 
 ### H-02: dedupe and conflicts need CLI error-contract tests
 
-Status: open.
+Status: closed by PR #122.
 
 Before publishing dedupe and conflicts in v0.4.0, their error paths need tests matching docs/OUTPUTS.md and docs/EXIT-CODES.md.
 
-Required phase:
+Completed phase:
 
 - test/add-dedupe-conflicts-error-contracts
 
@@ -185,11 +185,11 @@ Acceptance criteria:
 
 ### H-03: conflicts needs rule-family fixtures
 
-Status: open.
+Status: closed by PR #123.
 
 conflicts is more reputation-sensitive than dedupe because it reports contradictory guidance. It needs coverage for the implemented families, not broad semantic analysis.
 
-Required phase:
+Completed phase:
 
 - test/add-conflicts-rule-family-fixtures
 
@@ -206,11 +206,11 @@ Acceptance criteria:
 
 ### H-04: dedupe needs a representative golden or contract test
 
-Status: open.
+Status: closed by PR #124.
 
 dedupe is a new v0.4.0 command surface and needs a stable representative output contract.
 
-Required phase:
+Completed phase:
 
 - test/add-dedupe-golden-contract
 
@@ -222,11 +222,11 @@ Acceptance criteria:
 
 ### M-01: symlink behavior needs clearer documentation
 
-Status: open.
+Status: closed by PR #125.
 
 check degrades symlinked supported instruction files to SYS002 findings, while budget, dedupe, and conflicts fail hard with exit code 2. This can be valid, but must be documented as a deliberate UX and safety choice.
 
-Required phase:
+Completed phase:
 
 - docs/sync-outputs-symlink-behavior-clarification
 
@@ -239,11 +239,11 @@ Acceptance criteria:
 
 ### M-02: Python 3.13 classifier decision
 
-Status: open.
+Status: closed by PR #126.
 
 The project has a Python 3.13 compatibility job, but package classifiers currently communicate only Python 3.12 support.
 
-Required phase:
+Completed phase:
 
 - packaging/sync-python-313-classifier
 

docs/PRODUCT-STRATEGY.md

@@ -6,7 +6,7 @@ It is a strategy document, not an implementation plan for a specific feature. It
 
 ## Current product truth
 
-agent-rules-kit has a published v0.3.0 GitHub Release and PyPI package line. `v0.2.3` remains the previous published GitHub Release and PyPI package baseline. Current main contains post-v0.3.0 maintenance hardening intended for a future patch release.
+agent-rules-kit has a published v0.3.0 GitHub Release and PyPI package line. `v0.2.3` remains the previous published GitHub Release and PyPI package baseline. Current main contains post-v0.3.0 `dedupe` and `conflicts` command additions plus maintenance hardening. The next public release target is v0.4.0, not a v0.3.x patch, because the new commands expand the compatible command surface.
 
 The implemented product currently supports:
 
@@ -272,7 +272,7 @@ The next implementation phase should be justified against the current repository
 
 Good next candidates are narrow and evidence-backed:
 
-- v0.3.1 maintenance hardening before new product features;
+- v0.4.0 release preparation for the current `dedupe` and `conflicts` command additions, after final audit evidence is complete;
 - release and package smoke hardening;
 - README, support, security, and strategy public-truth checks;
 - supply-chain workflow additions only after dedicated evaluation phases;
@@ -288,7 +288,7 @@ Decision: keep product strategy as the boundary document after v0.2.
 Reason:
 
 - v0.3.0 already published the local diagnosis toolkit baseline;
-- current main contains post-v0.3.0 maintenance hardening that should become a future patch release;
+- current main contains post-v0.3.0 `dedupe` and `conflicts` command additions plus maintenance hardening that must be released, if approved, as v0.4.0 rather than a patch release;
 - adjacent tools still cover repository packaging, context frameworks, and broad rule generation better than this project should;
 - the real product wedge remains instruction governance;
 - future features must be justified against this document to avoid scope drift.