-
Notifications
You must be signed in to change notification settings - Fork 2
Milestones
List view
Doc 09 steps 5-6 (PR #132). The Swarm postage-purchase adapter as N=2 (exercising the requires-signing adapter path), the nexum:value-flow 1.0 freeze gate, the curated adapter registry with the ENS escape hatch, and the consent UX schema.
No due date•0/2 issues closedDoc 09 step 4 (PR #132). The simulate host primitive with pluggable backend, fact assembly over nexum:value-flow, the analyzer component kind, the policy engine with authorisation classes and fail-open/closed profiles, the identity-boundary checkpoint. Sequenced after the intent core; depends on a real identity backend (#52) and the embeddable builder surface (M0).
No due date•0/2 issues closedDoc 09 steps 2-3 (PR #132). The venue-generic strategy chassis, the one-SDK plan (nexum-sdk, macros, clean break of shepherd-sdk), the nexum:value-flow and nexum:intent WIT packages, the venue-adapter world, the pool router, nexum-venue-sdk plus conformance kit, the echo-venue example pair, the CoW venue adapter, and both flagship modules migrated once (chassis + pool + nexum-sdk together). Sequenced BEFORE the grant-evidence train by owner decision: grant evidence runs on this shape. Compatibility fallback: the legacy cow path (shepherd:cow, cow_orderbook extension) is not deleted until the adapter path passes evidence; if this milestone slips past roughly July 20, evidence collection falls back to the legacy path.
No due date•1/29 issues closedFoundational refactor that turns the runtime into a library-first, composable system: a RuntimeTypes associated-type lattice, a component seam with real and mock presets, a type-state RuntimeBuilder split from an imperative LaunchRuntime, a RuntimeAddOns extension layer, and a thin CLI over the same builder any embedder uses. Precedes and underpins M1-M5; it is not a version gate of its own. Acceptance: a third-party Rust program embeds and launches a runtime with a custom component set entirely through the public builder, with no CLI dependency, and the CLI binary is one consumer of that same builder. Extended 2026-07: M0 concludes with engine de-cow-ification (doc 09 step 1, PR #132): the extension seam replaces the mandatory Cow lattice slot, the cow backend moves out of nexum-runtime into a composition-root extension, and nexum-runtime becomes domain-free. See the de-cow epic.
No due date•57/69 issues closedNon-wire, non-blocker hardening, debt, and design follow-ups deferred past the first stable runtime. Not a gate for any earlier artefact. Includes observability sweeps, test-harness debt, dependency hygiene, performance tuning, and accumulated design follow-ups. Absorbs work that surfaces during M1 through M5 but should not block them. Acceptance: none; this is a rolling bucket triaged by priority.
No due date•3/21 issues closedThe module-authoring on-ramp. shepherd-sdk and the underlying nexum-sdk (alloy Provider over the host transport, typed Signer/Messaging/RemoteStore, TypedState<T>, log macros, the module proc macro, a MockHost for native tests), the minimal cargo tooling (new, check, run --mock), typed config-value, the example modules (balance-tracker, stop-loss, price-alert), and the backtest tooling (shepherd-backtest, backtest-collect, baseline-latency). Acceptance: a new author goes from zero to a running custom module in under 30 minutes using the scaffold plus a mock run. Revised 2026-07: the chassis, macros, nexum-sdk split, and shepherd-sdk clean break moved to M1 (intent core) so modules migrate once. M5 keeps the grant-scoped DX deliverables: documentation, examples, backtest tooling.
Due by July 17, 2026•2/6 issues closedOperator-facing distribution and the repository delivery machinery. CI/CD pipelines (build, lint, test, wasm-target, release) hardened and green; the runtime-level nexum-engine.toml multi-chain provider map with per-endpoint tower middleware; component-hash verification and the content-address fetch flow (bzz/ipfs/oci/https to local store to verify to cache); the operator CLI (run, module list/load/unload, state inspect, health); a Dockerfile plus a published GHCR image; and the release pipeline with versioning and changelog. Acceptance: an operator brings up a multi-chain engine from a published container image and config file, and a content-addressed module loads only after its sha256 verifies.
No due date•2/6 issues closedThe concrete production modules that prove the abstraction holds, shipped on the unmodified engine binary. modules/twap-monitor watches CoW Protocol ComposableCoW TWAP orders; modules/ethflow-watcher monitors CoW EthFlow order flow; both consume only declared capabilities with zero engine special-casing. Two modules with different capability combinations running on one engine binary is the falsifiable proof that generic and programmable is real, not aspirational. If shipping a module requires an engine change, that change is a runtime capability, not a module feature. Acceptance: the TWAP and EthFlow modules both run end to end against a forked-mainnet or testnet on the same unmodified engine binary, each exercising chain reads, persisted state, a subscription, and an outbound action.
No due date•0/8 issues closed