Repository navigation
v0.11.0
MOOSEDev v0.11.0
v0.11.0 makes knowledge supersession more explicit and reviewable, while simplifying the Story page's asynchronous operation ownership.
Highlights
Explicit relation-aware supersession
supersede_decision can now reassert selected semantic relations on the replacement in the same atomic operation. Relations are never inherited automatically: the caller chooses every carried link, and the result reports semantic links from the superseded record that were not carried forward.
Ontology-declared inverse links are resolved and materialized with the selected relation, so replacements remain reachable from both sides of the graph without requiring separate relate calls. Lifecycle, provenance, and rationale relations are excluded from the omission report.
Ratification for high-stakes replacements
Constraint and AntiPattern replacements now default to proposed. Until a human accepts the proposal, the previous record remains authoritative and the replacement stays outside the current working set.
Pending supersessions include the old and new claims, a bounded structured diff, and an optional reason: later-decision, record-was-inaccurate, code-diverged, or scope-narrowed. Accepting a proposal atomically activates the replacement and retires the old record; rejecting it leaves the old record authoritative.
Default MCP recall and natural-language query paths exclude proposed and rejected records together with every semantic or inferred inverse edge incident to them. Superseded and deprecated records remain available to query for questions about project evolution, while sparql and get_relevant_context(include_history=true) retain explicit access to the complete audit history.
Rejecting a record proposal also rejects its rationale and pending link proposals in the same lifecycle transaction, so no orphaned inbox item can later resurrect a declined replacement.
ArchitecturalDecision, Lesson, Pattern, and Requirement replacements retain immediate acceptance by default. Rust callers may explicitly override replacement status where the API permits it.
Story operation ownership
Story generation and editor operations now share an internal useStoryGeneration hook. The refactor centralizes cancellation tokens, stale-operation ownership, duplicate-action guards, busy and assisting state, saves, publication, and reload behavior while preserving the existing Story UI and HTTP surface.
Deep-link navigation continues to disown stale work immediately, and late responses cannot overwrite a newly selected Story or leave controls permanently disabled.
Compatibility
No MCP tools or HTTP routes were removed.
The MCP supersede_decision input gained optional relations and reason fields. Existing calls remain valid. The legacy Rust supersede_decision API keeps its transaction-only behavior and does not trigger whole-graph semantic enrichment; relation omission reporting is opt-in through the relation-aware API.
The principal behavior change is intentional: superseding a Constraint or AntiPattern without an explicit status now creates a pending proposal instead of an immediately authoritative replacement. Other record classes keep the v0.10 behavior.
Story recipe formats and public Story endpoints are unchanged; the hook extraction is internal to the web client.
Upgrading
No manual data migration is required. The committed knowledge graph remains authoritative, and pending supersessions appear in the existing ratification inbox.
Agents that supersede records should inspect the reported links that were not carried and pass the desired subset through relations. Clients should also handle the proposed result for Constraint and AntiPattern replacements and direct a human to the inbox for acceptance or rejection.
When code diverges from an accepted Constraint or AntiPattern, do not assume that the running code supersedes the record. Unless a recorded decision supports the divergence, treat the record as authoritative and the code as the defect to investigate.
What's Changed
Full Changelog: v0.10.0...v0.11.0
