Merge igneum-2.0-plan-docs e849cfb3 into master (gate: green on e849cfb3, recorded by tools/ci/pre-push.sh; landed on the box mirror under the exception declared by main: main's ruling, 7 Oct 2026 19:5x UK: the GitHub account is suspended, lanes land on the box mirror's master, the box gate stamp is the verdict; GitHub gets the fast-forward when it answers)

docs/plans/igneum-2.0.md

@@ -144,3 +144,59 @@ Owner: site lane.
 | Secure execution, finality and independently operated infrastructure | Developers and customers trust the network with meaningful activity |
 
 Each row is served only with its evidence beside it. What stops number one: losing on customer acquisition, developer adoption, operator economics or reliability; and GPU competitiveness is a contested claim (Ravencoin states it already), so the site shows a better result, never a more ambitious description.
+
+## Addendum from the complete plan (IGNEUM_2.0_Plan_Light.pdf, 8 October 2026, 37 pages)
+
+The PDF is the complete reference and supersedes the .rtf where they differ; both are kept beside this file (igneum-2.0-plan.pdf, igneum-2.0-plan.txt). These pins were missing above.
+
+### Evidence classes and status discipline (plan p. 5, 25, 27)
+- [ ] Every served claim carries one label: TEAM-REPORTED, MODELLED, PROPOSED, PENDING or EXCLUDED. Status words are distinct and never collapsed: designed, implemented, activated, team-tested, independently reproduced, independently reviewed.
+- [ ] Public wording ladder, each rung with what supports it: "designed for GPU competitiveness" (objective and rationale only); "team-tested" (published procedure, version, result); "independently reproduced" (an unaffiliated operator); "independently reviewed" (a scoped review with its unresolved findings); "top-tier contender" (comparative evidence plus operating and customer proposition); "category leader" (sustained adoption, demand, reliability, retention; never a numerical rank).
+- [ ] Claims never published: guaranteed chip death, a universal ASIC-efficiency ceiling, chip-arrival probabilities without a calibrated model, guaranteed profits, Ethereum security by compatibility, privacy from ZK.
+- [ ] Release evidence packet beside every material claim: source commit, exact parameters, test procedure, raw result, independent-reproduction status, review scope, unresolved limitations.
+
+### Decision register additions (p. 7)
+- [ ] Also excluded, kept as controls: SM gating, wider reads, sealed classes, random epoch lengths, per-tier scoring, VRF draws. The long-program result stays rejected when instruction memory is modelled as shared SRAM, not flip-flops.
+- [ ] The one acceptance rule for any hash change: it passes only when the best adversarial implementation becomes worse relative to the best practical GPU implementation, within pre-agreed cost and verification limits.
+- [ ] Accepted work includes rejected submissions, downtime, epoch preparation, compilation, host power and network delays.
+
+### Rotation mechanisms (p. 11)
+- [ ] Miner-voted bring-forward is specified as a mechanism: activation rule, coalition behaviour, partition handling, old-client behaviour. "No veto" is a mechanism, not a label.
+- [ ] Seed and VDF pipeline: the seed-selection property it protects is stated, and behaviour when finality is unavailable at a seed boundary is defined and tested.
+
+### Independent hardware brief (p. 12)
+- [ ] The adversary's transition matrix, each row a required result: firmware update (throughput, energy, cost before and after each family transition); emulation (penalty for missing native operations; slower is not unprofitable); memory expansion or overprovisioning (board cost, bandwidth, power, survival through the dataset schedule); companion CPU, GPU or FPGA (complete-system economics including hybrid mining and proving); favourable-period mining (revenue after idle, re-entry, difficulty response); silicon revision (incremental cost, reused design work, realistic delay).
+- [ ] Evidence standard: realistic SRAM macros, ports, wiring, memory interfaces, switching activity, complete-board overhead; same-node and advanced-node results kept separate; uncertainty ranges published.
+- [ ] The lifetime rule: a capable programmable design survives several epochs; a retirement benefit is awarded only when the cheapest adaptation loses economic competitiveness.
+- [ ] The disclosure prize rewards a better adversary and a reproduced shortcut, not confirmatory results.
+
+### Coexistence economics additions (p. 13)
+- [ ] Scenario axes include market structure: private supply, public hardware sales, multiple suppliers, concentration.
+- [ ] The USD 340 M and USD 23 M thresholds and the USD 20 to 75 M development range live in a sensitivity workbook with their assumptions, never as served boundaries.
+
+### Miner and operator experience (p. 14)
+- [ ] Desktop-first, a mining console. Easy entry: install, hardware detection, compatibility explanation, safe default tuning. Honest economics: mining, internal proving and external proving income shown separately, net of the operator's entered electricity tariff. Control: power limits, pause and stop, job selection, explicit acceptance of software updates. Failure visibility: rejected work, failed proofs, queue delays, memory pressure, missed payments visible and actionable. Accessible payouts: non-custodial, practical for small operators. Safe execution: proving isolated from wallet secrets and signing authority; security assumptions published.
+- [ ] Hardware profiling lives in the client, never as consensus privilege.
+
+### Proving correctness (p. 16)
+- [ ] The negative test set every validator passes: correct statement with an invalid proof (rejected, no reward); wrong program or verifier identity; wrong chain, epoch or statement binding (replay); changed payout identity; duplicate proof reward; incorrect rewards or consensus inputs (derivation authenticated, not only execution). Each mapped to a test in the enforced-proving set with its version.
+- [ ] Boundary served: a proof of execution is not a proof of authenticated consensus inputs, canonical history or data availability.
+
+### Consensus and failure behaviour (p. 19)
+- [ ] D5 scenario rows: prolonged partition (no conflicting final histories inside the fault assumptions; liveness loss explicit); authority-set transition (verifiable continuity from the last certified history; a timeout alone is not evidence missing voters are gone); signing stops while mining continues (defined checkpoint, weight and recovery; no contradictory certificates); old voting keys compromised (its own analysis, distinct from new hashrate); finality unavailable at a seed boundary (a seed and mining path that does not depend on an unavailable certificate); partitions reconnect (deterministic recovery, no quiet reversal of an irreversible label).
+- [ ] The real integration tested together: ordering, finality, proof queues, voter tables, seed transitions.
+- [ ] User-facing rule everywhere: included, executed, proven and finalised are four states; a safe pause is shown as a pause.
+
+### User verification (p. 20)
+- [ ] Light wallet: starting point, voter weights and authority changes authenticated. Execution proof: the permitted proof verified and its inputs authenticated, never an aggregator statement in its place. Payment receipt: proves the transfer with asset, recipient and amount, or is labelled "transaction-inclusion receipt". Oracle: deployer-installed trust anchors removed or disclosed, unchecked signatures named. Data availability: how state is obtained and reconstructed, explained.
+
+### Operational independence (p. 21)
+- [ ] One machine-readable release manifest: network identity, source commits, mining class, dataset parameters, finality rule, program and verifier identities, activation state, fee schedule. Status pages generate from it; historical records are labelled.
+- [ ] Software release: reproducible builds, pinned source and binaries, explicit operator acceptance, a signing-key incident procedure. A fleet that auto-accepts a release key is operationally centralised.
+- [ ] Public infrastructure, mining, proving and aggregation continue without founder services and without unpublished files or hidden configuration.
+
+### Programme order, mainnet prerequisites, funding (p. 24, 26)
+- [ ] Spend order: proof enforcement and finality boundaries first while closing the v6 evidence packet; hardware research and one narrow paid pilot in parallel; broad ecosystem expansion waits until the core path is secure, reproducible and useful.
+- [ ] Mainnet needs: complete proof enforcement, a resolved finality and recovery model, operator-control tests, the compatible-application test suite, a funded maintenance plan (engineering, audits, infrastructure, incident response), committed funding distinguished from adoption-dependent income; fair launch is a principle, not a funding strategy.
+- [ ] Acceptance scorecard served as a checklist with its "do not substitute" column (plan p. 25), never as a completion dashboard.
+- [ ] Brand kit stands: Unbounded, IBM Plex Sans, IBM Plex Mono; obsidian, ember, graphite, bone, molten.