Skip to content

v0.12 T04 blocker: isolated restore and crash-recoverable lock/restore transactions #71

Open

Description

@eybersjp

Status

Blocks promotion of T04 hardening PR #70 and progression to T05. Current T04 source is on fix/v0.12-t04-state-engine-hardening, and the cumulative main-targeted PR #69 must not be merged independently.

Remaining independent-review findings (risk 3)

  1. P1: Restore staging is not isolated against a hostile process running under the same local UID. A process can replace a directory within the stage between a path preflight and openSync() and redirect writes outside the project. See fix(v0.12 T04): crash-safe event append, process locks and restore confinement #70 (comment). Node.js pathname APIs alone do not provide cross-platform descriptor-relative unreplaceable traversal. Do not claim protection from arbitrary same-UID attackers without OS-native handle APIs or process isolation.
  2. P2: Non-atomic two-rename root promotion can strand the complete target root after a crash. See fix(v0.12 T04): crash-safe event append, process locks and restore confinement #70 (comment).
  3. P2: Reclamation mutex .state.lock.reclaim can be orphaned if its owner crashes, blocking later state writes until safe manual intervention. See fix(v0.12 T04): crash-safe event append, process locks and restore confinement #70 (comment).

Required architecture decision

Select an explicit supported security boundary before implementing further patches: (A) an isolated recovery helper with native directory-handle-relative APIs and appropriate OS credentials, or (B) a restricted offline restoration feature that fails closed outside a trusted, exclusively controlled recovery workspace. An unverified boolean/trust flag or directory permission 0700 is not sufficient against a same-UID attacker.

Acceptance contract

  • All backup writes remain inside the intended root under injected parent swaps, hardlinks, junctions and symlinks. Include deterministic swap-at-open and swap-at-rename tests on supported platforms.
  • A crash at every transaction boundary can be resumed/rolled back deterministically without discarding the original root, with a durable journal and startup/manual recovery before any new restore.
  • Lock guard crash cannot leave the system permanently blocked without a documented, verified, safe recovery path. An explicit fail-closed maintenance procedure is permissible only if the limitation is accepted in the T04 contract.
  • Restore does not silently change original root mode, ownership, traversal ability or custom ACLs; for unsupported host metadata semantics, fail closed and document the limitation.
  • The existing H01–H23 security/concurrency tests and the complete Ubuntu/Windows npm run release:validate matrix must pass twice on the same reviewed HEAD. No skipped supported security fixture.
  • Independent code, architecture, and security reviews must report zero unresolved Critical/Major findings and the deterministic risk-3 acceptance evidence must be persisted in .development-kit governance before merge.

Non-goals / exclusions

No T05–T10 functionality, package version release, registry changes or deletion of retained legacy state. This issue does not authorize an npm/GitHub release.

