Merge pull request #131 from coreytshaffer/cr-oc-001c-closeout

docs(change): close out CR-OC-001C after merge

Author: coreytshaffer

docs/change/change_log.md

@@ -6,6 +6,8 @@ This file provides a chronological, human-readable record of applied codebase an
 
 ## [Unreleased]
 
+- Closed out CR-OC-001C after merge (documentation only): CR-OC-001C is complete, accepted, and merged through PR #128 as merge commit `f65a86423d520a9583c47e5863b90159b4b040ac`, whose parents are `5e41d6f` and `dec98b1`. This entry records the final state and retires the pre-merge status language that became false at the moment of merge. Section 1's implementation status now reads complete, accepted, and merged, with local and hosted validation passed as recorded in section 26, and with the implementation deliberately **non-runtime-integrated**: no runtime module imports or invokes the executor. Implementation and merge authority for CR-OC-001C are recorded as **exercised and now spent** — any correction, expansion, runtime integration, or change to the supported profile requires new authority, and neither the CR document nor section 25 was ever the source of that authority, since each grant was separate, explicit, and bounded to the section 25.1 seven-path allowlist. The approval-gate text now records that both CR-OC-001C gates were satisfied — implementation authority over the allowlist, then merge authority once hosted evidence passed — while stating explicitly that this history establishes no precedent and no standing permission and that every later slice requires its own separate approval. Section 25's "planning only, grants no authority" language is **preserved verbatim rather than rewritten**, with a supersession note recording that its statements were true when written and remain true as statements about section 25 itself, that the five conditions in section 25.11 were subsequently satisfied by separate explicit approvals, and that the four allowlisted code paths now exist on `main`; section 25.11's closing sentence that CR-OC-001D and CR-OC-001E remain unauthorized survives unchanged. A new section 26.9 closure record captures PR #128, the merge timestamp `2026-08-01T09:53:15Z`, merge commit `f65a864`, parents `5e41d6f` and `dec98b1`, the tested generated merge commit `86d43b7`, a tree comparison showing **zero file differences**, deletion of the implementation branch after ancestry verification, and no runtime integration. That tree comparison is the load-bearing fact for acceptance: CI ran against the generated merge commit `86d43b7` rather than against `f65a864`, and although the two have different commit graphs their trees are identical, so the complete four-job evidence from run `30694417116` applies to the tree now on `main`; the post-merge local run of 149 passed and 1 skipped is supplemental confirmation and explicitly not the acceptance basis. The implementation branch was deleted only after verifying that `dec98b1` is an ancestor of `main` and that zero commits existed on the branch but not in the merged history. The closure record states narrowly what the merge completed: CR-OC-001C's **bounded executor slice** — a Windows/NTFS constrained single-file replacement executor existing as a non-integrated library surface that only tests invoke — and **not** the broader OpenClaw lane or the mediated-execution lane. CR-OC-001D (broker and named pipe), CR-OC-001E (OpenClaw tool), and every runtime consumer remain separately unauthorized, no runtime module imports or invokes the executor, and the section 26.7 non-claims survive the merge unchanged, since merging code does not convert any of them into established properties — nothing here establishes hostile-writer safety, cross-process exclusion, OpenClaw containment, authorization, reservations, exactly-once execution, or causation from observation. The backlog moves CR-OC-001C out of the active list into the completed status section as a compact entry, with detailed lineage preserved in the CR document and this change log rather than carried as an active item. This entry changes no code, tests, workflow, dependency, fixture, or configuration.
+
 - Recorded the CR-OC-001C implementation evidence after the section 10.2b correction and its hosted Windows validation (documentation only): Part III section 26 previously claimed the branch was unpushed and that hosted Windows CI had never run. Both were live contradictions and are replaced. The implementation on draft PR #128 now conforms to section 10.2b — the supported-profile gate sits immediately after pre-mutation snapshot validation and before the `TokenOwner` query, so an absent, NULL, or inheritance-enabled DACL is refused as `metadata_precondition_failed` with outcome `not_attempted` before temporary-file creation and before `ReplaceFileW`; healthy Windows fixtures are present, non-NULL, and protected by construction with the owner untouched and all fixture preparation confined to tests; T20's third part is a supported-profile control; T21 gained a genuine unprotected-target refusal proving cessation at the pre-mutation capture with no temporary file, no replacement, no token query, bytes intact, no artifacts, and the DACL still unprotected afterwards because the executor inspects and refuses rather than repairing; seam-injected absent and NULL states refuse identically; a present, protected, zero-ACE DACL is proven supported, which is the deterministic guard that `pre_dacl_nonempty` never leaked from diagnostic control into production policy; T35W confirms the supported profile before replacing; and the two temporary diagnostic tests were converted into their contracted T21 homes rather than left as parallel ambiguous controls, with T35W sharing the single difference classifier so the two cannot drift. The mutant record moves from a stale 29 total (19 Windows, 10 Ubuntu) to 31 total — 21 Windows, 10 Ubuntu, 31 clean behavioural kills, 0 survivors, 0 invalid kills — and section 25.9's reviewer command set is corrected from 27 variants to 31, since that is a concrete instruction rather than historical prose. Because section 10.2b changed the shared Windows fixture and several designated killers, all 31 mutants were rerun against the final text rather than resting on function-equivalence arguments, and all 31 anchors were pre-validated as present exactly once after newline normalization before any cycle ran. Section 26.6 now carries the observed local evidence rather than preserved counts: 149 focused Windows with one optional skip, 173 mandatory with one deselected and zero skipped and a passing structured gate recording `True->True`, 96 Ubuntu neutral with 54 skipped, 24 Ubuntu guards, a 640-file Ubuntu manifest, 1664 full-repository with 6 skipped, and 31 of 31 mutants killed. The Ubuntu 54-skipped figure is explicitly distinguished from the hosted zero-skip metric: it is what running the whole Windows-oriented executor file on Ubuntu produces, since every `[W]` obligation is `windows_only`, whereas the zero-skip rule applies to the hosted mandatory group, which reported zero. A new section 26.6a records the hosted evidence: run `30694001033`, PR head `257966b5899a96143f1757fb4694eca3448aeb13`, checked-out generated merge ref `c5e8a9e4764f954f8d3baf263dfaaf0f783ec855`, base `5e41d6fc27f505e14b206d0e743add020428bfba`, Windows Server 2025 build 10.0.26100 on image `windows-2025-vs2026` version 20260714.173.1, Python 3.12.10, NTFS, 173 mandatory tests, zero skipped, structured gate PASS, transition `True->True`, symlink probe pass, all four jobs green. The distinction between the head commit and the generated merge commit is recorded deliberately and was verified through the commits API rather than assumed, because the run's own `headSha` field reports the association and not the checkout; recording only one of the two would misstate what was tested. That evidence satisfies the hosted Windows portions of sections 21 and 25.7 for that tested tree only, and is neither a universal Windows guarantee nor evidence about any later commit, since any subsequent change produces a different merge ref requiring its own run. Section 26.2's discovery count moves from three to five, adding the two defects that only hosted CI found — the `TokenUser`/`TokenOwner` quantity error and the failure of a successful `ReplaceFileW` to preserve the invariant on inheritance-enabled targets — which is the strongest available argument that the hosted job is not ceremonial. Section 26.3 grows from three harness defects to seven, cumulatively rather than by replacement, adding four evidence-integrity faults capable of making unexercised or unrestored state look like valid evidence: a same-length mutation combined with the timestamp-and-size `.pyc` reuse heuristic served stale mutated bytecode, fixed by disabling bytecode writes and purging caches around every mutation and restoration; CRLF byte-mode anchors caused multi-line mutants to be silently skipped while the run still looked complete, fixed with newline-aware anchors and hard failure statuses for missing or duplicate anchors; `docker cp` created root-owned source files in the Ubuntu volume so the first cycle raised `PermissionError` on its first write, and because that happened before any mutation landed the source was verified against the pristine hash before anything else was done, confirming no unrestored state existed, after which the files were recreated under the container user with hashes re-verified and the cycles rerun; and an ephemeral `.pytest_cache` entry invalidated the repository manifest, which was narrowed to the 640 source-controlled files it is intended to protect. Section 26.7's non-claims are revised: hosted Windows validation has now been achieved for the tested merge ref, the optional symlink probe skipped locally while the hosted supplemental probe passed, `True->True` is one accepted observation rather than a required platform behaviour, and nothing establishes hostile-writer safety, cross-process exclusion, OpenClaw containment, authorization, reservations, exactly-once execution, or causation from observation. Section 26.8's warning count is corrected from a stale 40 to the observed hosted 46, retaining the explanation that registering the markers would require the unauthorized `pyproject.toml` path and that strict-marker escalation is a stop condition rather than a reason to widen scope. Section 1 records that the implementation now conforms to section 10.2b with local and hosted validation passed, while remaining unmerged, not accepted, and not runtime-integrated, with merge authority not granted. This entry changes no code, tests, workflow, dependency, fixture, or configuration.
 
 - Amended CR-OC-001C to restrict execution to targets with a present, protected DACL, after three hosted Windows CI runs established that a successful `ReplaceFileW` does not preserve the required invariant on inheritance-enabled targets (documentation only): A new section 10.2b narrows the supported profile. CR-OC-001C now supports only targets whose pre-mutation DACL is present, non-NULL, and protected from inheritance (`SE_DACL_PROTECTED` set); any absent, NULL, or inheritance-enabled DACL is refused as `metadata_precondition_failed` with outcome `not_attempted`, before temporary-file creation and before any replacement attempt. This narrows the supported profile rather than weakening the invariant, and the amendment says so explicitly: the exact owner, DACL-state, control-bit, `AclRevision`, ACE-count, ACE-order, and complete-ACE-byte comparison of section 10.1 is unchanged, no comparison is relaxed or made unordered or partial or replaced by an effective-permissions rule, the section 10.1a `SE_DACL_AUTO_INHERITED` monotonic rule is unchanged, post-verification remains mandatory and authoritative rather than being displaced by the precondition, and unsupported targets are never normalized, repaired, protected automatically, or attempted — the executor does not modify a security descriptor to make a target supportable, it refuses. The discovery sequence is recorded in full. Hosted run `30689442321` classified a previously unexplained failure: on an ordinary inheritance-enabled target a **successful** `ReplaceFileW` changed exactly three components — `dacl_auto_inherited`, `ace_count`, and `ace_bytes_or_order`. Hosted run `30690450931` ran a paired protected-DACL control that was neither failed nor skipped, and that result is recorded deliberately as *not* evidence: as first written the control failed only on a metadata label beyond `dacl_auto_inherited`, so a refusal such as `temp_creation_failed` accompanied by no metadata differences would also have passed it, and the recorded `protected_replacement_result` property could not be recovered because the mandatory command failed before the structured gate or bounded summary exposed it and no artifact is uploaded. Absence from a failure list is not evidence, so the control was strengthened to require simultaneously a protected and nonempty fixture, `reason_code == ok`, outcome `replacement_verified`, target bytes exactly equal to the proposed bytes, and metadata differences of none or `dacl_auto_inherited` alone; each of those assertions was then verified to actually fail when its condition was forced, because an unverified control is the same defect one level up. Hosted run `30691068391` passed the strengthened control while the unprotected control reproduced the same three differences. What that establishes is stated narrowly: on the hosted runner, the unprotected profile violated the exact invariant while the present-and-protected profile completed a verified replacement under the exact same comparison. What it does **not** establish is stated just as plainly: it does not prove that inheritance recomputation is the underlying Windows mechanism, because the diagnostic reported field labels only and established neither that every new or changed ACE was inherited nor that effective access was unchanged. Microsoft documents `ReplaceFileW` as preserving the DACL and separately describes the operation as merging attribute and ACL information into the replacement file, without promising byte-identical ACE enumeration in every inheritance environment, and automatic inheritance can set `SE_DACL_AUTO_INHERITED`, materialize inherited ACEs, and order inherited entries after explicit ones — but the governance conclusion does not depend on which explanation is correct. The hosted environment is recorded as bounded evidence rather than a universal Windows guarantee: Windows Server 2025, build 10.0.26100, image `windows-2025-vs2026`, Python 3.12.10, NTFS. An effective-permissions rule was considered and rejected as materially harder to prove safely than exact equality, since ACE order affects access decisions and common effective-rights helpers omit owner rights, privileges, logon-session groups, resource-manager policy, and some inherited-deny cases; exact equality over a narrower profile is the conservative direction. `pre_dacl_nonempty` is documented as a diagnostic validity control whose only purpose was to prove the hosted success was not a trivial empty-ACL comparison, and explicitly not a production requirement — a present, non-NULL, protected DACL with zero ACEs remains supported, and section 10.1's three-state classification continues to distinguish present-empty from NULL and absent. Section 10.2's DACL carry-over bullet and section 11.2's merge language were revised so neither implies that `ReplaceFileW` alone establishes general exact preservation; both now state that documentation is trusted to choose the primitive and never to skip the check, that hosted evidence supports preservation only within the protected profile, and that post-verification remains the deciding evidence. Section 1 now records all three amendments as contract-discovery results found by running the contract against real Windows evidence. Rather than adding a thirty-seventh obligation, T21 is revised into four parts — an unprotected target refuses before temporary-file creation or `ReplaceFileW` with original bytes unchanged and no artifacts remaining, seam-injected absent and NULL DACL states refuse identically, a present and protected target completes with `ok`, `replacement_verified`, exact proposed bytes and the full exact metadata invariant, and existing injected post-replacement differences still produce `metadata_preservation_failed` — so obligation totals stay at 36 while mutants move from 30 to 31 (21 Windows, 10 Ubuntu). The new M31 defect is omitting the present-and-protected DACL precondition or treating an inheritance-enabled target as supported, killed by T21[W]'s unprotected-target test; it is Windows-scoped by necessity because its killer asserts refusal against a genuine NTFS security descriptor and a real mechanism call log, which the neutral core cannot produce. Section 21's acceptance contract and section 25.7's hosted acceptance now additionally require that every healthy replacement case run within the supported profile, that T35[W] confirm the supported pre-state before replacement, that every other participating component be exactly preserved, that absent, NULL, and unprotected profiles fail before mutation, and that M31 be killed cleanly. Sections 1, 10.2, 10.2b, 11.2, 19, 20, 21, 25.5, 25.6, and 25.7 are updated consistently. Three contradictions the amendment would otherwise have left behind are also corrected. T20's third part said "an ordinary target created by this process reaches `replacement_verified`", which under the amended contract either permitted or required a healthy result without establishing the supported profile; it now reads that a target created by this process, then placed into a present, non-NULL, protected DACL profile without changing its owner, reaches `replacement_verified` with post owner equal to pre owner, and the section 10.2a lineage entry above carries the same qualifier. Section 1's implementation status said "Proposed, not authorized", which has been false since implementation was explicitly authorized; it now records that implementation is authorized and in progress on draft PR #128, not merged, not accepted, not runtime-integrated, and not yet conformant with section 10.2b — the supported-profile gate, revised fixtures, T21 evidence, and M31 all remain pending — with the adjacent authority and approval-gate bullets adjusted so they no longer read as denying an authority that was in fact granted, while still stating that it came from a separate explicit approval bounded to the section 25.1 seven-path allowlist and is not merge authority. And the gate order is now explicit: the supported-profile gate is evaluated immediately after validating the pre-mutation security snapshot and before the `TokenOwner` ownership gate, despite the order the two bullets are written in, which gives T21's absent, NULL, and unprotected cases a precise cessation point and avoids querying the token's default owner for a profile already known to be unsupported. This entry changes no code, tests, workflow, dependency, fixture, or configuration; the implementation on draft PR #128 remains unmerged and will be corrected after this amendment lands, at which point the production profile gate and M31 remain outstanding work.