Skip to content

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

@hyperpolymath

Description

@hyperpolymath

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

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