Skip to content

Decide: is absolute-zero/ a deliberate fork or stale vendor copy? #84

Closed
#89
Closed
Decide: is absolute-zero/ a deliberate fork or stale vendor copy?#84
#89
Labels
tech-debtKnown shortcut, drift, or hygiene owed - includes cleanup

Description

@hyperpolymath
hyperpolymath
opened on May 27, 2026

Context

Triage PR #82 classified the 150 markers in absolute-zero/proofs/{coq,lean4,agda}/ as §(e) VENDORED — estate-sibling, on the assumption that this directory is a vendored copy of hyperpolymath/absolute-zero. Cross-tree diff against canonical absolute-zero/main (commit 6a17152) shows this is not a vendored copy — it's a structurally divergent fork.

The classification, the §(e) schema extension in docs/proof-debt.md, and the answer to "submodule yes/no" all depend on which of the dispositions below applies. Filing here so the right disposition is owner-chosen, not Claude-guessed.

Evidence of fork (not vendor)

Files in maa-framework's copy with no upstream home

absolute-zero/proofs/agda/:

  • EchoBridgeCNO.agda
  • EchoBridgeScaffold.agda
  • README.adoc

(Naming pattern strongly suggests maa-framework↔absolute-zero integration bridges.)

Top-level absolute-zero/:

  • ABI-FFI-README.md
  • benches/
  • CLAUDE.adoc
  • CONTRIBUTING.md
  • COOKBOOK.adoc
  • COORDINATION.md
  • docs/reports/
  • ECHIDNA_INTEGRATION.adoc
  • ECHIDNA_MALBOLGE_REPORT.md
  • ECHIDNA-NEUROSYM-INTEGRATION.adoc
  • eclexiaiser.toml
  • examples/go/

The ECHIDNA_* files are almost certainly maa-framework-specific — they describe maa-framework's integration with Echidna, which doesn't live in canonical absolute-zero.

Files in canonical absolute-zero/main not in maa-framework's copy

  • 0-AI-MANIFEST.a2ml
  • absolute-zero-abi.ipkg
  • absolute-zero.agda-lib
  • AUDIT.adoc
  • CHANGELOG.md
  • docs/proof-debt.md ← canonical proof-debt index (Phase 1 triage outcome)
  • docs/proof-debt-triage.md
  • docs/PROOF-CLASSIFICATION.adoc
  • docs/PROOF-COMPLETION-PLAN.adoc
  • docs/PROOF-INSIGHTS.md
  • docs/PROOF-VS-TEST-SUBJECTS.adoc
  • docs/MACHINE_VERIFICATION.adoc
  • docs/MAINTAINERS.adoc
  • docs/JUSTFILE-COOKBOOK.adoc
  • docs/RSR_OUTLINE.adoc
  • docs/wiki/
  • docs/archive/
  • docs/tech-debt-2026-05-26.md
  • ECHIDNA.adoc
  • tech-debt-2026-05-26.md
  • VERIFICATION_RESULTS.adoc

