Repository navigation
docs(spec): propose uninstall reachability conformance - #3331
Draft
Daniel Meppiel (danielmeppiel) wants to merge 4 commits into
Draft
Daniel Meppiel (danielmeppiel) wants to merge 4 commits into
Daniel Meppiel (danielmeppiel) wants to merge 4 commits into
Conversation
Related to #2270. Draft amendment only; classification, review and publication remain pending. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: b9e09d66-a487-47cf-a05a-5ae014d3ab12
Preserve the public policy amendment alongside proposed req-lk-024 and regenerate the full conformance inventory. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: b9e09d66-a487-47cf-a05a-5ae014d3ab12
Collaborator
Author
APM Spec Guardian:
|
| Panel | Assessment | Shocked | New B | New R | New N |
|---|---|---|---|---|---|
| Swagger / OpenAPI editor | ship_with_followups | 8/10 | 0 | 2 | 2 |
| OCI distribution editor | ship_with_followups | 8/10 | 0 | 3 | 2 |
| Package-manager contract editor | ship_with_followups | 8/10 | 0 | 4 | 3 |
| Web-platform architect | ship_with_followups | 7/10 | 0 | 4 | 2 |
B = new blocking findings, R = new recommended, N = new nits.
Counts are signal strength, not gates. The maintainer decides the next action.
Convergent themes (flagged by 2+ panels)
- T1 -- Forward reference to proposed req-lk-024 in the Section 5.2 per-entry field table embeds pending-amendment behavioral claims in stable metadata (supporting: sw-rec-r1-2, oci-nit-r1-1, pkg-rec-r1-4, tag-nit-r1-1)
- T2 -- Appendix D structural divergence: separate heading and table for the Formalize a spec requirement for uninstall reachability preservation (req-lk-0XX) #2270 entry unlike other proposed amendments (supporting: sw-nit-r1-1, pkg-nit-r1-1, tag-rec-r1-3)
- T3 -- Diagnostic clause completeness: cross-reference gap and visibility-level specification in Section 5.2.2 paragraph 3 (supporting: oci-rec-r1-2, pkg-rec-r1-3)
- T4 -- Definitional precision: terms used by normative req-lk-024 text lack formal vocabulary binding or labeled anchors (supporting: pkg-rec-r1-2, tag-rec-r1-1)
Fold now (5 item(s))
- [F1 / T1] docs/src/content/docs/specs/openapm-v0.1.md:1040 -- Section 5.2 per-entry field table, resolved_by row -- Replace the sentence 'Proposed req-lk-024 repairs a removed parent's anchor to a verified surviving parent during uninstall.' with a non-normative editorial note such as 'See proposed Section 5.2.2 for a pending amendment affecting this field.' Retain the existing 'Not a complete incoming-edge set.' sentence which all four panels cited as valuable clarification. Within Formalize a spec requirement for uninstall reachability preservation (req-lk-0XX) #2270 scope: the forward-reference sentence was introduced by this PR.
Success criterion:grep -c 'repairs a removed parent' on line 1040 returns 0; grep 'Not a complete incoming-edge set' on line 1040 returns 1. - [F2 / standalone] docs/src/content/docs/specs/openapm-v0.1.md:3834-3836 -- Section 10.7 Unverified content cleanup mitigations prose -- After the final mitigation sentence ending at line 3836 ('Containment alone does not establish ownership or authorize deletion of existing content.'), append: 'Proposed req-lk-024 preserves reachable entries and fails closed on uncertain evidence during uninstall-time orphan cleanup.' Use 'Proposed' prefix to retain pending status per Section 9.3. Within Formalize a spec requirement for uninstall reachability preservation (req-lk-0XX) #2270 scope: this cross-reference addresses the threat-model gap created by the new requirement.
Success criterion:grep 'req-lk-024' docs/src/content/docs/specs/openapm-v0.1.md returns a hit within the Section 10.7 prose (lines 3822-3836). - [F3 / standalone] docs/src/content/docs/specs/openapm-v0.1.md:3901 -- Section 10.11 summary-table row 7 (Unverified content cleanup) -- In summary-table row 7 at line 3901, append ', proposed req-lk-024' to the existing mitigations cell after 'self-entry isolation' and before the closing '|'. Use 'proposed' to retain pending status. Within Formalize a spec requirement for uninstall reachability preservation (req-lk-0XX) #2270 scope: completes the threat-model cross-reference for the new requirement.
Success criterion:grep 'req-lk-024' on summary-table row 7 (line 3901) returns one hit. - [F4 / T3] docs/src/content/docs/specs/openapm-v0.1.md:1357-1358 -- Section 5.2.2 paragraph 3, diagnostic sentence -- After 'without exposing secrets' at lines 1357-1358, insert the parenthetical '(see req-sc-007)'. This adds a non-normative cross-reference to the existing credential-redaction anchor without altering the MUST obligation or its scope. Within Formalize a spec requirement for uninstall reachability preservation (req-lk-0XX) #2270 scope: the diagnostic sentence was introduced by this PR.
Success criterion:grep 'req-sc-007' within the Section 5.2.2 paragraph 3 (lines 1353-1359) returns one hit on the diagnostic sentence. - [F5 / standalone] docs/src/content/docs/specs/openapm-v0.1.md:4784 -- Appendix D, Pending uninstall amendment (Formalize a spec requirement for uninstall reachability preservation (req-lk-0XX) #2270) Changes cell -- Append to the Changes cell text: 'Also corrects the Section 7.4 lockfile-fragment worked-example citation from req-rs-010 to req-rs-001 (resolved_by provenance, not conflict diagnostics).' This records an otherwise unlisted editorial correction that the PR's diff includes. Within Formalize a spec requirement for uninstall reachability preservation (req-lk-0XX) #2270 scope: the citation correction was made in this PR.
Success criterion:grep 'req-rs-010 to req-rs-001' in the Appendix D #2270 entry (line ~4784) returns one hit.
Defer to v0.1.1 (8 items)
- [F6 / standalone] docs/src/content/docs/specs/openapm-v0.1.md:1337-1375 -- req-lk-024 body, Section 5.2.2 -- Letter the distinct MUST sub-obligations in req-lk-024 as (a) through at least (g), consistent with the existing sub-clause pattern used by req-lk-020 and req-pl-015 elsewhere in the artifact. This improves per-clause citability for conformance reports without changing normative content. Within Formalize a spec requirement for uninstall reachability preservation (req-lk-0XX) #2270 scope: affects only req-lk-024 text introduced by this PR. Editorial; no author normative decision required.
- [F7 / T4] docs/src/content/docs/specs/openapm-v0.1.md:1328-1335 -- Section 5.2.2 pre-anchor prose (surviving-declared-dependency and reachability sentences) -- Wrap the surviving-declared-dependency and reachability sentences at lines 1328-1335 in a labeled definition block with its own anchor, then have the normative text of req-lk-024 cite that anchor. Whether the pre-anchor prose carries informative or normative force is an author decision that affects how the label is worded; the synthesizer does not assume either classification. Within Formalize a spec requirement for uninstall reachability preservation (req-lk-0XX) #2270 scope: the pre-anchor prose was introduced by this PR.
- [F8 / T3] docs/src/content/docs/specs/openapm-v0.1.md:1356 -- req-lk-024 paragraph 3 diagnostic MUST -- Author normative decision required. pkg-rec-r1-3 proposes changing 'It MUST emit an actionable diagnostic' to 'It MUST emit a default-visible actionable diagnostic' at line 1356, consistent with req-tg-006 and req-pr-008 phrasing. This is a normative strengthening: it would prevent quiet-mode suppression of a security-relevant preservation event. The author must determine whether this additional obligation is intended by the amendment. Within Formalize a spec requirement for uninstall reachability preservation (req-lk-0XX) #2270 scope: the diagnostic sentence was introduced by this PR.
- [F9 / standalone] docs/src/content/docs/specs/openapm-v0.1.md:1361 -- req-lk-024 dry-run paragraph -- Author normative decision required. tag-rec-r1-4 proposes prefixing the dry-run sentence starting at line 1361 with 'If the consumer exposes a dry-run preview of this cleanup,' making the MUST conditional on offering the feature. Without the prefix the MUST applies unconditionally; consumers that omit preview capability entirely satisfy it vacuously but carry a latent conformance surface should they ever add preview. The author must determine the intended reading. Within Formalize a spec requirement for uninstall reachability preservation (req-lk-0XX) #2270 scope: the dry-run paragraph was introduced by this PR.
- [F10 / standalone] docs/src/content/docs/specs/openapm-v0.1.md:1345-1347 -- req-lk-024 paragraph 2, anchor-repair clause -- Author normative decision required. oci-rec-r1-3 proposes appending after 'identifies the same source.' at line 1347 a sentence stating that existing content-hash verification obligations (req-lk-015, req-lk-017) remain applicable to the repaired entry. This is intended as clarification, not a new duty, since those obligations already apply to all locked entries. However, placing the note at the repair site could be read as implying a new verification-time obligation triggered by repair itself. The existing obligations already cover frozen-install and audit states; the author must decide whether restating applicability at this location adds clarity or ambiguity. Within Formalize a spec requirement for uninstall reachability preservation (req-lk-0XX) #2270 scope: the anchor-repair clause was introduced by this PR.
- [F11 / T4] docs/src/content/docs/specs/openapm-v0.1.md:1338-1339 -- req-lk-024 paragraph 1, preservation scope -- Author normative decision required. pkg-rec-r1-2 proposes replacing the phrase 'the installed material required by it' with a more specific vocabulary binding against existing lockfile fields. The current phrase is intentionally broad; a specific enumeration narrows what the MUST preserves and may exclude future entry fields. The author must determine the intended preservation scope. Within Formalize a spec requirement for uninstall reachability preservation (req-lk-0XX) #2270 scope: the phrase was introduced by this PR.
- [F12 / standalone] tests/spec_conformance/gen_statement.py:65,196 and CONFORMANCE.json -- proposed_amendments key -- Add an informative comment or docstring in tests/spec_conformance/gen_statement.py near the UNINSTALL_REACHABILITY constant (line 65) and near the proposed_amendments dict (line 196) documenting the key shape, its lifecycle (present while Section 9.3 processing is in flight, removed on adoption or withdrawal), and its relationship to optional_features. Within Formalize a spec requirement for uninstall reachability preservation (req-lk-0XX) #2270 scope: the proposed_amendments key was introduced by this PR.
- [F13 / standalone] docs/src/content/docs/specs/openapm-v0.1.md:1343-1344 -- req-lk-024 paragraph 2, parent selection -- The traversal-prescription component of pkg-rec-r1-1 (breadth-first declaration-order parent selection) is outside the bounded scope stated in paragraph 5 (line ~1368): the amendment prescribes neither a traversal algorithm nor storage of multiple parents. That component is declined. Within the remaining scope, the author may optionally add explanatory wording such as 'any verified surviving declaring parent may be chosen' to clarify that no deterministic selection rule is imposed by this amendment. This is not a normative decision requiring a fresh selection algorithm; it is an optional editorial clarification that the text is silent on selection order by design. Within Formalize a spec requirement for uninstall reachability preservation (req-lk-0XX) #2270 scope: the surviving-parent clause was introduced by this PR.
Declined findings
- sw-nit-r1-1 -- Appendix D structural divergence (T2). The separate Formalize a spec requirement for uninstall reachability preservation (req-lk-0XX) #2270 heading is a deliberate placeholder pending the Section 9.2/9.4 classification and revision-number decision. Consolidation into the main revision table requires that decision, which is outside this review's authority. Deferred to the classification decision, not to a patch release.
- pkg-nit-r1-1 -- Appendix D structural divergence (T2). Same rationale as sw-nit-r1-1: consolidation awaits the classification and revision-number decision outside this review's authority.
- tag-rec-r1-3 -- Appendix D structural divergence (T2). Same rationale as sw-nit-r1-1: the separate heading is intentional pending classification. tag-rec-r1-3 additionally proposes moving the row and assigning a revision number, which is outside this review's authority under the bounded scope.
- oci-nit-r1-2 -- Positive observation with null recommended_fix. The Section 7.4 worked example correctly shows resolution-time state; an inline YAML comment showing post-repair state is optional enrichment that risks confusion between normative and illustrative content. No source fix proposed or needed.
- pkg-nit-r1-2 -- Positive observation confirming the req-rs-010 to req-rs-001 citation correction is accurate. No fix proposed (recommended_fix is null). The correction is documented in F5 as an Appendix D improvement.
- pkg-nit-r1-3 -- Positive observation confirming conformance summary consistency between the CONFORMANCE.json proposed_amendments key and the new requirement. No fix proposed (recommended_fix is null). No action needed.
- tag-nit-r1-2 -- The Section 7.4 proposed-language sentence is already labeled with 'Proposed' prefix and the panelist acknowledges no mandatory change is required. The existing labeling is sufficient for editorial clarity.
Linter notes (2 check(s) failed)
- [10] No authored Unreleased changelog entry for this substantive proposal; existing openapm mentions belong to other PRs. This is a SHOULD-level advisory note, not an adoption/release request.
- [11] 4 Python test/generator files changed; the spec-only NONE assertion does not hold. No authored production src changes; no additional panels spawned and no pytest/build/CLI replay.
Note: the synthesizer recommends ship, but the linter found issues worth considering first. These notes do not change its advisory recommendation.
Linter handoff: After F1: re-grep docs/src/content/docs/specs/openapm-v0.1.md:1040 to confirm 'repairs a removed parent' is absent while 'Not a complete incoming-edge set' is preserved. After F2: verify req-lk-024 appears in Section 10.7 prose (lines 3822-3836). After F3: verify req-lk-024 appears in Section 10.11 summary-table row 7 (line 3901). After F4: verify req-sc-007 appears in Section 5.2.2 paragraph 3 (lines 1353-1359). After F5: verify 'req-rs-010 to req-rs-001' appears in Appendix D #2270 entry (line ~4784). Run the forbidden-token check on all new or edited text. Confirm requirement count remains 137 (132 MUST, 5 SHOULD) and that no anchors were added or removed by the folds. The two advisory linter failures (IDs 10 and 11) are not gating; Wave 5 should note them without asserting pass. Mechanical result: checks 1-7 and 9 PASS; check 8 not applicable (no spec Mermaid); checks 10 and 11 have the advisory notes above. All 10 existing public schemas passed check_schema; all 22 YAML/JSON fixtures parsed and cited requirements; 137 anchors and 137/132/5 totals agreed with the manifest and statement. No pytest, collection, application imports, build, CLI or ordinary Python lint was replayed. Owner-reported runtime results are not this review's execution evidence; no green-docs or publication claim is made.
Full per-panel findings
Original panel observations are retained for transparency. The synthesis above determines their disposition; deferred or declined proposals are not instructions to apply them.
Swagger / OpenAPI editor -- shocked_meter 8/10, confidence high
Summary: The req-lk-024 amendment is well-structured from an interface-contract perspective: counts are consistent, the anchor is unique and correctly sequenced, conformance class is uniform across all sites, RFC 2119 keywords are properly capitalized, and cross-references resolve. Two recommended findings: (1) the compound requirement would benefit from sub-clause lettering for per-obligation citability, consistent with the spec's own pattern for req-lk-020 and req-pl-015; (2) the per-entry field table should not embed forward references to proposed requirements. Two nits on Appendix D structural divergence and an unlisted citation correction.
New recommended findings (2)
- [sw-rec-r1-1] 5.2.2 / req-lk-024 -- req-lk-024 packs approximately 10 distinct MUST and MUST NOT obligations across four normative paragraphs under a single anchor. A conformance oracle or test report citing req-lk-024 cannot distinguish which sub-obligation failed without re-parsing the paragraph structure. The spec already uses sub-clause lettering (a)/(b)/(c) for compound requirements (see req-lk-020, req-pl-015, req-mf-025); req-lk-024 would benefit from the same treatment. Each MUST binds a testable claim, but the per-clause citability is weaker than the spec's own established pattern for compound requirements.
Recommended fix: Letter the distinct MUST clauses in req-lk-024 as sub-clauses: (a) preserve reachable entry and required material, (b) keep parent information coherent with a surviving declaring parent, (c) keep resolved_by and local_path coherent for local deps, (d) identity/version/commit/constraint invariance, (e) permit final-parent cleanup, (f) preserve uncertain candidates, (g) emit actionable diagnostic for uncertain cases, (h) do not treat unknown subtree as empty, (i) dry-run preview makes same decisions without mutation. This enables conformance test reports to cite req-lk-024(f) rather than quoting paragraph text. - [sw-rec-r1-2] 5.2 per-entry field table, resolved_by row -- The resolved_by field description in the Section 5.2 per-entry table now embeds a forward reference to proposed req-lk-024: 'Proposed [req-lk-024] repairs a removed parent's anchor to a verified surviving parent during uninstall.' This places a proposed amendment's behavioral claim inside the stable field-description table, which otherwise describes current semantics. If req-lk-024 is rejected or substantially revised during the Section 9.3 process, the table row requires a coordinated revert. Field tables in a specification should describe current normative semantics, not proposed future behavior.
Recommended fix: Replace the forward-reference sentence in the resolved_by table cell with a non-normative editorial note ('See Section 5.2.2 for a proposed amendment affecting this field.') or move the description into Section 5.2.2 itself, so the table row remains stable regardless of the amendment outcome.
New nit findings (2)
- [sw-nit-r1-1] Appendix D -- The Formalize a spec requirement for uninstall reachability preservation (req-lk-0XX) #2270 amendment receives its own subsection heading ('### Pending uninstall amendment (Formalize a spec requirement for uninstall reachability preservation (req-lk-0XX) #2270)') with a separate revision table, unlike all other proposed amendments (0.1.42 through 0.1.55) which are rows in the main Appendix D table. The 'Revision pending (Formalize a spec requirement for uninstall reachability preservation (req-lk-0XX) #2270, proposed)' version label also breaks the numbered '0.1.XX (proposed)' pattern. This structural divergence creates an extra heading in the document outline and a distinct pattern that future amendments may or may not follow.
Recommended fix: Consider assigning a numbered slot (e.g. 0.1.56 (proposed)) and placing the row in the main revision table with a parenthetical note that revision selection is pending, consistent with the existing pattern. - [sw-nit-r1-2] 7.4 / Appendix D -- The Section 7.4 lockfile-fragment citation was corrected from req-rs-010 (conflict diagnostic formatting) to req-rs-001 (intersection-pick and resolved_by provenance recording). This correction is factually correct but is not specifically listed in the Appendix D revision entry, which describes the change abstractly as 'Reconciles resolution provenance with lifecycle anchors'. A reader auditing individual citation changes would not find this fix enumerated.
Recommended fix: Add a clause to the Appendix D entry: 'Corrects the Section 7.4 lockfile-fragment citation from req-rs-010 to req-rs-001 (resolved_by provenance, not conflict diagnostics).'
Preserved strengths confirmed
- Count consistency: 137 (132 MUST, 5 SHOULD) is identical across Section 1.3, Appendix C trailer, Appendix D trailer paragraph, and the amendment revision row delta (136 -> 137).
- Anchor uniqueness: req-lk-024 is the next free slot after req-lk-023; no duplicate anchors exist among all 137 normative anchors (plus the non-normative req-XXX template example at line 4347).
- Conformance class consistency: req-lk-024 is classified as consumer in all five enumeration sites (Section 5.2.2 body, Section 5.7 lockfile summary, Section 11.3.2 consumer enumeration, Appendix C table, and openapm-v0.1.requirements.yml manifest).
- RFC 2119 keyword capitalization: all MUST and MUST NOT occurrences in the new Section 5.2.2 text are properly uppercased; no informal lowercase 'must' or 'should' with normative intent was found.
- Cross-references: all new internal links from req-lk-024 body (req-lk-020, req-lk-021, req-rpl-002) and the corrected Section 7.4 citation (req-rs-001) resolve to existing anchors.
- The Section 7.4 citation correction from req-rs-010 to req-rs-001 is factually correct: req-rs-001 clause 1 governs resolved_by provenance recording while req-rs-010 governs conflict diagnostics.
OCI distribution editor -- shocked_meter 8/10, confidence high
Summary: req-lk-024 is well-scoped: outcome-based, algorithm-agnostic, and correctly fails closed on uncertain evidence. The main gap from a supply-chain threat-model lens is that Section 10.7 and summary-table row 7 do not cite the new requirement as a mitigation for the 'Unverified content cleanup' threat it directly addresses. Two editorial cross-references (req-sc-007 in the diagnostic clause, content-hash obligations after anchor repair) would tighten the defense-in-depth chain. No content-addressing, hash-envelope, or mirror-tolerance regression.
New recommended findings (3)
- [oci-rec-r1-1] docs/src/content/docs/specs/openapm-v0.1.md:3822-3835 (Section 10.7) and :3901 (Section 10.11 summary-table row 7) -- The Section 10.7 'Unverified content cleanup' threat narrative and its summary-table row 7 enumerate req-tg-002, req-lk-020, req-lk-021, req-lk-023, req-mf-025, and self-entry isolation as mitigations but do not cite req-lk-024. req-lk-024 directly mitigates a variant of this threat: orphan cleanup based on a stale single-parent resolved_by value could delete a still-reachable transitive dependency and its installed material. The fail-closed uncertainty clause (paragraph 3 of req-lk-024, line 1354) also mitigates unauthorized deletion when manifest or path evidence is incomplete. The threat-model mapping should be exhaustive for supply-chain audit.
Recommended fix: Append req-lk-024 to Section 10.7 mitigations prose (after the req-mf-025 sentence at line ~3835, e.g. 'Uninstall-time orphan cleanup preserves reachable entries and fails closed on uncertain evidence per req-lk-024.') and to summary-table row 7 at line 3901 (add ', req-lk-024 for uninstall reachability' before the semicolon). Within Formalize a spec requirement for uninstall reachability preservation (req-lk-0XX) #2270 scope. - [oci-rec-r1-2] docs/src/content/docs/specs/openapm-v0.1.md:1357-1358 (req-lk-024 paragraph 3 diagnostic clause) -- The diagnostic clause says 'without exposing secrets' but does not cross-reference req-sc-007, which is the load-bearing normative anchor for token redaction across diagnostics, packed artifacts, lockfiles, and audit records. An implementer reading Section 5.2.2 in isolation may not realize that req-sc-007 already covers this surface and defines the required redaction scope (source-descriptor identification, not literal values). An explicit cross-reference would strengthen the defense-in-depth chain and prevent independent reimplementation of a weaker redaction.
Recommended fix: At line 1358, after 'without exposing secrets' append a parenthetical: '(see req-sc-007)'. Within Formalize a spec requirement for uninstall reachability preservation (req-lk-0XX) #2270 scope. - [oci-rec-r1-3] docs/src/content/docs/specs/openapm-v0.1.md:1345-1347 (req-lk-024 paragraph 2 local_path anchor-repair clause) -- The local_path anchor repair clause says the consumer 'MUST keep resolved_by and local_path coherent together, so resolving the relative path from that parent identifies the same source.' The phrase 'identifies the same source' is ambiguous between filesystem-path identity (the repaired path resolves to the same directory) and content identity (the bytes at that path match the recorded content_hash). A hostile actor who controls a surviving parent's directory layout could place a different package at the path the anchor repair resolves to. Existing content_hash verification fires only on frozen install and audit (req-lk-015, req-lk-017), not at repair time. This is a pre-existing verification-timing gap, not newly introduced, but the new repair operation creates a fresh window where the gap matters. A clarifying note that content_hash obligations are not waived by anchor repair would close the ambiguity.
Recommended fix: After the sentence ending 'identifies the same source.' at line 1347 add: 'Existing content-hash verification obligations (req-lk-015, req-lk-017) remain applicable to the repaired entry; anchor repair does not waive them.' Within Formalize a spec requirement for uninstall reachability preservation (req-lk-0XX) #2270 scope.
New nit findings (2)
- [oci-nit-r1-1] docs/src/content/docs/specs/openapm-v0.1.md:1040 (Section 5.2 per-entry field table, resolved_by row) -- The resolved_by field-table note now references 'Proposed [req-lk-024]' inline, embedding a pending-amendment pointer in the normative field reference table. Other proposed requirements (req-lk-023, req-rpl-*) are not similarly referenced from their affected field-table rows. This inconsistency is minor but could confuse readers about which field descriptions carry normative weight from adopted vs proposed requirements.
Recommended fix: Either remove the proposed req-lk-024 sentence from the field-table note (the Section 5.2.2 body and Section 7.2 reconciliation already explain the relationship), or add a parenthetical '(proposed)' qualifier to match the Appendix C annotation style. Defer if the drafter prefers the current inline approach. - [oci-nit-r1-2] docs/src/content/docs/specs/openapm-v0.1.md:2472-2477 (Section 7.4 lockfile fragment prose) -- The prose preceding the 3-chain worked example was extended to distinguish resolution-time provenance from the uninstall lifecycle anchor, but the example YAML still shows only the resolution-time state (resolved_by as a full constraint chain). A brief inline comment in the YAML showing the post-repair state (e.g. '# After uninstall of acme/baz, resolved_by would carry only the surviving parent') would make the distinction concrete for implementers reading the example.
Preserved strengths confirmed
- Hash envelope discipline (req-lk-016) with anchored regex, explicit deprecation horizon for bare-hex reader tolerance, and algorithm allow-list (sha256/sha384/sha512) remains intact and unchanged by this PR.
- Mirror tolerance contract (req-rs-009) correctly anchors trust on resolved_hash, not resolved_url, and is unaffected by the uninstall reachability change.
- Fail-closed archive extraction (req-sc-004) with media-type pinning, decompression caps, entry-count caps, and zip-slip protection (req-sc-002) remains unchanged.
- Publisher provenance and attestation reservation for v0.2 (Section 10.12) with named binding targets (in-toto/SLSA, sigstore, attestations lockfile field) remains intact.
- Token redaction (req-sc-007) covering diagnostics, packed bundles, lockfiles, and audit records remains the load-bearing supply-chain redaction anchor.
- Canonical git-tree hash definition (Section 5.6.4) with enumerated edge cases and the v0.2 local content_hash reservation remain unmodified.
Package-manager contract editor -- shocked_meter 8/10, confidence high
Summary: Well-crafted outcome-based amendment that adds a hard consumer MUST for uninstall reachability preservation without prescribing traversal algorithms or lockfile format changes. The main lockfile-determinism concern is that anchor repair parent selection across multiple surviving parents is not pinned, which could produce implementation-divergent resolved_by values; this should be either pinned to declaration order or explicitly named as implementation-defined. The citation fix from req-rs-010 to req-rs-001 in Section 7.4 is a correct pre-existing error repair. Counts, conformance enumerations, and cross-references are consistent.
New recommended findings (4)
- [pkg-rec-r1-1] docs/src/content/docs/specs/openapm-v0.1.md:1343-1350 (Section 5.2.2, paragraph 2: anchor repair) -- Anchor repair parent selection is non-deterministic across conformant implementations. The requirement at line 1343 says the consumer MUST keep parent information coherent with 'a verified surviving declaring parent' (indefinite article). When two or more surviving declared dependencies both declare the shared transitive, two conformant consumers may repair resolved_by (and local_path) to different surviving parents, producing divergent lockfile bytes from the same (manifest, lockfile, uninstall-target) input. Unlike resolved_at, which is explicitly called advisory, resolved_by after repair has no explicit implementation-defined carve-out. This is a lockfile-determinism gap: while it does not produce divergent dependency graphs (the set of retained entries is identical), it means a byte-level lockfile comparison after uninstall can differ across conformant implementations, which could trip frozen-install diffs or CI lockfile-drift checks on a subsequent operation.
Recommended fix: Add one sentence after 'a verified surviving declaring parent' at line 1344: 'When more than one surviving declaring parent qualifies, the consumer MUST select the one whose manifest declaration appears first in breadth-first, declaration-order traversal, consistent with the resolution order defined in req-rs-001.' Alternatively, if the intent is to leave selection implementation-defined, add: 'The specific parent selected is implementation-defined; the resulting resolved_by value after repair is not a determinism anchor and MAY differ across conformant implementations for the same input.' Either approach closes the gap; the first produces cross-implementation byte-identical lockfiles, the second names the drift explicitly. - [pkg-rec-r1-2] docs/src/content/docs/specs/openapm-v0.1.md:1337-1341 (Section 5.2.2, paragraph 1: preservation scope) -- The phrase 'installed material required by it' at lines 1338-1339 is not defined in terms of existing lockfile field vocabulary. The existing spec defines deployed_files, deployed_file_hashes, the installed package tree under apm_modules, and content_hash, but req-lk-024 does not specify which of these constitute 'installed material required by' a retained entry. A conformant implementation could interpret this as only the lockfile entry (metadata), or the lockfile entry plus apm_modules package content, or both plus the deployed files referenced by deployed_files. The companion doc changes (uninstall.md) suggest it means 'installed package and required deployed content,' but the normative text should be self-standing.
Recommended fix: Replace 'the installed material required by it' at line 1339 with 'the installed material required by it, including the materialized package content and the deployed files and hashes recorded for that entry'. This aligns the normative text with the companion description and removes interpretation ambiguity without prescribing internal storage. - [pkg-rec-r1-3] docs/src/content/docs/specs/openapm-v0.1.md:1353-1360 (Section 5.2.2, paragraph 3: uncertainty diagnostic) -- The uncertainty clause at line 1356 requires an 'actionable diagnostic' but does not specify whether the diagnostic MUST be default-visible or whether it MAY be suppressed in quiet mode. Other similar diagnostics in the spec (e.g., req-tg-006, req-tg-007, req-pr-008) explicitly say 'default-visible.' Since uncertain-evidence preservation is a security-relevant outcome (the alternative is silent data loss), the visibility level matters for operator awareness.
Recommended fix: Change 'It MUST emit an actionable diagnostic' at line 1356 to 'It MUST emit a default-visible actionable diagnostic', consistent with the phrasing used in req-tg-006 and req-pr-008. - [pkg-rec-r1-4] docs/src/content/docs/specs/openapm-v0.1.md:1040 (Section 5.2, per-entry field table, resolved_by row) -- The resolved_by field-table description at line 1040 was changed from a factual definition to a description that references a proposed requirement ('Proposed req-lk-024 repairs a removed parent's anchor...'). Field-table rows in Section 5.2 should describe the field's semantics in the current adopted spec, not reference proposed amendments inline. If the amendment is not adopted, this forward reference becomes stale. Other proposed amendments (e.g., req-rpl-003 for lockfile_version 3) do not inject their proposed semantics into the core field table.
Recommended fix: Revert the field-table description at line 1040 to a self-standing definition: 'Resolution provenance: the repo_url of the declaring parent that contributed this transitive entry to the resolved graph. For a local entry, also serves as the anchor for local_path resolution. Not a complete incoming-edge set; see Section 7.2 and proposed Section 5.2.2.' This preserves the 'not a complete incoming-edge set' clarification (which is a genuine improvement) without embedding proposed-amendment behavior in the core field table.
New nit findings (3)
- [pkg-nit-r1-1] docs/src/content/docs/specs/openapm-v0.1.md:4780-4793 (Appendix D, 'Pending uninstall amendment' subsection) -- The Formalize a spec requirement for uninstall reachability preservation (req-lk-0XX) #2270 amendment at line 4780 is placed in a separate subsection with its own table, unlike all other proposed amendments (0.1.42 through 0.1.55) which each occupy a row in the main revision table. The structural inconsistency is understandable (no revision number assigned yet) but a TBD row in the main table would be more uniform.
Recommended fix: Add a row to the main revision table with 'Revision pending (Formalize a spec requirement for uninstall reachability preservation (req-lk-0XX) #2270, proposed)' in the Version column, '2026-10-21' in the Date column, and the existing Changes text. Remove the separate subsection heading. This keeps all revision entries in one scannable table. - [pkg-nit-r1-2] docs/src/content/docs/specs/openapm-v0.1.md:2469-2475 (Section 7.4, lockfile fragment preamble) -- The citation correction at lines 2469-2470 from req-rs-010 to req-rs-001 in the resolution-time example preamble is accurate (req-rs-001 clause 1 governs resolved_by recording at resolution time; req-rs-010 governs conflict diagnostic formatting). This is a genuine pre-existing citation error fixed by this PR. Noting for the record that this is a correct editorial fix, not a semantic change.
- [pkg-nit-r1-3] docs/src/content/docs/specs/openapm-v0.1.md:1632 and 4164 (Section 5.7 and Section 11.3.2 conformance summaries) -- The conformance summary appends req-lk-024 with the parenthetical '(proposed uninstall reachability obligation)' which accurately mirrors the pattern used for req-lk-023. Consistent and correct.
Preserved strengths confirmed
- Semver dialect remains pinned to node-semver plus semver 2.0.0 Section 11, with no changes introduced by this amendment.
- Lockfile version monotonicity (req-lk-002) is untouched; no new lockfile_version value or format change is proposed.
- Transitive conflict policy (intersection-pick default, nest reserved with MUST-NOT) is unchanged; the amendment explicitly scopes to uninstall-time orphan cleanup, not resolution.
- Producer/Consumer/Registry conformance classes remain independently enumerable; req-lk-024 is correctly scoped to consumer class only at lines 4630 and 1337.
- Frozen-install determinism (req-lk-006) is unaffected; anchor repair occurs during uninstall, never during frozen install, and the dry-run clause at line 1361 explicitly prohibits file or lock-record mutation.
- The req-lk-005 canonical sort order (repo_url, virtual_path) is preserved since repaired fields (resolved_by, local_path) are not sort keys.
- Reserved-slot defensive MUSTs (workspaces, nest mode, version withdrawal, attestations, registry HTTP) remain intact and unchanged.
Web-platform architect -- shocked_meter 7/10, confidence high
Summary: The amendment is architecturally sound: outcome-contract framing, honest Section 9.3 gating, synchronised machine-readable surface, and bounded cross-requirement interaction. Four recommended findings address definition layering (reachability terms outside the normative anchor), a new undocumented CONFORMANCE.json key, Appendix D structural asymmetry, and a vacuously binding dry-run MUST. Two nits flag prospective language in the field-reference table and worked example. No blocking issues; ship-quality with tracked followups.
New recommended findings (4)
- [tag-rec-r1-1] Section 5.2.2, openapm-v0.1.md:1330-1335 -- The definition of 'surviving declared dependency' and 'reachability' that req-lk-024's MUST clauses depend on sits in three prose sentences preceding the [req-lk-024] anchor (lines 1330-1335). These sentences are informative preamble, not inside the normative block and not in a labelled Definition box. A third-party implementer reading only the anchored requirement text plus Appendix C would miss the graph-walk definition entirely. Comparable specs hoist definitional prose into a numbered or titled definition list so MUSTs can cite it by label. Introduced by Formalize a spec requirement for uninstall reachability preservation (req-lk-0XX) #2270.
Recommended fix: Wrap the surviving-declared-dependency and reachability sentences in a labelled definition block (e.g. 'Definition -- Uninstall reachability.') with its own anchor id, then have the normative text of req-lk-024 cite that anchor. This lifts the definition into the spec's machine-parseable surface without changing any normative obligation. - [tag-rec-r1-2] CONFORMANCE.json:12, proposed_amendments key -- CONFORMANCE.json line 12 adds a new top-level key 'proposed_amendments' alongside the existing 'optional_features' and 'requirements'. The optional_features key is motivated by Section 11.2 item 3, but proposed_amendments has no corresponding spec text, no JSON Schema constraint, and no documented shape or lifecycle contract. A third-party CI pipeline consuming CONFORMANCE.json cannot validate whether this key is well-formed or expected. The key is semantically correct -- it distinguishes a proposed hard obligation from an optional capability -- but without a schema a parser must treat it as opaque. Introduced by Formalize a spec requirement for uninstall reachability preservation (req-lk-0XX) #2270.
Recommended fix: Add an informative note in the conformance-statement generation section (or gen_statement.py preamble) defining the proposed_amendments key shape, its lifecycle (present while a Section 9.3 process is in flight, removed on adoption or withdrawal), and its relationship to optional_features. Alternatively add the key to a conformance-statement JSON Schema if one is maintained. - [tag-rec-r1-3] Appendix D, openapm-v0.1.md:4779-4783 -- Every other proposed amendment (0.1.42 through 0.1.55) sits in the main Appendix D revision-history table with a provisional numbered revision. The Formalize a spec requirement for uninstall reachability preservation (req-lk-0XX) #2270 amendment receives a separate heading ('Pending uninstall amendment (Formalize a spec requirement for uninstall reachability preservation (req-lk-0XX) #2270)') and its own table at line 4779. The revision field reads 'Revision pending (Formalize a spec requirement for uninstall reachability preservation (req-lk-0XX) #2270, proposed)' instead of a provisional number. This structural asymmetry fragments Appendix D: tooling that extracts revision-history rows by parsing the first markdown table in Appendix D will not discover this entry. The trailing reconciliation paragraph partially compensates, but the entry is not machine-discoverable in the same location as the others. Introduced by Formalize a spec requirement for uninstall reachability preservation (req-lk-0XX) #2270; classification/revision-number assignment is outside this review's authority -- the synthesizer arbitrates any numbering suggestion.
Recommended fix: Move the row into the main Appendix D table so it is co-located with the 0.1.42-0.1.55 entries. If a separate table is preferred for classification-deferred amendments, add a one-sentence note documenting the structural intent so tooling authors know to expect multiple tables. Defer the actual revision-number decision to the Section 9.2/9.3 process. - [tag-rec-r1-4] req-lk-024, openapm-v0.1.md:1372 -- The last paragraph of req-lk-024 states 'A dry-run preview of this cleanup MUST make the same preserve/remove decisions ...' This is a hard MUST, but no existing requirement mandates that a conforming consumer offer dry-run preview. If a consumer omits preview entirely, the clause is vacuously satisfied. Comparable specs condition such clauses ('If the implementation offers a preview mode, it MUST ...') to make conditionality machine-readable. The current wording leaves ambiguity about whether the absence of dry-run is a conformance gap or a permitted omission. Introduced by Formalize a spec requirement for uninstall reachability preservation (req-lk-0XX) #2270.
Recommended fix: Prefix the dry-run sentence with an explicit conditional: 'If the consumer exposes a dry-run preview of this cleanup, it MUST ...' This does not create a new obligation to provide dry-run; it clarifies the MUST applies only when the feature exists, matching the apparent intent.
New nit findings (2)
- [tag-nit-r1-1] Section 5.2 per-entry field table, openapm-v0.1.md:1038 -- The resolved_by field description now reads 'Proposed [req-lk-024] repairs a removed parent's anchor to a verified surviving parent during uninstall. Not a complete incoming-edge set.' This sentence describes behaviour that does not exist unless the proposed amendment is adopted. The surrounding table otherwise describes only current v0.1 semantics; a forward reference to an unadopted proposal in the same cell blurs the normative/informational boundary. Introduced by Formalize a spec requirement for uninstall reachability preservation (req-lk-0XX) #2270.
Recommended fix: Move the prospective sentence to a parenthetical note or footnote below the table (e.g. '(see proposed req-lk-024 for future anchor-repair semantics)') to make its non-normative status visually distinct from the current-semantics description. - [tag-nit-r1-2] Section 7.4 worked example, openapm-v0.1.md:2474 -- The added prose 'Proposed [req-lk-024] permits a verified surviving-parent lifecycle anchor to replace removed-parent provenance without changing the selection' sits inside a non-normative worked example about resolution-time provenance, not uninstall-time anchor repair. The sentence is clearly labelled 'Proposed' and does not override the example's context, but a future editor could misread the example as a req-lk-024 conformance illustration. Introduced by Formalize a spec requirement for uninstall reachability preservation (req-lk-0XX) #2270.
Recommended fix: No mandatory change. If tightening is desired, append: 'this resolution-time example is not a conformance illustration for the proposed uninstall obligation.'
Preserved strengths confirmed
- Outcome-contract architecture: req-lk-024 prescribes preservation and repair results without mandating a traversal algorithm or multi-parent storage format, giving implementers design freedom while constraining observable behaviour.
- Amendment process discipline: the blockquote preamble at Section 5.2.2 (line 1322) honestly enumerates every outstanding Section 9.3 gate (non-author approvals, 14-day comment, 9.2/9.4 classification, 9.5 migration, publication). No normative clause is presented as adopted.
- Extension model intact: no change to the x-* extension surface, round-trip guarantees, or reserved-key discipline. The amendment is additive and does not collide with the extension namespace.
- Machine-readable manifest synchronised: req-lk-024 appears in openapm-v0.1.requirements.yml (line 248) with accurate section, keyword, class, and notes. CI extraction of the canonical req-XXX list works without HTML scraping.
- Consistent count reconciliation: the 136-to-137 bump is reflected in Section 1.3 (line 138), Appendix C trailer (line 4730), the Appendix D narrative (line 4781), and CONFORMANCE.json/md. No count-site is stale.
- Cross-requirement interaction explicitly bounded: the normative text (line 1383) enumerates unchanged interactions with req-lk-020, req-lk-021, and req-rpl-002 and disclaims adding network recovery, rollback, exit-code rules, or shared-file policy.
- Forward-compatibility slot reserved: the deferred classification (Section 9.2/9.4) and the separate Appendix D entry leave a clean path for either a patch or minor bump without rewriting the normative text.
This panel is advisory. It does not block merge. Re-apply the spec-review label after addressing feedback to re-run.
Generated by apm-spec-guardian. This comment is AI-generated and may contain errors.
Compose public main without changing proposed uninstall obligations. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: b9e09d66-a487-47cf-a05a-5ae014d3ab12
Apply F1-F5 from the independent review of c85072d. Keep the pending proposal, requirement IDs and obligations unchanged; leave F6-F13 for explicit follow-up. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: b9e09d66-a487-47cf-a05a-5ae014d3ab12
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Propose(spec): formalize uninstall reachability conformance
TL;DR
Proposes req-lk-024 for preserving reachable transitive lock entries and required installed material through either parent-removal order, coherent surviving-parent/local-path anchors, eventual final-parent cleanup, conservative handling of uncertain evidence, and read-only previews. Reuses the existing installed-CLI sequential-diamond oracle and adds requirement-bound uncertainty evidence; production code and published schemas are unchanged.
Important
Draft amendment, not adopted specification text. Classification/revision selection, actual non-author approvals, the subsequent 14-day public-comment period, any applicable migration, and publication remain outstanding. This PR does not complete #2270, promise a CLI release, or ratify the separate conditional
req-rpl-002proposal.Problem (WHY)
req-lk-020andreq-lk-021address different deployed-file ownership rules. The amendment is grounded in existing executable behavior, consistent with "Effective skills are grounded in real expertise."Approach (WHAT)
req-lk-024cases, synchronized manifest/enumerations/history, and truthful generated proposal disclosure.Implementation (HOW)
docs/src/content/docs/specs/openapm-v0.1.mdreq-rs-001; retainreq-rs-010for conflict diagnostics.docs/public/specs/manifests/openapm-v0.1.requirements.ymltests/integration/test_required_lifecycle_state_machine.pytests/spec_conformance/test_uninstall_reachability_reqs.pytests/spec_conformance/gen_statement.py,test_gen_statement.pyCONFORMANCE.json,CONFORMANCE.mdreq-lk-024.docs/src/content/docs/reference/cli/uninstall.md,reference/lockfile-spec.md,specs/conformance.mdpackages/apm-guide/.apm/skills/apm-usage/commands.md,dependencies.mdEvidence flow
The existing lifecycle oracle and new uncertainty cases execute real CLI checks; full collection supplies the generator's binding inventory, not a passing-run certificate.
flowchart TD Oracle["Existing sequential-diamond oracle: real CLI and filesystem"] --> Bridge["req-lk-024 bridge: local and remote, both orders"] Bridge --> Map["Full collection: conformance-coverage.json"] Faults["req-lk-024 uncertainty cases: real CLI and filesystem"] --> Map Map --> Generator["gen_statement.py"] Manifest["openapm-v0.1.requirements.yml"] --> Generator Generator --> Output["Writes CONFORMANCE.json and CONFORMANCE.md"]Trade-offs
src/changes, lock/schema changes, network recovery, rollback/exit redesign, shared-file-policy expansion, historical-waiver edits, or release commitment.c85072d7is recorded below; it supplies no human approval.Permission deniedwith the affectedapm.yml; only that overly narrow oracle changed. The final matrix passes all 12 cases. No destructive product discrepancy or exit-code redesign is claimed.Benefits
Independent guardian follow-up
The independent four-panel advisory reviewed
c85072d7543b3b54856a52346804ddb1c1596b3b, not the follow-up head. Mean 7.75/10, zero new blockers, andfold_and_shipare advisory results, not approval or readiness. Its actual mechanical receipt remains 8 PASS / 2 advisory FAIL / 1 SKIP: check 10 notes no authored CHANGELOG entry; check 11 notes the four Python test/generator files rather than spec-onlyNONE; check 8 skips absent spec Mermaid.Follow-up head
d6a30291b435f4bc15aba8c1926317fd6f6884d7composes public main3b9a8503e0bf5978253f769f823bb84340edfc4a. The fold commit changes only the spec (+7/-5 lines): F1 makes the field-table pointer an explicitly pending Section 5.2.2 reference, retaining "Not a complete incoming-edge set"; F2/F3 add proposed reachability links in threat prose/table; F4 links existingreq-sc-007redaction; F5 records the already-madereq-rs-010toreq-rs-001citation correction in the pending history entry. No obligation, ID, schema, production code or proposal status changes.Actual dispositions for F6-F13: deferred, not silently implemented
No revision number is allocated and no Appendix D table consolidation is performed. Future-version buckets in the advisory are organizational categories, not release commitments. These dispositions preserve the open questions; they do not reject future consideration or ratify the text.
Validation
Original runtime evidence head:
c85072d7543b3b54856a52346804ddb1c1596b3b; public main58199c734e4b57dc4fe905172c38ff34c26a6c9cwas merged before that run. Python 3.12.10, console-script shebang andapm_cliimports were verified to resolve to this checkout, not another editable installation. The 532-test result and hosted docs evidence below remain attributed to that head, not relabeled as follow-up execution.All local pytest, collection, generation and build attempts were routed through the campaign's two-slot
run-heavy.py --lane 2270 --timeout 1800 --runner.APM_BINARY_PATHpointed at this checkout's.venv/bin/apm, withAPM_E2E_TESTS=1. In the commands below,$SESSION_FILESdenotes the session evidence directory used for isolated pytest temporary files. The separately linked GitHub-hosted docs run was inspected read-only after it completed..venv/bin/python -m pytest tests/spec_conformance --no-cov -q --tb=short --basetemp=$SESSION_FILES/pytest-full-spec.venv/bin/python -m pytest tests/spec_conformance --collect-only --no-cov -q.venv/bin/python -m tests.spec_conformance.gen_statementnpm --prefix docs run buildastromissing.npm --prefix docs ci --ignore-scripts --no-audit --no-fund --quietvite-8.3.5.tgz; subsequent build/link check did not run. Official-registry artifact HEAD also failed transport.npm run buildindocs/;uv run --frozen python scripts/check_cli_docs.py docs/distc85072d7543b3b54856a52346804ddb1c1596b3b: 126 pages built, 1112 relative links valid, 34 public CLI commands match 34 rendered pages; schema$idreachability passed. The deployment job was skipped.uv run --frozen --extra dev ruff check src/ tests/ scripts/lint_architecture_boundaries.py scripts/architecture_linter/ scripts/windows_native_symlink_probe_entry.pyuv run --frozen --extra dev ruff format --check src/ tests/ scripts/lint_architecture_boundaries.py scripts/architecture_linter/ scripts/windows_native_symlink_probe_entry.pyuv run --frozen --extra dev python -m pylint --disable=all --enable=R0801 --min-similarity-lines=10 --fail-on=R0801 src/apm_cli/ scripts/lint_architecture_boundaries.py scripts/architecture_linter/ scripts/windows_native_symlink_probe_entry.pybash scripts/lint-auth-signals.shbash scripts/lint-architecture-boundaries.shstr(relative_to)and 2100-line guardsmmdc -i $SESSION_FILES/conformance-flow.mmd -o $SESSION_FILES/conformance-flow.svgRecorded final execution output
The full repository test suite and native Windows acceptance were not run locally. Only the linked docs CI run is asserted here; the entire GitHub check suite is not claimed green. Owner-v2 production-touch mutation evidence is not applicable: the authored diff changes no production owner or boundary rule.
Follow-up checks on the composed editorial tree
The same campaign runner and checkout-local Python 3.12.10 were used. Imports resolved under this worktree's
src/; the actual spawned.venv/bin/apm --versionreported0.34.0 (6eeded04c)on the public-main merge commit with the editorial diff present. Committing that exact checked spec tree producedd6a30291b; no Python file changed in the fold commit..venv/bin/python -m pytest tests/spec_conformance --collect-only --no-cov -q.venv/bin/python -m tests.spec_conformance.gen_statementfollowed bygit diff --exit-code -- CONFORMANCE.json CONFORMANCE.mdreq-lk-024bindings..venv/bin/python $SESSION_FILES/verify-editorial-folds.pygit diff --checknpm run buildindocs/,uv run --frozen python scripts/check_cli_docs.py docs/dist,python3 scripts/check_schema_ids.pyd6a30291b435f4bc15aba8c1926317fd6f6884d7: 126 pages, 1114 relative links, 34 CLI pages and all 10 schema assets verified. Deployment skipped.No independent panel, 532-test suite, native acceptance or local docs build was replayed for the five editorial folds. The original local Vite 404 and exact-
c85072d7hosted docs success remain historical evidence; the separately linked follow-up docs run was inspected read-only. The follow-up does not claim full CI, deployment, publication or human approval.Scenario Evidence
tests/spec_conformance/test_uninstall_reachability_reqs.py::test_sequential_diamond_lifecyclereusestests/integration/test_required_lifecycle_state_machine.py::test_required_diamond_uninstall_preserves_shared_instructions_until_last_parent(four cases).tests/spec_conformance/test_uninstall_reachability_reqs.py::test_uncertain_manifest_preserves_material_and_preview(six local/remote cases).tests/spec_conformance/test_uninstall_reachability_reqs.py::test_uncertain_path_preserves_candidate_and_external_content(two cases).How to test
APM_BINARY_PATH="$PWD/.venv/bin/apm"andAPM_E2E_TESTS=1; verify its interpreter/import paths.tests/spec_conformance/test_uninstall_reachability_reqs.pymatrix through the campaign runner when working inside this campaign; expect both source kinds/orders and all uncertainty cases to pass on POSIX.tests/spec_conformancesuite, regenerateCONFORMANCE.{json,md}, then rungit diff --exit-code -- CONFORMANCE.json CONFORMANCE.md; expect no drift.npm --prefix docs run build.Issue and approved scope
Issue: #2270 (related; deliberately not closed by this PR).
Human scope-approval comment: #2270 (comment)
Scope explanation: #2270 (comment)
The current execution assignment is separate from that product-scope record. Fresh canonical eligibility reports
record-present,authorizes_implementation: false, andcontact_confirmation_needed: false; it is evidence, not permission. The issue is open/unlocked and solely assigned to the executing human. Complete open-PR inventory found no competing carrier before publication.Remaining: normal amendment classification/revision decision; two actual non-author approvals; subsequent 14-day public comment; applicable migration and publication. The completed independent guardian advisory and this F1-F5 follow-up do not satisfy those gates; F6-F13 remain deferred as recorded above. Local dependency retrieval remains unavailable, with hosted docs evidence attributed only to its actual head. No publication, release, approval or merge is performed here.
req-lk-021/022/023remain occupied and unchanged; the public inventory supplied the freereq-lk-024identifier. No ID was reserved on behalf of #3203 or #3215.Type of change
Testing
The unchecked item avoids claiming the full repository suite or remote CI passed. This PR adds conformance evidence, not new production functionality.
Spec conformance (OpenAPM v0.1)
If this PR changes behaviour that an OpenAPM v0.1
req-XXXcovers,confirm the three-step ritual in the
development guide:
docs/src/content/docs/specs/openapm-v0.1.mdupdated(new/changed
<a id="req-XXX"></a>anchor + prose + Appendix Crow).
docs/src/content/docs/specs/manifests/openapm-v0.1.requirements.ymlupdated.
@pytest.mark.req("req-XXX")test undertests/spec_conformance/added or extended.CONFORMANCE.{md,json}regenerated viauv run --extra dev python -m tests.spec_conformance.gen_statementand committed.
The template's manifest location is historical; the actual canonical file updated is
docs/public/specs/manifests/openapm-v0.1.requirements.yml. Generation used the equivalent checkout-local.venv/bin/pythoncommand recorded above. These completed source steps do not ratify the proposed requirement.