Repository navigation
Milestone 4
Last reconciled: 2026-09-14T16:16:05.583Z. Team: RUNNING. Milestone.
As a naming-registry user, I want one installable command to manage names, rebuild the mirror from a node and drain pending requests. The deployment interface has landed and follower development is underway; the folder and naming command are in progress. A deployment-set deposit is refundable on Over to an address committed at registration. Its model-only ticket awaits the pending-claim lock-point ruling.
Stories describe outcomes; tickets are delivery containers. The mapping is many-to-many. Unticketed work, decisions and standing obligations are named explicitly. A landed enabler does not mean the product outcome is delivered.
Dependency-stage Gantt — not a calendar forecast. Each equal-width bar occupies one dependency stage; positions are calculated from the prerequisites below. Synthetic dates are rendering coordinates only. Widths are not effort, duration or completion percentages. Standing obligations are checkpoints. Same-stage rows may be independent, but this chart grants no dispatch authority.
Labels report delivery state; only in-progress rows use active colouring.
%%{init: {"gantt": {"leftPadding": 380, "sectionFontSize": 12, "fontSize": 12}}}%%
gantt
title Manage a naming registry from any machine - dependency stages
dateFormat YYYY-MM-DD
axisFormat Stage %j
tickInterval 1day
todayMarker off
section Manage names with one executable
naming-command Manage the registry through one command [in-progress] :active, naming-command, 2025-01-02, 1d
connected-cancellation Cancel a pending registration [in-progress] :active, connected-cancellation, 2025-01-01, 1d
registration-deposit Lock a deposit while a name is held [blocked] :crit, registration-deposit, 2025-01-01, 1d
section A writer on a second machine
deployment Attach to a persistent registry [landed] :done, deployment, 2025-01-01, 1d
follower Rebuild the trie from the node [in-progress] :active, follower, 2025-01-02, 1d
section A permissionless folder
folder Drain a queue in measured batches [in-progress] :active, folder, 2025-01-01, 1d
section Delivery and operation
journey Rebuild and drain from a fresh checkout [planned] :journey, 2025-01-03, 1d
maintenance Keep the product map and recovery record current [standing] :milestone, maintenance, 2025-01-01, 0d
State key: landed/delivered = evidence linked; review/ready = not landed; blocked/decision = unresolved prerequisite; planned = not commissioned; standing = continuing obligation.
| Story | Kind | Tracking | State | Owner |
|---|---|---|---|---|
| naming-command Manage the registry through one command | product | Ticketed — #114 | in-progress | Naming executable owner |
| connected-cancellation Cancel a pending registration | enabler | Ticketed — #117 | in-progress | Connected cancellation repair owner |
| registration-deposit Lock a deposit while a name is held | product | Unticketed work | blocked | Deposit model owner |
As a naming-registry user, I want an installable singular-naming executable exposing the existing naming operations individually, so that I can inspect and manage my chosen registry from the terminal.
Tracking: Ticketed. Dedicated installed management-command ticket. It consumes the merged deployment, representative, follower and folder interfaces; deposit implementation is a later separate ticket. #114.
Now — in-progress: the on-chain #106 and #110 are now accepted on main at f558d0e and b4a36ea. PR #115 is integrating the accepted spelling-derived representative API and registry-bound policy; local adapter checks continue. Preprod remains held for the separate on-chain handoff.
Acceptance: Install the released executable, select a deployment and invoke supported naming actions with user-chosen values through the same command exercised on devnet. Integrate follower and folder commands after their tickets land.
Dependencies: connected-cancellation: Cancel a pending registration
Next: Finish the accepted-API integration and current checks, then consume accepted follower/folder/cancellation interfaces; wait for the verified preprod handoff.
Evidence: Naming command draft PR
As a naming-registry user, I want to cancel the pending claim created by registration and receive its committed refund, so that I can withdraw before my registration is folded.
Tracking: Ticketed. Separate repair restores the connected cancellation already required by #114. Corrected artifacts proceed under the existing model; compatibility with the existing deployment remains unresolved. #117.
Now — in-progress: Accepted #110 spelling-derived representative and registry policy are integrated in the #117 lane; focused Aiken checks pass 11/11. Real Haskell/devnet cancellation remains unproven after earlier collateral and minUTxO failures; PR118 stays draft.
Acceptance: The production builder cancels a real pending registration on devnet, consumes its claim and approval and returns the committed refund, with corresponding refusal controls and successful fold preserved.
Dependencies: No prerequisite story recorded; this is not dispatch authority.
Next: Complete real connected register/approval/cancel devnet acceptance, then obtain the required independent audit before any merge or CLI integration.
Evidence: Cancellation repair draft PR
As a registry deployer, I want to set a registration deposit at deployment that becomes refundable on Over, so that holding names locks capital and makes squatting expensive.
Tracking: Unticketed work. Operator pricing choices are settled. A dedicated owner is filing the first model-only ticket; protocol and command integration follow in a separate implementation ticket.
Now — blocked: The deposit amount, Over release and committed refund address are settled. Model transitions are blocked on whether locking begins at successful registration or at request submission: a cancelled or losing pending claim never reaches Over. The owner has prepared its model-only proposal; no model behavior is changed yet.
Acceptance: The ruled deposit behavior is represented in Lean before implementation; real transaction checks enforce the configured deposit and its refund at Over, and the naming executable exposes the implemented deployment setting.
Dependencies: No prerequisite story recorded; this is not dispatch authority.
Next: Obtain the lock-point ruling, then file and run the first model-only ticket in parallel. Protocol implementation remains a later separate ticket.
Evidence: No completion evidence claimed.
| Story | Kind | Tracking | State | Owner |
|---|---|---|---|---|
| deployment Attach to a persistent registry | enabler | Ticketed — Persistent deployment PR #106 | landed | On-chain milestone owner |
| follower Rebuild the trie from the node | product | Ticketed — #107 | in-progress | Registry follower ticket owner |
As a registry writer, I want a deployment manifest that identifies the existing registry, so that I can attach to the same on-chain state.
Tracking: Ticketed. External prerequisite owned by the on-chain milestone; not an additional ticket in this milestone. Persistent deployment PR #106.
Now — landed: The persistent deployment interface merged to main at f558d0e8fc916eef494fffcef09cfe2ac5582b8e. The live preprod writing window still awaits the separate on-chain milestone handoff.
Acceptance: The persistent deployment PR is merged to main and exposes the manifest and mirror contract.
Dependencies: No prerequisite story recorded; this is not dispatch authority.
Next: Use the merged interface for follower development; await the actual preprod handoff before shared-registry writes.
Evidence: Merged deployment PR, Deployment merge
As a writer on a second machine, I want to rebuild the trie with the manifest and node socket, so that I can fold without obtaining another machine's mirror.
Tracking: Ticketed. Includes deployment follow, root equality refusal, attach --rebuild and incremental replay from the last point. #107.
Now — in-progress: PR #116 candidate 112d20c now has 26 successful remote checks, 2 skipped and complete local evidence, including replay mutation controls. It is audit-ready but remains draft/unaccepted because the replay/checkpoint seam and cross-ticket outcome require independent gate/test audit.
Acceptance: A fresh checkout with only the manifest rebuilds from a preprod node and folds successfully; the devnet deletion-and-rebuild test runs in CI; onboarding uses follow.
Dependencies: deployment: Attach to a persistent registry
Next: Commission and complete the fresh independent audit, then resolve its findings before merge; preprod still awaits the verified on-chain handoff.
Evidence: Follower draft PR
| Story | Kind | Tracking | State | Owner |
|---|---|---|---|---|
| folder Drain a queue in measured batches | product | Ticketed — #104 | in-progress | Folder loop ticket owner |
As a permissionless folder, I want to drain pending requests using batches sized by node evaluation, so that I need neither a fixed batch limit nor manual retries.
Tracking: Ticketed. Includes deterministic ordering, halving on size or execution-unit refusal, confirmation, fresh proofs, poisoned-request reporting and batch narration; supersedes the closed batch-limit story in #71. #104.
Now — in-progress: Adaptive folding, connected registration and attached-mirror devnet runs pass. Retirement CI exposed an error-rendering regression that hides refusal attribution. The desk has authorized one localized compatibility repair, retaining the strict retirement checks.
Acceptance: The CI devnet test drains varied-size requests in multiple batches, ends at the mirror root and reports/skips one poisoned request; the runbook explains the folder and preprod uses fold-all.
Dependencies: No prerequisite story recorded; this is not dispatch authority.
Next: Repair error rendering and run the retirement and adaptive controls plus current-head CI; preprod still awaits the complete deployment handoff and writer assignment.
Evidence: Folder loop draft PR
| Story | Kind | Tracking | State | Owner |
|---|---|---|---|---|
| journey Rebuild and drain from a fresh checkout | outcome | Ticketed — #107, #104 | planned | Off-chain milestone owner |
| maintenance Keep the product map and recovery record current | operation | Standing obligation | standing | Off-chain milestone owner |
As a new registry writer, I want to rebuild from a manifest and drain a queue larger than one transaction, so that I can operate the registry from any machine.
Tracking: Ticketed. Combined milestone outcome; neither ticket alone establishes this complete journey. #107, #104.
Now — planned: The integrated preprod outcome has not been executed. Transfer to this milestone is authorized once the on-chain milestone supplies a verified deployment handoff and releases the shared registry; no further approval is needed. The two tools will use it sequentially.
Acceptance: A fresh checkout with only the deployment manifest rebuilds the mirror from a preprod node and drains a queue of requests that cannot fit one transaction.
Dependencies: follower: Rebuild the trie from the node; folder: Drain a queue in measured batches
Next: After both tools land, verify this connected journey and link the released runnable artifact.
Evidence: No completion evidence claimed.
As an operator, I want current evidence and recoverable ownership, so that I can see delivery gaps and resume interrupted work.
Tracking: Standing obligation. Milestone owner obligation; no implementation ticket is needed.
Now — standing: The desk maintains this story register and a separate recovery ledger.
Acceptance: Every landing and desk sweep reconciles ticket evidence, contracts and dependencies and publishes the generated page.
Dependencies: No prerequisite story recorded; this is not dispatch authority.
Next: Update both records when product state changes.
Evidence: No completion evidence claimed.
This page and its Gantt are generated from the adjacent story register. The milestone owner must reconcile it on material state changes and before handoff. Updating the timestamp alone is not reconciliation. A normal debrief reads this page; an authorised state sweep updates and publishes it. If publication is blocked, the desk must name the stale publication and pending changes.
Register schema: milestone-stories/v1. Parsed-register SHA-256: 58c8ae3f74311862d78da6ffc001b7ce9fa1c7c8a6190c22db866de2aad1f0df.