Most of these are weeks-fresh canonical work (the Phase 1 proof-debt triage docs from absolute-zero#58/#59 landed 2026-05-27).

Content drift in proof sources

Three proof files differ between the two trees:

  • proofs/coq/quantum/QuantumCNO.v
  • proofs/coq/quantum/QuantumMechanicsExact.v
  • proofs/lean4/QuantumCNO.lean

Direction of drift not yet characterised — could be maa-framework specialisations or upstream-only fixes.

Possible dispositions

(A) Deliberate fork

The ECHIDNA_* files and EchoBridge*.agda strongly suggest this. maa-framework maintains its own absolute-zero variant for its Echidna/Malbolge integration evaluation, and the divergence is intentional.

If (A): the right action is rename + reframe, not submodule. Move the directory to e.g. maa-framework/integrations/absolute-zero-fork/, add a top-level README declaring it a fork, and reclassify the 150 markers as estate-owned §(c)/(d) (because maa-framework owns the fork → the unproven axioms are maa-framework's responsibility, not absolute-zero's).

(B) Stale vendor copy with accidental accretion

Someone started vendoring, then dropped maa-framework-specific files into the vendored tree without considering that it was meant to track upstream.

If (B): the right action is extract + submodule. Lift the maa-framework-specific files (ECHIDNA_, EchoBridge.agda, benches/, examples/go/) out of absolute-zero/ into maa-framework's own top-level tree. Upstream any general-interest improvements (likely the QuantumCNO drift) to absolute-zero. Then replace absolute-zero/ with a submodule pinned to canonical absolute-zero/main.

(C) Hybrid

Parts (A) and parts (B). Most plausible in practice — the ECHIDNA_* docs are clearly (A), but the QuantumCNO drift could go either way without inspection.

Until decided

  • PR docs: seed proof-debt.md per standards#203 schema (all 150 markers §(e) vendored) #82 lands with §(e) VENDORED classification (semantically imprecise but factually correct that markers are path-enumerated). check-trusted-base.sh will pass.
  • This issue should be the blocker for any subsequent action on absolute-zero/.
  • The maa-framework proof-debt.md should NOT yet be considered authoritative — the §(e) section will need rewriting once disposition lands.

Suggested first step

Inspect the three drifted proof files (QuantumCNO.v / QuantumMechanicsExact.v / QuantumCNO.lean) to see whether the drift is maa-framework-specific (likely (A)) or general-interest (likely (B)) — that should disambiguate disposition with little effort.

Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com

🤖 Generated with Claude Code

Activity

  1. hyperpolymath commented on May 27, 2026

    @hyperpolymath
    hyperpolymath
    on May 27, 2026
    OwnerAuthor

    Drift characterisation — disposition narrowed to (B) Stale vendor + accidental accretion

    Inspected the three drifted proof files plus the maa-framework-only Agda files. Findings flip my prior recommendation toward (B), with a clear 3-step execution plan.

    Proof-source drift is purely "vendor is stale"

    All three diverging proof files (QuantumCNO.v, QuantumMechanicsExact.v, QuantumCNO.lean) have the identical drift pattern: canonical absolute-zero/main has Phase 2d trusted-base annotation comments ((* AXIOM: ... §(c) per docs/proof-debt.md (Phase 2d triage). *)) that maa-framework's copy lacks. Zero structural code changes; zero maa-framework-specific changes. The maa-framework copy is a snapshot from before absolute-zero#58/#59 landed.

    Numbers: 80 diff lines (QuantumCNO.v), 11 diff lines (QuantumMechanicsExact.v), 36 diff lines (QuantumCNO.lean). Every single one of those lines is an annotation comment, not a semantic change.

    The "maa-framework-only" Agda files are absolute-zero's, not maa-framework's

    The 3 Agda files only present in maa-framework's copy (EchoBridgeCNO.agda, EchoBridgeScaffold.agda, README.adoc):

    • The header of EchoBridgeScaffold.agda says: "Echo/CNO Agda bridge scaffold. This module is intentionally independent from CNO.agda so it can stay typecheckable while that file is still being completed." — i.e. it's bridging absolute-zero's CNO construct to hyperpolymath/echo-types.
    • The README.adoc literally titles itself: "Agda Proofs (absolute-zero)" — claims absolute-zero ownership.
    • No reference to maa-framework or Echidna anywhere.

    These are upstream-orphans: written for absolute-zero, never landed upstream, only ever existed in the maa-framework vendored copy.

    Disposition: (B) Stale vendor copy with accidental accretion

    The accretion separates cleanly into two buckets:

    Bucket 1 — belongs upstream in absolute-zero (the EchoBridge files):

    • proofs/agda/EchoBridgeCNO.agda
    • proofs/agda/EchoBridgeScaffold.agda
    • proofs/agda/README.adoc

    Bucket 2 — belongs at maa-framework's top level (the Echidna integration docs):

    • ABI-FFI-README.md
    • benches/
    • CLAUDE.adoc, CONTRIBUTING.md, COOKBOOK.adoc, COORDINATION.md
    • docs/reports/
    • ECHIDNA_INTEGRATION.adoc, ECHIDNA_MALBOLGE_REPORT.md, ECHIDNA-NEUROSYM-INTEGRATION.adoc
    • eclexiaiser.toml
    • examples/go/

    These are maa-framework artefacts that got dropped inside the vendored absolute-zero/ directory by mistake. Their natural home is maa-framework's own tree.

    Execution plan (3 sequential PRs)

    1. absolute-zero PR: add the 3 EchoBridge files (Bucket 1) to canonical proofs/agda/. Cite this issue as origin.
    2. maa-framework PR (a): move Bucket 2 files OUT of absolute-zero/ into maa-framework's top-level tree (e.g. docs/echidna/, benches/, examples/go/). Pure-move, no content edits.
    3. maa-framework PR (b): after (1) merges and absolute-zero/main contains the EchoBridge files, replace absolute-zero/ with a submodule pinned to the new absolute-zero HEAD. Update docs/proof-debt.md to drop the §(e) VENDORED section — the markers now have a clean canonical home upstream, and maa-framework's proof-debt becomes empty (or limited to whatever's in Bucket 2 that happens to bear markers, which is none).

    This is sequential because (3) needs absolute-zero/main to have the EchoBridge files for the submodule pin to make sense.

    Total effort: ~2-3 small PRs. The path is mechanical; no further owner judgement needed beyond the green-light to execute.

    Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com

  2. hyperpolymath
    added a commit that references this issue on May 27, 2026

    feat(proofs/agda): upstream Echo/CNO bridge files from maa-framework …

    282c204

  3. hyperpolymath commented on May 27, 2026

    @hyperpolymath
    hyperpolymath
    on May 27, 2026
    OwnerAuthor

    Status update (2026-05-27): premise superseded — disposition revised to (B), not (C)

    The "deliberate fork" evidence in this issue's body is now stale. PR #83 (sync: re-vendor absolute-zero/ subtree to upstream HEAD, commit b184e57, merged earlier today) removed the maa-only files this issue cited:

    • All 12+ top-level "fork signal" files (ECHIDNA_INTEGRATION.adoc, ECHIDNA_MALBOLGE_REPORT.md, ECHIDNA-NEUROSYM-INTEGRATION.adoc, CLAUDE.adoc, CONTRIBUTING.md, COOKBOOK.adoc, COORDINATION.md, ABI-FFI-README.md, eclexiaiser.toml, benches/, examples/go/, docs/reports/) are gone from the vendored tree.
    • The 2 EchoBridge*.agda files (the strongest "fork" indicator) were already upstreamed via absolute-zero#65 (feat(proofs/agda): upstream Echo/CNO bridge files from maa-framework vendored copy) and now live in both trees identically.
    • File-set partition today: 174 paths byte-identical, 0 maa-only, 2 upstream-only (new proofs/coq/common/PhysicsConstants.v + StatMechBasis.v from upstream PR #67).
    • Only maa string remaining in vendored content: a stale \url{https://gitlab.com/maa-framework/...} in a BibTeX entry, identical in both trees.

    Drift inspection (7 files differ)

    All 7 drifted source files differ in the same direction: upstream is newer by ~6 hours and carries the post-vendor Phase 2d/2e + Follow-up 1/2/3 triage work (absolute-zero #63, #66, #67). Pattern across all 7:

    • proofs/coq/quantum/QuantumCNO.v — adds PhysicsConstants import + ~15 inline (* AXIOM: ...; §(c) per docs/proof-debt.md *) annotations
    • proofs/coq/quantum/QuantumMechanicsExact.v — removes dead-code duplicate axioms, +1 AXIOM annotation
    • proofs/lean4/QuantumCNO.lean — ~14 inline AXIOM annotations + 2 §(d) DEBT comments
    • proofs/coq/physics/LandauerDerivation.v, proofs/coq/physics/StatMech.v — PhysicsConstants/StatMechBasis hoisting (Follow-up 1+3)
    • proofs/lean4/StatMech.lean — Phase 2e Lean triage annotations
    • proofs/coq/_CoqProject — new module registrations

    No maa-specific content in any of the drift. Pure upstream-newer.

    Revised disposition

    (C) hybrid was correct when this issue was filed (the body's fork evidence was accurate then). After b184e57, the directory is a clean vendor copy with light drift in one direction, which makes (B) extract-nothing + submodule the right shape now.

    Revised remediation (2 PRs, not 4)

    1. Submodule conversion — drop the absolute-zero/ tree, add it back as a submodule pinned to hyperpolymath/absolute-zero at HEAD (or a tagged commit). Update .gitmodules. Touch any maa-framework build/CI that references absolute-zero/ paths so they resolve through the submodule (likely proofs/ walks in check-trusted-base.sh, justfile targets).
    2. Proof-debt §(e) rewrite — the 150 markers PR #82 listed as VENDORED now either live inside a submodule (owned upstream, drop from maa-framework's count) or, if check-trusted-base.sh walks submodules, get a cleaner §(e) definition ("markers owned by another estate repo via a pinned submodule").

    The earlier PR 1 (upstream contributions) and PR 2 (maa fork extraction) are no-ops because there's no bucket-A content to extract and no maa-specific drift to upstream.

    Open questions before PR 1 lands

    1. Does check-trusted-base.sh follow submodules or not? — answer determines whether maa-framework's §(e) section keeps any rows after conversion.
    2. Stale \url{gitlab.com/maa-framework/...} BibTeX URL in README.adoc exists identically in both trees. Worth a separate small upstream fix; out of scope for the submodule PR.

    Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com

  4. hyperpolymath
    added
    tech-debtKnown shortcut, drift, or hygiene owed - includes cleanup
    on May 30, 2026
  5. hyperpolymath
    added a commit that references this issue on May 30, 2026

    docs: park maa-framework #84 resolution (absolute-zero vendor-copy au…

    334c0ac
  6. hyperpolymath
    closed this as completedin #89on May 30, 2026
  7. hyperpolymath
    added a commit that references this issue on May 30, 2026

    chore(submodule): convert absolute-zero/ to git submodule pinned to u…

    b34e4f9
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

    tech-debtKnown shortcut, drift, or hygiene owed - includes cleanup

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions