Specification tickets and dependency-ordered implementation follow-ups.
Core-2 Delivery Roadmap
Status: specification delivery; implementation follows accepted specifications
The parent is ZER5-34 on the ZergLang board.
All work for this wave lands on zerglang-4. Review means specification
delivered with evidence; Done means accepted. Implementation support is a
separate claim. Existing Core-0/Core-1 and self-hosting work remains independent.
| Ticket | Specification deliverable | Depends on |
|---|---|---|
| ZER5-35 | terminology, inheritance, previews | — |
| ZER5-36 | component/port/net/process grammar | 35 |
| ZER5-37 | combinational and four-state semantics | 36 |
| ZER5-38 | clocks, reset and CDC | 37 |
| ZER5-39 | asynchronous and intrinsic semantics | 37 |
| ZER5-40 | physical mesh, quantities, fields and equations | 35 |
| ZER5-41 | model libraries and bridge foundations | 38, 39, 40 |
| ZER5-42 | realization identities and evidence | 38, 39, 40 |
| ZER5-43 | effects, capabilities and matrix | 35, 42 |
| ZER5-44 | ZLM3 logical records, reflection and diagnostics | 36, 40, 42, 43 |
| ZER5-45 | compiler/fabric adapter protocol | 44 |
| ZER5-46 | SolverPlan and generated-solver admission | 41, 42, 44 |
| ZER5-47 | ZL512 allocation and migration | 37–46 |
| ZER5-48 | stable activation and conformance | 47 |
Every ticket includes its clause families, positive/negative examples, publication/validation acceptance and explicit deferred implementation. Attach clean tracked files as commit-pinned evidence after commit. Infeasible or superseded work goes to Icebox with the reason and needed decision; delivered specification cards go to Review. Do not infer acceptance from writing a card.
Implementation epics after specification acceptance
The following is the concrete seed for later epics, not an instruction to start compiler/runtime work or create accepted implementation tickets now. Each implementation epic must link its accepted specification cards and use test-first behavior, bounded negative cases and mutation/evidence gates.
| Epic | Required behavior and acceptance | Dependencies |
|---|---|---|
| Parser/AST and static elaboration | accept bounded component/model declarations; reject unknown profiles, recursive instances and invalid bindings; preserve lossless source and old editions | 35–40, 43, 44 |
| ZLM3 binary tranches | allocate exact rows and feature gates; implement typed round trips, identity vectors and tamper rejection without changing ZLM1/2 | parser/AST; 44 |
| Reference hardware simulation | truth tables, driver resolution, simultaneous state, reset, CDC, async event law and deterministic bounded traces | parser/AST, binary; 37–39 |
| Synthesis IR and adapters | checked lowering, vendor-neutral protocol, independent functional equivalence, target report validation | reference simulation; 42, 44, 45 |
| FPGA deployment | select an explicit board/part, configure using live authority, verify readback policy, reconcile indeterminate actions, capture real receipts | adapters; 43, 45 |
| Async/intrinsic measurement | admit delay/hazard/fork assumptions; bind calibrated instruments, devices, placement/routes and held-out validity envelopes | deployment; 39, 42 |
| Physics IR and standard models | type dimensions/frames, validate mesh/equations/conditions, supply versioned EM/thermal/mechanical/fluid/semiconductor definitions | parser/AST, binary; 40, 41 |
| Solver execution and generation | execute typed plans, bound generation/resources, report error/convergence evidence and validate independent solvers | physics IR; 42, 43, 46 |
| Mixed-signal co-simulation | implement foundational bridges, event ordering, coupled convergence and irreversible hardware-in-the-loop behavior | simulation, solvers; 41, 46 |
| ZL512 fixtures and publication | create separate schema/catalog/executor/projections, seal inherited baseline, implement 128+128 task allocations and preserve ZL256 routes | relevant executors; 47, 48 |
| Canonical snapshots and ZDE | display ownership, lifecycle, active realizations, hardware/solver runs, uncertainty and failure with contract/UI tests | explicitly paired with each runtime epic; 48 |
Hardware simulation precedes target deployment; physical solving follows hardware-preview semantics but can develop independently of a particular FPGA vendor. Actual board selection and instrument access are explicit deployment prerequisites. No device measurement can be replaced by fixture-only evidence.