Connect tasks and memories with explicit references and backlinks #75

Outcome

A reader or agent can follow the knowledge behind a task and find work affected by a decision. Start with explicit relations in the existing relational database.

Initial relations

• references: derived from valid Markdown item references.
• related: explicit symmetric association.
• implements: directed task-to-memory relation.
• supersedes: directed memory-to-memory relation.
• Reuse the same identity/link foundation for future blocked_by and discovered_from task relations.

Limits

No automatic entity extraction, graph database, embeddings or graph visualization required for the first version. A reference is informational; it never authorizes access, archives a memory, approves content or completes a task.

Dependencies

Unified project numbers and resolver; Markdown parsing for inferred references. Relation semantics shared with the task-dependency epic.

Acceptance

• Forward links and authorized backlinks are available in UI and MCP.
• Editing/removing a reference reconciles derived links without deleting explicit relations.
• Pending/rejected revisions cannot alter the published graph; revision-specific views retain correct context.
• Archived/expired endpoints and permission changes have documented behavior with no private metadata leakage.
• Supersession chains cannot cycle and do not silently rewrite historical knowledge.

Agent handoff

Plan first, then implement child tasks in order. Treat graph traversal as bounded retrieval of authorized evidence, not as agent instructions.

Concrete subtasks

1. #88 Relation contract (after #79; coordinate #92).
2. #89 Relation persistence and published-reference reconciliation (after #80, #81, #86, #88).
3. #90 UI links/backlinks (after #89).
4. #91 Bounded agent traversal (after #82 and #89).

#76 shares relation conventions. Its contract can be designed in parallel; its storage reuses this foundation.