|
| 1 | +# ENGI Spec V19 Notes |
| 2 | + |
| 3 | +## Status |
| 4 | + |
| 5 | +- Scope: draft recommendations for the next specification after V18 generated proof closure |
| 6 | +- Prior canonical target: `V18` |
| 7 | +- Prior generated proof appendix: `/Users/garrettmaring/Developer/ENGI/ENGI_SPEC_V18_PROVEN.md` |
| 8 | +- Current V19 state: notes only; no V19 canonical pointer, spec file, parity matrix, or source implementation yet |
| 9 | + |
| 10 | +## Recommended V19 center |
| 11 | + |
| 12 | +V19 should focus on canonical replay determinism and promotion hardening. |
| 13 | + |
| 14 | +V18 proved that ENGI can generate and execute proof-member, theorem-evidence, and state-machine matrices from runtime proof truth. |
| 15 | +It also exposed the next sharper requirement: once more proof surfaces become digested, latent nondeterminism becomes canonical debt. |
| 16 | +The `.engi/eval-manifest.json` digest instability from volatile parsed-completion timestamps is the representative V19 lesson. |
| 17 | + |
| 18 | +The V19 question should be: |
| 19 | + |
| 20 | +Can ENGI prove that the same source, same canonical inputs, and same proof-source commit always regenerate the same canonical appendix and matrix artifacts? |
| 21 | + |
| 22 | +## Primary specification potentialities |
| 23 | + |
| 24 | +1. Deterministic canonical replay |
| 25 | + V19 should require every canonical proof run to be hermetic and replay-stable. |
| 26 | + Digested proof artifacts must not include wall-clock timestamps, process-order drift, random ids, filesystem-order drift, locale drift, environment drift, or unstated runtime inputs. |
| 27 | + |
| 28 | +2. Canonical promotion command |
| 29 | + V19 should specify one promotion workflow that advances `ENGI_SPEC.txt`, regenerates `ENGI_SPEC_VN_PROVEN.md`, runs typecheck, targeted matrix tests, full tests, generator check mode, and diff hygiene, and emits the canonical commit message body. |
| 30 | + This removes manual sequencing as a canonical risk. |
| 31 | + |
| 32 | +3. Generated matrix artifact materialization |
| 33 | + V18 generates matrix data and renders summaries into `_PROVEN_`. |
| 34 | + V19 should decide whether the full generated matrix artifacts are written as canonical structured JSON, so all cells are inspectable without reverse-engineering markdown. |
| 35 | + |
| 36 | +4. Negative proof mutation matrices |
| 37 | + V19 should add generated fail-closed tests that mutate proof inputs and require deterministic rejection. |
| 38 | + Initial mutation classes should include missing digest, corrupted replay step, dropped theorem verdict, mutated member payload, changed projection policy, missing witness path, and changed matrix axis. |
| 39 | + |
| 40 | +5. Source-level projection security matrix |
| 41 | + V17 proved projection behavior through browser operator coverage. |
| 42 | + V19 can add source-level projection-policy assertions across scenario, branch mode, and principal to prove policy visibility directly below the UI. |
| 43 | + |
| 44 | +6. Canonical diff and contract-change ledger |
| 45 | + V19 should generate a version-to-version delta covering proof families, member ids, theorem ids, replay steps, witness artifacts, digest counts, matrix counts, and accepted boundary changes. |
| 46 | + The goal is to make contractual changes explicit before a canonical bump. |
| 47 | + |
| 48 | +7. Deferred UX quality canon |
| 49 | + Visual regression, accessibility, and performance budgets remain valid future canon. |
| 50 | + They should not displace deterministic replay unless V19 is intentionally scoped as a production-quality UX release. |
| 51 | + |
| 52 | +## Recommended V19 acceptance decisions |
| 53 | + |
| 54 | +- Accept reproducible canon as V19's center. |
| 55 | +- Do not introduce new proof families unless determinism or mutation testing reveals a missing category. |
| 56 | +- Treat V18's `1832` generated matrix cells as the closed positive-proof baseline. |
| 57 | +- Treat V19 mutation matrices as negative-proof coverage, not as additions to the V18 positive matrix count. |
| 58 | +- Keep `_PROVEN_` generated-only and require check mode to be stable immediately after generation. |
| 59 | +- Preserve the V16/V17/V18 proof-source commit convention unless V19 explicitly replaces it with self-referential canonical commit generation. |
| 60 | + |
| 61 | +## First implementation path |
| 62 | + |
| 63 | +1. Inventory all volatile fields in canonical proof artifacts. |
| 64 | +2. Add a deterministic replay test that runs `_PROVEN_` generation twice and requires byte-identical output. |
| 65 | +3. Add a proof-artifact volatility scanner for timestamps, random-looking ids, unsorted collections, and environment-derived values. |
| 66 | +4. Add a promotion command or script that executes the canonical bump sequence. |
| 67 | +5. Add negative mutation matrix builders after replay determinism is green. |
| 68 | +6. Decide whether full matrix JSON artifacts become committed canonical outputs or generated side artifacts. |
| 69 | +7. Only then consider source-level projection-security matrices or UX quality gates. |
| 70 | + |
| 71 | +## V19 success condition |
| 72 | + |
| 73 | +V19 is complete when canonical promotion is reproducible, generated proof output is byte-stable, mutation coverage proves fail-closed behavior, and contractual deltas are generated rather than inferred from manual review. |
0 commit comments