Activity

  1. eybersjp commented on Oct 9, 2026

    @eybersjp
    OwnerAuthor

    T04 recovery design — proposed closure evidence (independent approval pending)

    Selected Issue #71 option B: restricted operator-controlled offline restoration, without claiming portable Node.js can defend against hostile same-UID filesystem mutation. Restores now fail closed unless the caller explicitly sets confirmOffline: true. This is a required operational attestation and no guarantee of actual OS isolation; use is unsupported when co-tenant processes can manipulate the project or sibling stage. See docs/04-architecture/dkf-state-engine-v2-offline-recovery-boundary.md.

    Implemented a durable sibling journal with precise stage/root device/inode witnesses encoded as BigInt decimal strings, explicit recoverLegacyRestore({targetRoot,confirmOffline:true}), file/directory sync and interruption recovery. H25 and H28 exercise exception and real child-process termination between the two root renames. New restores refuse to run while an incomplete journal remains.

    Implemented owner metadata and conservative explicit recoverAbandonedStateLock({rootDir,confirmOffline:true}). It verifies a 60s-old guard and a dead local PID; H26/H27 cover orphan and live-owner denial. Normal writers never remove uncertain guards.

    Previous code SHA 223982fb7ee5... passed full Ubuntu/Windows CI run 37972680014 with H01–H28. Latest source includes additional staged-tree syncing and a Windows write-handle correction; latest exact-source CI and independent risk-3 review are running. Issue remains open until independent reviewers confirm acceptable scope, no in-scope Critical/Major findings, and deterministic T04 acceptance is persisted.

  2. eybersjp commented on Oct 12, 2026

    @eybersjp
    OwnerAuthor

    T04 status — exact source cf0fd8208cd262da29dfe0d91576c4808efa6873

    Verified final CI matrix on GitHub Actions run https://github.com/eybersjp/development-kit/actions/runs/38318331981:

    • validate (ubuntu-latest) SUCCESS
    • validate (windows-latest) SUCCESS
    • T04 independently reviewed acceptance FAILURE: evidence is still pending, not a source/test validation pass.

    The Ubuntu job's decoded log records T04-H43, H44 and H45 PASS, with 66 passing / 1 skipped in its focused suite (the skipped case is Windows-only H14). Local Windows validation was reported as 56 passed / 11 skipped, with the skip rationale recorded in docs/04-architecture/dkf-state-engine-v2-t04-hardening-validation.md. These platform-conditional skips are not interchangeable with cross-platform assurance.

    Three independent, single-role, exact-source review requests are queued on PR #70:

    As inspected, each request has only a Codex eyes acknowledgement; no authentic +1 clean review or source-bound accepted review receipt exists. docs/04-architecture/dkf-t04-independent-review-receipts.json still has reviewedCommit:null, reviews:[].

    Human security/PO decision still required: the separate proposal to limit automatic runtime protection to a trusted/exclusive local environment (excluding hostile same-UID mutation) is explicitly a candidate and cannot be adopted on assistant authority or inferred from the previously chosen offline restore Option B. The author must explicitly accept or reject this narrower runtime contract with its limitations before T04 risk-3 approval.

    Keep Issue #71 and PR #70 open, no T05 progression/merge, until the three authenticated independent reviews, explicit scope decision, zero unresolved Major/Critical findings, and deterministic T04 ACCEPTED record all exist.

  3. eybersjp commented on Oct 12, 2026

    @eybersjp
    OwnerAuthor

    Product Owner disposition — defer stronger runtime isolation

    The Product Owner's latest direction is to leave hostile concurrent same-account filesystem protection for a later Development Kit revision, and mark it for explicit reconsideration. Tracked in Issue #72: #72.

    For v0.12.0, treat the documented trusted, exclusively controlled local runtime as the chosen limited supported operating environment for T04. Do not claim portable Node.js prevents a hostile same-UID process from swapping canonical event ledgers or recovery journal entries. The prior restricted offline restoration (Issue #71 option B) is separate and unchanged. This scopes the unsupported adversary case; it does not establish an atomic filesystem guarantee.

    T04 independent gate remains mandatory: confirm v0.12 scope disclosure and requirements, zero remaining in-scope Critical/Major defects, valid exact-source code/architecture/security reviews, Windows+Ubuntu validation, authentic receipts and deterministic ACCEPTED. Don't treat this decision as an external review approval; do not invent receipts or merge before those independent gates pass.

    No need to repeatedly ask for this same scope choice during v0.12 unless the implementation reveals a materially different risk or incompatibility. Future version planning must reopen Issue #72.

  4. eybersjp commented on Oct 12, 2026

    @eybersjp
    OwnerAuthor

    DKF v0.12.0 continuation — T04 implementation and review status

    As of exact PR #70 head c04615700476cd55c57d3eea58026ac91bda1107, the latest full-source corrective round includes:

    Remaining blockers: Issue #73 Windows native durable rollback and normal staged promotion/journal ordering needs independent verification/architecture closure; PR #70 has three unresolved review threads until current-head review. Exact-source authentic role receipts and deterministic ACCEPTED are still absent. The separately approved same-account attacker deferral Issue #72 does not waive Issue #73 or the risk-3 gate.

    The approved plan explicitly prohibits commencing T05 Lifecycle Instances until T04 reaches deterministic ACCEPTED; T06–T10 depend sequentially thereafter. PR #70 has NOT been merged into its T04 base, PR #69 has NOT been merged to main, and v0.12.0 has NOT been released. The hourly DKF v0.12 completion workflow is configured to continue at the next lawful gate and surface substantive decisions/findings.

  5. eybersjp commented on Oct 29, 2026

    @eybersjp
    OwnerAuthor

    T04 risk-3 acceptance provenance hardening — 29 October 2026

    A separate acceptance-gate source defect was reproduced and corrected on draft diagnostic PR #94 (not merged into PR #70 or main): #94 .

    Reproduction: Existing gate labeled all acceptance criteria PASS and claimed repeated Windows/Ubuntu validations from a single current CI run, with a hard-coded historical GITHUB-ACTIONS-37974556018 evidence identifier. It also did not explicitly reject acceptance while mandatory Issue #71 or Windows durability P1 Issue #73 remained open. Test-first red CI: https://github.com/eybersjp/development-kit/actions/runs/40948591533 and https://github.com/eybersjp/development-kit/actions/runs/40949192760 .

    Verified corrective candidate: Exact draft PR #94 SHA b4c461cd5e5f02d0324152219540ddae16d410d4 passed complete Ubuntu and Windows release validation in https://github.com/eybersjp/development-kit/actions/runs/40949273081 . New verifier requires two distinct authenticated same-source PR #70 workflow executions with successful Windows and Ubuntu jobs, rejects fabricated/reused/stale evidence, and blocks acceptance while #71/#73 are not closed as completed. The gate's read-only Actions permission is scoped to the acceptance job. Adversarial tests cover missing repeats, duplicate IDs, stale source, skipped Windows, foreign runs, open and waived issues.

    Boundaries: Diagnostic CI passing is NOT independent T04 acceptance; the T04 acceptance job is intentionally skipped on PR #94. Issue #73 still requires controlled physical power-loss evidence and independent verification. Three authenticated role-scoped exact-source reviews and the persisted deterministic ACCEPTED verdict remain missing. Do not close this issue, merge PR #70/#69, or claim release readiness on this evidence alone.

  6. eybersjp commented on Oct 29, 2026

    @eybersjp
    OwnerAuthor

    T04 acceptance provenance follow-up — 29 October 2026

    Codex independently identified two new PR #94 review defects on source b4c461c: P1 repeated validations could share a PR head but use different merge bases, and P2 the verifier rejected the permitted post-review receipts-only execution commit C after reviewed source R. Source: #94 .

    Test-first regression reproduced failures in GitHub Actions https://github.com/eybersjp/development-kit/actions/runs/40958619112 (both platforms' acceptance-provenance regression step failed). The narrowly scoped draft PR #94 correction now: (1) binds CI to immutable T04 PR #70 head checkouts in both platform jobs and acceptance while preserving merge-ref integration tests for other PRs; (2) checks the authenticated PR base SHA is unchanged across repeated runs; (3) distinguishes reviewed R from receipts-only execution C, proving C's checked-out tree equals R except for receipts; and (4) binds acceptance checkout HEAD to GitHub's authenticated PR event.

    Real CI on corrected source 5e7e6b6: https://github.com/eybersjp/development-kit/actions/runs/40958813022 — Ubuntu full release validation SUCCESS, Windows full release validation SUCCESS, acceptance correctly SKIPPED on diagnostic PR. Latest documentation-only candidate 123de36 also passed full Ubuntu and Windows release validation in https://github.com/eybersjp/development-kit/actions/runs/40958908194 ; its independent T04 acceptance job was correctly SKIPPED because this is diagnostic PR #94, not production PR #70. Fresh independent code, architecture and security review requests have been made on the exact latest candidate; do not presume a clean verdict.

    No acceptance claim: PR #94 is draft and not merged into production PR #70. Issues #71 and #73 remain open; controlled Windows power-loss durability evidence and authentic three-role production-source receipts remain mandatory. Neither PR #70 nor #69 may merge before the proper v0.13 gate.

    Second independent review cycle — merge-workflow provenance and cancelled-run selection

    Codex's next exact-source review found a further P1: GitHub selects pull_request workflow YAML from the merge ref even if checkout selects the PR head; workflow ID and job names alone do not authenticate the executed workflow revision. It also found a P2: the collector selected a cancelled matching prior run and missed an earlier successful full matrix. Both were reproduced in red Windows/Ubuntu CI https://github.com/eybersjp/development-kit/actions/runs/40959720558 .

    Draft PR #94 now checks that refs/pull/70/merge has the exact validated base/head parents and that the merge tree's CI workflow blob matches the independently reviewed source; it searches prior matching runs for a complete successful matrix while rejecting malformed or paginated evidence. Exact latest source a6fa183 passed both Ubuntu and Windows full release validation in https://github.com/eybersjp/development-kit/actions/runs/40959846051 . Independent T04 acceptance was correctly skipped on this diagnostic PR. Fresh independent review is pending. No Windows power-loss claim, PR70 merge, receipt, or ACCEPTED verdict is implied.

    Third review cycle — workflow identity and complete run pagination

    A further Codex review found P1 workflow-ID substitution (an unreviewed workflow with the same name and job names) and P2 missing pagination beyond the first 100 workflow runs. Both reproduced by adversarial regression in red Windows/Ubuntu CI https://github.com/eybersjp/development-kit/actions/runs/40960477587 . The diagnostic correction now authenticates workflow ID/name/path against .github/workflows/ci.yml, verifies each run's path, filters by immutable head SHA, paginates prior CI executions and rejects duplicate/malformed evidence. Exact latest draft PR #94 source 056533a passed full Ubuntu and Windows release validation in https://github.com/eybersjp/development-kit/actions/runs/40960622741 . T04 acceptance was correctly skipped on this diagnostic PR. Exact-source independent re-review remains pending. These are not acceptance receipts for production PR #70; Windows physical durability Issue #73 and Issue #71 remain open.

    Diagnostic review disposition

    Codex's latest code-review summary on exact PR #94 SHA 056533a reports completed with no new findings. All six historical diagnostic inline threads were replied to with specific corrective source/CI references and are now resolved (administrative thread disposition, not independent production approval). The diagnostic PR remains DRAFT and UNMERGED. Its Ubuntu/Windows green CI #40960622741 does not satisfy PR #70's source-bound review receipts, Issue #73 physical Windows crash durability, or a persisted T04 ACCEPTED verdict.

  7. eybersjp commented on Oct 29, 2026

    @eybersjp
    OwnerAuthor

    T04 acceptance source-provenance correction — 30 October 2026 (diagnostic PR #94, not production integration)

    A further narrowly scoped fail-closed GitHub evidence defect was reproduced and corrected on draft PR #94, exact candidate 399451332eeaeaa6f44a63d9ebdf28cd694d4f94.

    Defect: scripts/t04-hardening-acceptance-gate.mjs passed the independently reviewed commit SHA directly into the Git Trees REST endpoint. The API's supported identifier is the Git tree SHA. This implicit commit-as-tree resolution is not a documented provenance contract and can make authentic review acceptance fail or depend on undocumented coercion.

    Test-first CI evidence: Added a regression requiring an authenticated git/commits/<reviewed R> lookup and a canonical git/trees/<R.tree.sha> lookup. Both Ubuntu and Windows provenance regression steps failed as expected on https://github.com/eybersjp/development-kit/actions/runs/40966393144 . Corrected gate verifies the commit object's returned SHA equals R, validates its tree SHA, then compares the complete tracked Git index to that tree (except the authenticated receipts-only change). Fixed an over-escaped test regex during the red/green iteration. The final candidate's Ubuntu and Windows full release-validation jobs both SUCCESS at https://github.com/eybersjp/development-kit/actions/runs/40966532943 . Independent Codex diagnostic review on this exact source reported no major issues in PR #94; this is NOT a production PR #70 role-scoped approval.

    Release boundary unchanged: PR #94 is draft and unmerged; production PR #70 remains at a203ab9280a3d5cd726019499f8900e3610ee8de, without this fix. T04's source-bound independent code/architecture/security receipts are still absent, Issue #73 Windows physical crash durability remains unproven, and deterministic ACCEPTED is still blocked. No waiver, fabricated review, merge or release.

  8. eybersjp commented on Oct 30, 2026

    @eybersjp
    OwnerAuthor

    T04 diagnostic consolidation checkpoint — 30 October 2026

    Opened draft, unmerged PR #97 #97, exact combined source 06d636b086e073b4b0a6479d44fd63874c82810e, integrating independently test-first diagnostic work from PR #94 (authentic repeated CI provenance), PR #95 (H51–H56 real process termination and negative controls), and PR #96 (truthful unused Windows native-helper documentation). Full Ubuntu and Windows release-validation jobs SUCCESS on the combined head in https://github.com/eybersjp/development-kit/actions/runs/41001218441; independent T04 acceptance correctly SKIPPED because this is not production PR #70. Exact-source code, security and architecture diagnostic reviews requested on PR #97; no approvals presumed.

    The source is not merged into production PR #70; mandatory Issues #71/#73 remain OPEN, review receipts still reviewedCommit:null, reviews:[], and the Windows physical power-loss/journal-unlink durability contract remains unproven. No merge, v0.12 release inclusion or persisted T04 ACCEPTED claim. Next integration only after genuine source-bound reviews, controlled Windows durability evidence and protected v0.13 gates.

  9. eybersjp commented on Oct 30, 2026

    @eybersjp
    OwnerAuthor

    v0.13 integration evidence update, 30 October 2026 (not acceptance): actual draft integration PR #92 has been updated from released v0.12.1 source to commit 67570ce802cddb9c76a0bfa6480d092049874a19. Atomic source/test port 37d1d22d94d2fdf005c35bb1d807c059883fc50b copies 11 narrowly scoped files from diagnostic PR #99 head 51556f841bb07e9ed27436e9156bfff022487de1, excluding the diagnostic-only CI workflow exception. Test-first evidence: Windows W73-19 RED CI #41010567167 -> Ubuntu/Windows GREEN #41014994052; Windows W73-20 RED CI #41015062706 -> Ubuntu/Windows GREEN #41015133002. PR #92's new exact-head CI https://github.com/eybersjp/development-kit/actions/runs/41015777874 is in progress. The PR #92 review request is #92 (comment). Open P1: Windows ACL security descriptor preservation, recovery publication-barrier retry, and physical NTFS power-loss evidence. Three independent authenticated exact-source role reviews and deterministic persisted ACCEPTED are still missing; Issue #71 remains open, no merge or release.

  10. eybersjp commented on Oct 30, 2026

    @eybersjp
    OwnerAuthor

    Verified exact v0.13 integration-head CI (30 Oct 2026): draft PR #92 commit 67570ce802cddb9c76a0bfa6480d092049874a19, GitHub Actions #41015777874, Ubuntu PASS and Windows PASS in the v0.13 compatibility/regression lane. This is the first verified two-platform run on this exact final-so-far head, not the required two distinct runs and not deterministic ACCEPTED. Windows NTFS ACL security-descriptor P1 is now under test-first draft diagnostic PR #100; its CI is pending. Three distinct independent source-bound role approvals, physical power-loss evidence and remaining P1 disposition are still required. Do not merge or release.

  11. eybersjp commented on Oct 30, 2026

    @eybersjp
    OwnerAuthor

    2026-10-30 exact v0.13 integration-head evidence (not acceptance): draft PR #92 at a580c6e2845d743149d1b0e164f2d1b30ef4d3a0 passed both Ubuntu and Windows full v0.13 compatibility/regression jobs in https://github.com/eybersjp/development-kit/actions/runs/41022585209. Test-first W73-22 helper-result validation: diagnostic PR #102 RED both platforms #41021958044, corrected GREEN both platforms #41022103181, source/test-only port to #92 with memory.md updated. Exact-source distinct code, architecture and security reviews were requested at #92 (comment); no authenticated approvals/receipts exist yet. Remaining blocking P1 includes Windows NTFS ACL preservation (diagnostic PR #101 CI failed), Issue #73 physical power-loss/rename durability assurance, second distinct full Ubuntu/Windows validation on the eventual identical final reviewed SHA, and deterministic persisted risk-3 ACCEPTED. No mainline merge, no v0.12 inclusion, no release; Issue #71 remains OPEN.

  12. eybersjp commented on Oct 30, 2026

    @eybersjp
    OwnerAuthor

    2026-10-30 v0.13 P0 engineering checkpoint (NOT ACCEPTED): integration candidate remains draft PR #92 (feature/v0.13-state-engine-v2), currently at 1f2c909816287aeceb7aca1f2fd4e6dd9a68aadf. Test-first draft diagnostic PR #104 reproduced NTFS DACL/helper gaps on red Ubuntu/Windows CI #41029403553. Corrected diagnostic source 6b76951413f3798fe2800a5082cda52ce5132e57 passed both complete Ubuntu and Windows v0.13 compatibility/regression jobs in https://github.com/eybersjp/development-kit/actions/runs/41029930369; its focused real Windows NTFS W73-21/23/24 plus legacy restore tests passed 7/7, 0 skipped in https://github.com/eybersjp/development-kit/actions/runs/41029930153. Only validated native helper, migration runtime and test files were ported into PR #92; diagnostic CI workflow exceptions were not ported. The port protects a private NTFS stage during sensitive child copy, restores/verifies original child DACLs before widening root DACL, and verifies native-helper success against exact Windows directory identity across 8.3 aliases. PR #92 exact-head CI https://github.com/eybersjp/development-kit/actions/runs/41030766378 is still running; do not count it as passed yet. Outstanding: Issue #73 physical Windows power-loss durability, three genuinely independent code/architecture/security reviews bound to final immutable source, two distinct full Ubuntu/Windows runs on the final reviewed SHA, deterministic persisted risk-3 ACCEPTED and protected v0.13 release approval. No PR merge or release.

  13. eybersjp commented on Oct 30, 2026

    @eybersjp
    OwnerAuthor

    2026-10-30 — exact integration-head cross-platform validation completed, NOT T04 acceptance. Draft PR #92 at immutable 1f2c909816287aeceb7aca1f2fd4e6dd9a68aadf passed both Ubuntu and Windows full v0.13 compatibility/regression jobs in https://github.com/eybersjp/development-kit/actions/runs/41030766378. This follows red test-first diagnostic CI #41029403553 and corrected full diagnostic Ubuntu/Windows CI #41029930369; focused real Windows NTFS W73-21/W73-23/W73-24 plus legacy restore tests passed 7/7, zero skipped in #41029930153. Changes are confined to Windows native ACL helper, restore runtime, regression tests and repository memory.md; diagnostic-only CI workflow was not ported. PR #92 remains draft, open, unmerged, with zero independent submitted reviews and zero review threads at this check. Issue #73 remains OPEN: no physical NTFS sudden-power-loss ordering proof; Issue #84 remains OPEN. The required second distinct full Ubuntu/Windows validation execution on the same final reviewed head, three distinct authenticated source-bound code/architecture/security approvals, security-domain evidence and deterministic persisted risk-3 ACCEPTED are still absent. No merge or release is authorized.

  14. eybersjp commented on Oct 30, 2026

    @eybersjp
    OwnerAuthor

    2026-10-30 — v0.13 T04 exact integration-head validation update (NOT ACCEPTED): draft PR #92 (feature/v0.13-state-engine-v2) immutable commit 993ec2a73158a472606a30afb5f0bc100a2b32b9 passed both full Ubuntu and Windows v0.13 compatibility/regression jobs in GitHub Actions run #41045115029, conclusion SUCCESS. The same TEST B correction from diagnostic PR #99 is present byte-for-byte on this head (same blob SHA bbf1d2858226daf4cd9941612bcc9887b0ab106f); diagnostic run #41015133002 also passed, but its different source SHA cannot count as the second exact-head validation. PR #92 has zero submitted independent reviews and zero review threads at inspection. Windows Issue #73 remains OPEN: real hosted Windows tests and Win32 helper success are not controlled physical NTFS sudden-power-loss evidence. Required before risk-3 acceptance: second distinct complete Ubuntu/Windows validation execution on the eventual identical reviewed SHA; genuinely independent exact-SHA code, architecture and security review; physical power-loss/namespace ordering evidence and approved contract; deterministic persisted ACCEPTED. No release, no merge, no fabricated approval or hardware claim.

  15. eybersjp commented on Oct 30, 2026

    @eybersjp
    OwnerAuthor

    30 Oct 2026 — v0.13 P0 T04 exact-head CI evidence, NOT acceptance. Actual integration candidate is draft PR #92 (feature/v0.13-state-engine-v2), immutable head 7351c08c2aae444c3230b1397c7a805ccfde9b73 (v0.12.1 baseline). GitHub Actions CI #41054394842 completed SUCCESS for both validate (ubuntu-latest) and validate (windows-latest) on this head, including v0.13 compatibility/regression lanes. This is one verified dual-platform workflow execution, not two independent full executions on an identical final reviewed SHA. The W73-27 Windows alias-journal guard had test-first negative control CI #41052720876 and corrected diagnostic dual-platform green CI #41053285824, but actual NTFS 8.3 aliases were unavailable on the hosted runner; the extended-length namespace alias was tested. PR #92 currently has two unresolved inline P1 review threads (trusted PowerShell interpreter and NTFS alias journal binding; the first is outdated in diff, neither is independently approved/closed), and no three distinct authenticated exact-final-source code/architecture/security approvals. Issue #73's controlled physical NTFS power-loss evidence remains outstanding. No persisted risk-3 ACCEPTED verdict, no merge, no release authorization. Do not promote or close #71/#73 based solely on green CI.

  16. eybersjp commented on Oct 30, 2026

    @eybersjp
    OwnerAuthor

    2026-10-30 v0.13 PR #92 independent P1 source findings — test-first engineering in isolated draft diagnostics (no acceptance/merge):

    1. Prototype-sensitive JSON patch replay (PR feat(v0.13): State Engine V2 durability and migration #92 review thread at runtime/orchestration/state-engine-v2.mjs:790): diagnostic PR T04 diagnostic: test-first prototype-safe state patch replay (P1) #109, test-only commit 692084d0b02194a39f563e1f90705077eb771f75, GitHub Actions #41057142898 reproduced global Object.prototype mutation on Ubuntu and Windows. Narrow correction 7d55832a640400948d7cf896bcc18b822c223471 changes diff and patch traversal to own-property checks and data-property definitions. Ubuntu full v0.13 lane passed in #41057264710; Windows still running at this checkpoint. No source port claimed yet.

    2. Initial ledger layout racing an acknowledged writer (PR feat(v0.13): State Engine V2 durability and migration #92 review thread at state-engine-v2.mjs:518): diagnostic PR T04 diagnostic: first-layout ledger publication race (P1) #110, deterministic interleaving test corrected at 079a92a9a8b8d9b379a7b774d5edcc2790c91d74; Ubuntu CI #41057459611 reproduced actual acknowledged-event loss (events.jsonl empty after concurrent successful commit). Narrow correction d1b1d9e32e1ac74e4b8ee98fd7a1fdb7c6a79915 uses exclusive non-replacing, descriptor-pinned initial file creation. Ubuntu/Windows full v0.13 lanes pending at this checkpoint. Do not port until verified.

    Both diagnostics use workflow exceptions only to run the v0.13 lane; these exceptions must NOT be ported into actual PR #92. T04 still requires physical NTFS sudden-power-loss evidence (Issue #73), independent exact-source code/architecture/security reviews, repeated full cross-platform validation on final source, and authentic persisted risk-3 ACCEPTED. PR #92 remains draft/unmerged.

  17. eybersjp commented on Oct 30, 2026

    @eybersjp
    OwnerAuthor

    2026-10-30 follow-up to Issue #71 evidence comment 6523161013 — two independently reproduced PR #92 P1 findings now have cross-platform green diagnostic CI and narrowly ported fixes:

    Unresolved: distinct authenticated source-bound code/architecture/security approvals and all outstanding P1 threads, controlled physical NTFS power-loss proof for Issue #73, two independent complete Ubuntu/Windows workflow executions on identical final reviewed SHA, persisted deterministic risk-3 ACCEPTED. PR #92 remains DRAFT/UNMERGED; v0.12.1 baseline unchanged.

  18. eybersjp commented on Oct 30, 2026

    @eybersjp
    OwnerAuthor

    2026-10-30 exact combined v0.13 PR #92 integration-head CI checkpoint: final source SHA 3dd4f0aac2fb2ea9cd63b1e99419211220ec3d41 (both test-first P1 corrections and memory.md) completed GitHub Actions #41058735438 with Ubuntu full v0.13 validation SUCCESS and Windows full v0.13 validation SUCCESS. The earlier intermediate PR #92 source SHA 42df7f1f58ba899e817618964a5975b5f8ace52f also passed Ubuntu/Windows in #41058283905, but that is a different SHA and cannot be counted as a second full validation on the final reviewed head. The diagnostic PR #109/#110 negative-control and correction runs are separately documented above. No source modifications are made by this comment.

    Not ACCEPTED: exact final SHA still requires a second distinct complete Ubuntu+Windows workflow execution, three distinct authenticated source-bound code/architecture/security review approvals and independent resolution of outstanding P1 threads, Issue #73 controlled NTFS physical power-loss assurance, and persisted deterministic risk-3 ACCEPTED. PR #92 remains draft/unmerged, and v0.12.1 remains the published baseline.

  19. eybersjp commented on Oct 30, 2026

    @eybersjp
    OwnerAuthor

    30 Oct 2026, v0.13.0 P0 exact integration source verification (NOT ACCEPTED). Actual candidate is draft PR #92 feature/v0.13-state-engine-v2 at immutable SHA 3dd4f0aac2fb2ea9cd63b1e99419211220ec3d41 (v0.12.1 baseline); historical PR #70 is not the integration target. GitHub Actions run #41058735438 reports successful complete validate (ubuntu-latest) and validate (windows-latest) jobs on this head. This is one exact-head CI workflow execution, not the required two independent full runs. Four P1 review threads on PR #92 remain GitHub-unresolved: Windows interpreter provenance r4423012888 (outdated), NTFS 8.3 journal alias r4423012895 (current), concurrent initial ledger publication r4423628008 (outdated), prototype-safe patch replay r4423628018 (outdated). Test-first corrections for these areas are recorded in PR #92 memory.md, but resolved state and independent code/architecture/security approval must not be inferred from outdated thread markers or green CI. Fresh exact-SHA Codex re-review requested at PR #92 comment 6523829863; that request is not a role receipt. Issue #73 controlled physical NTFS sudden-power-loss evidence remains absent. No persisted deterministic risk-3 ACCEPTED was found, no merges/releases authorized. Preserve full Windows legacy restore and fail-closed recovery; do not close #71/#73 or promote T04 before genuine evidence.

  20. eybersjp commented on Oct 30, 2026

    @eybersjp
    OwnerAuthor

    30 Oct 2026 — v0.13.0 T04 test-first P1/P2 source corrections integrated, NOT ACCEPTED. Actual integration draft PR #92 (feature/v0.13-state-engine-v2), final current source/memory SHA 19cf3bbee2cd2eeb49766e31e0aafd8a69ee9cfb (released v0.12.1 baseline). Isolated diagnostic draft PR #112 test-only SHA 8fbc216705e2f4bf736ef63cf160a163cc5181cd reproduced two genuine failures on both platforms in GitHub Actions #41066475740: (1) inherited __proto__/constructor entity keys could masquerade as existing records and corrupt identity/index semantics; (2) concurrent initializer could observe a published but empty schema.json. Corrected diagnostic SHA 16cd69e20a443eb75689bb3bc30fc9237bfb7f9a passed both full Ubuntu and Windows v0.13 CI lanes, including full compatibility regression, in #41066604563. Only two source/test files were ported to PR #92: scripts/state-engine-v2.test.mjs at 7c199d0dc637663adee27a14428507c88ebbcd49 and runtime/orchestration/state-engine-v2.mjs at e75c6225f1090225504c68815f56035e59f462a8; memory.md records evidence at 19cf3bbee2cd2eeb49766e31e0aafd8a69ee9cfb. No diagnostic workflow exception or historical branch merge was ported. Exact final integration SHA requires new dual-platform CI and two independent full runs on that identical reviewed head, fresh distinct authenticated code/architecture/security reviews, disposition of all PR #92 P1/P2 threads, and Issue #73 controlled physical NTFS power-loss evidence. No physical power-loss certification, reviewer approval, persisted ACCEPTED, merge or release is claimed.

  21. eybersjp commented on Oct 30, 2026

    @eybersjp
    OwnerAuthor

    30 Oct 2026 — Two distinct complete cross-platform CI executions on the exact v0.13 T04 integration head (NOT ACCEPTED). Actual draft PR #92 source/memory SHA 19cf3bbee2cd2eeb49766e31e0aafd8a69ee9cfb passed full validate (ubuntu-latest) and validate (windows-latest) jobs in independent GitHub Actions run #41067803155 and run #41067865090. Both workflow executions completed SUCCESS; each ran v0.13 State Engine V2 and complete v0.13 compatibility/regression. The second execution was triggered by CI-only draft PR #113 created directly from the identical immutable commit, with no source modification; PR #113 must not merge. The first execution is on actual integration PR #92. Test-first negative-control and corrected diagnostic evidence is separately recorded above (PR #112). Remaining blockers: six GitHub-unresolved PR #92 review threads, no authenticated distinct exact-head code/architecture/security PASS reviews, Windows Issue #73 controlled NTFS sudden-power-loss durability assurance, and no persisted deterministic risk-3 ACCEPTED verdict. Issues #71/#73/#84 remain open. Two green full CI runs are necessary but not sufficient. No approval, physical test, merge, release or T04 acceptance is claimed.

  22. eybersjp commented on Oct 30, 2026

    @eybersjp
    OwnerAuthor

    30 Oct 2026 — v0.13 T04-H56 test-first fail-closed pending recovery correction (NOT ACCEPTED). Actual integration remains draft PR #92 (feature/v0.13-state-engine-v2) based on released v0.12.1. Diagnostic draft PR #122 reproduced a real evidence-preservation defect on the exact PR #92 baseline: snapshot witness fs.readFileSync errors (EACCES/I/O) were swallowed as disposable derived-state corruption, allowing canonical pending-ledger repair before the snapshot witness could be inspected. The descriptor-relative-path-aware T04-H56 negative control FAILED on both Ubuntu and Windows in CI #41126196799 (RED). Narrow correction treats only ENOENT as absent snapshot; all other read errors abort before ledger mutation or journal deletion. Corrected diagnostic SHA ee0e5f69b9f619b87a694bb3f93d3790873323c2 passed both full Ubuntu and Windows v0.13 compatibility validation lanes in CI #41126337280 (GREEN). Ported only regression test 77bfac8f398b733f16ebf4ea55f272e3c96d0069 and runtime source a2dc909cb69f5e73acfd1a038f9c8272a7e2c94a to PR #92, with memory.md provenance at f3bc71988cc8a472aaeabefc2397ebe5db4c1d85. Diagnostic PR #122 is unmerged. The new integration SHA requires its own CI and independent exact-source code/architecture/security review; 13 review threads remain unresolved, Issue #73 lacks controlled physical NTFS power-loss evidence, review receipts are pending, and no persisted deterministic ACCEPTED exists. Do not merge or release.

  23. eybersjp commented on Oct 30, 2026

    @eybersjp
    OwnerAuthor

    30 Oct 2026 — two genuine source-exact Ubuntu/Windows validation executions for v0.13 T04 (NOT ACCEPTED). Actual integration draft PR #92 remains at immutable source 0e351370e156765634683865cc1f57b8105d9bc3 (released v0.12.1 baseline). After T04-A17 test-first checkout fix, two distinct authenticated GitHub Actions executions validated that same exact source, not a synthetic PR merge:

    This corrects the prior invalid source attribution: #41127165486 and #41127572518 ran on GitHub synthetic merge commits, so were not eligible as exact-source passes. The new pair (#41132327533, #41132505678) is eligible for later review receipt provenance only while the reviewed source remains 0e35137. No receipt has been populated because three distinct independent authenticated APPROVED code/architecture/security reviews are still absent; 13 inline PR #92 threads remain unresolved and Issue #73 still lacks independently reviewed controlled physical NTFS sudden-power-loss evidence. The deterministic risk-3 ACCEPTED verdict is NOT persisted, Issue #71/#73 remain open, and no merge or release is authorized.

  24. eybersjp commented on Oct 31, 2026

    @eybersjp
    OwnerAuthor

    31 October 2026 — T04-A20 test-first concurrency correction (NOT ACCEPTED). Authoritative v0.13 draft integration PR #92 (not historical PR #70) had a live-writer race in cleanupOrphanedStateTemps(): orphan cleanup could unlink another active writer's fsynced events.jsonl.tmp-<pid>-<uuid> before its atomic rename. Isolated unmerged draft PR #130 added a regression first; both Ubuntu and Windows failed at the expected active-stage assertion in RED CI #41171427038. An initial fix had an over-escaped filename regex and failed the existing interrupted-stage cleanup test in CI #41171525251; corrected diagnostic SHA 54162254d1a7c57c5d807f2385da760bed91a9b9 passed full Ubuntu and Windows validation in GREEN CI #41171601007. Only the validated source/test were ported to PR #92 (106847dd1afb38b29fbe419bacf292753d54e5ba, dddf27d18a8533a5f3541339bffa1958f6d98e25); memory.md records evidence at d405dc7fa7abb18d8bc59eee0c816b00e7454b79. The change preserves live or unknown PID-owned temporary stages, restricts cleanup to internal filenames and avoids removing hardlinked bootstrap witnesses. This is a narrow concurrency correction, not proof of Windows physical power-loss durability or independent review acceptance. Production-head full CI, 13 review threads, three independent source-bound reviews, Issue #73 and persisted deterministic ACCEPTED remain required. No merge or release authorized.

  25. eybersjp commented on Oct 31, 2026

    @eybersjp
    OwnerAuthor

    31 October 2026 — T04-SEC-JSON-01 test-first source correction (NOT ACCEPTED). Actual v0.13 integration is draft PR #92 on v0.12.1; historical PR #70 is not the integration target. cloneSerializable() allowed Map, Set, Date, undefined properties and non-finite numbers to be acknowledged even though JSON event serialization silently discards/transforms them. Isolated unmerged diagnostic PR #132 test-only SHA 3ae982c72fbee77bf38768f813e80547cf36a623 reproduced the loss on both Ubuntu and Windows in RED CI #41176319558 (Missing expected exception: Reject Map). Narrow correction verifies a lossless JSON parse round-trip before committing; diagnostic SHA 728291c317eb7b009a1c8164437b7869b279052f passed both complete Ubuntu/Windows v0.13 CI jobs in GREEN CI #41176399858. Ported only the validated runtime and test to PR #92 via e11da547b776c2cf306974535d1fd20f5ed6f7bb and 5d39940177330274ba6e37033e1c316d08263487, plus memory evidence at final integration SHA c0ba032e6fa6607c9a0aa288bc7c5fb1d7349aea. Fresh integration CI #41177010675 was queued at observation, NOT yet claimed green. PR #132 remains draft, unmerged, and must not be merged. No physical NTFS power-loss test, independent role approval, review-thread closure, persisted ACCEPTED, merge or release is claimed. Issues #71/#73/#84 remain open; full Windows restore, journal and original-tree preservation, fail-closed behavior and v0.12.1 compatibility remain mandatory.

  26. eybersjp commented on Oct 31, 2026

    @eybersjp
    OwnerAuthor

    T04-H57 test-first source/security correction — 31 Oct 2026 (NOT ACCEPTED). On actual v0.13 integration PR #92, two fault-injection tests proved that replacing events.jsonl with a hard link at the tail-repair r+ open caused newline completion or torn-tail truncation to mutate unrelated external bytes. Test-only SHA 2c8f9cc024768213d6d66ce650623daeead7336c reproduced both failures on Ubuntu and Windows in RED CI #41180716611. Narrow descriptor-bound correction SHA 4e969e2578b8c42ddc05c06ed304fae55baed78e passed both full Ubuntu and Windows validation jobs in GREEN CI #41180784890. The separate acceptance job failed as designed: missing authentic exact-source independent reviews. Engineering replied with test/source evidence and dispositioned 11 of 13 PR #92 review threads; the remaining P1/P2 concern actual NTFS 8.3 ancestor aliases and staged destination collisions and stay open. memory.md evidence commit 8a808475bea114b9bb4ea010b38e4498b9395ae3 changes integration HEAD and requires new CI. No ACCEPTED verdict, no merge, no physical NTFS power-loss proof, no independent role approvals. Issue #73 remains a mandatory separate blocker.

  27. eybersjp commented on Oct 31, 2026

    @eybersjp
    OwnerAuthor

    31 October 2026 — exact-head two-run v0.13 T04 engineering verification (NOT ACCEPTED). Authoritative draft PR #92 immutable head 35b1667d3e7c7dd9956c045aef18bac991fee082 (released v0.12.1 base) completed two distinct authenticated full Ubuntu/Windows GitHub Actions workflow executions on identical source: integration run #41183000671 and no-change CI-only draft PR #135 run #41183246186. All four platform validation jobs PASS; logs show HEAD is now at 35b1667 in each, and both real Windows runs report W73-8DOT3-01 and W73-8DOT3-02 PASS, not SKIP. Source/test hardening from PR #92 plus these tests preserves hash-chained journal witnesses and detects actual NTFS short-name aliases. All 15/15 PR #92 inline review threads are resolved with engineering dispositions, but this is not three independent approvals. The production risk-3 acceptance job in #41183000671 FAILED as designed (Missing exact-source independent reviews); the CI-only PR #135 acceptance job was skipped as designed. Review register still records reviewedCommit: null, reviews: [], validationRunIds: [], windowsPhysicalPowerLoss: null, PENDING_INDEPENDENT_REVIEWS. Issue #73 controlled sudden physical NTFS power-loss evidence and three distinct authenticated exact-SHA code/architecture/security review approvals are still required. The existing two-run CI evidence is real but not yet bound by an accepted review register. PR #92 remains draft/unmerged; PR #135 is a no-change diagnostic and MUST NOT MERGE. No authentic persisted ACCEPTED verdict, release approval, merge or publication.

  28. eybersjp commented on Oct 31, 2026

    @eybersjp
    OwnerAuthor

    31 Oct 2026 — T04-A22 false-acceptance control corrected on v0.13 integration PR #92, not T04 acceptance. An arbitrary green same-SHA workflow could previously satisfy securityControls[].workflowRunId; the risk-3 gate now requires membership in the independently authenticated full Ubuntu+Windows validationRunIds set. Test-first RED on both OS: diagnostic PR #136 SHA efd80c2068f180a1bed5337d7804887efce03e94, CI #41185875905. Diagnostic GREEN both OS: SHA 08734c3148d4a8cd2b4f15fc66c47683732620c8, CI #41185891626. Ported source/test/memory to authoritative draft PR #92 SHA 017916a4662bd7f271e92e4548415d09aa93dd79. Two complete source-identical Ubuntu/Windows runs PASS: #41186309042 and #41186342573. Independent T04 acceptance correctly FAILED CLOSED for missing reviews. Issue #71 remains OPEN; Issue #73 physical NTFS evidence and three exact-source independent role approvals are still mandatory. No waiver, merge, release or ACCEPTED claim.

  29. eybersjp commented on Oct 31, 2026

    @eybersjp
    OwnerAuthor

    v0.13 H68 cooperative migration/cutover gate — operator recovery boundary (31 Oct 2026; not acceptance). Authoritative draft PR #92 source 91564ad0bbc55cf306858512b95f3e846e2f0ad3 introduces .development-kit/.state-migration.lock, atomically created with wx and owner token, held from legacy inspection through backup/import/completion and acquired by supported legacy/V2 state writers before authority selection. A lock is never automatically reclaimed by age or PID alone; competing writers fail closed after bounded wait. For an orphaned gate: (1) take the entire project offline and independently verify all DKF migration, Autopilot and orchestration writers have terminated (PID alone is insufficient due reuse); (2) preserve an immutable copy of the lock bytes/metadata, legacy current pointers/revisions/manifests, V2 events/pending/snapshot/index and legacy backup; (3) inspect verifyStateEngineIntegrity and the backup/legacy source witness without modifying either; (4) only an authorized operator with exclusive filesystem control may remove the gate and retry recovery/migration, preserving original evidence if uncertainty remains. This is a proposed fail-closed operator procedure, not an approved waiver of full Windows restore, Issue #73 NTFS power-loss assurance, or same-UID hostile writer limitation Issue #72. Test-first H68 RED 41233222609, diagnostic full Ubuntu/Windows GREEN 41240549095; integration exact-head dual CI pending. Independent risk-3 reviewers must assess the gate's lifecycle and operator procedure before closure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions