Clarify decision-graph runtime workflow for graph-backed memory retrieval/writes

[Copilot]

This update addresses reviewer uncertainty about whether Tower actively reads/writes the decision graph during normal operation. It documents the exact runtime workflow: initialization, graph materialization, memory regeneration, and provenance queries.

• What was clarified

  • tower-run initializes project state on every command (init_project, update_git_branch).
  • sync-memory writes graph data by importing sessions, appending events, and materializing nodes/edges/indexes.
  • Memory retrieval is graph-backed: L0/L1 regeneration reads graph indexes/nodes after each sync.
  • log-decision writes explicit decision/artifact/edge events, then re-syncs graph and refreshes L0/L1.
  • graph-status, graph-search, and explain all force a graph sync before reading/querying provenance.

• Workflow (shared in review comment)

  • Startup → bootstrap/init
  • Command path:
    • sync-memory → ingest sessions → sync graph → rebuild L0/L1
    • log-decision → append decision events → sync graph → rebuild L0/L1
    • graph-*/explain → sync graph → read/query graph state

• Illustrative snippet

flowchart TD
  A[tower-run <command>] --> B[init_project + update_git_branch]
  B --> C{command}
  C -->|sync-memory| D[import sessions + append events]
  D --> E[sync_decision_graph]
  E --> F[materialize nodes/edges/indexes + decisions.md]
  F --> G[refresh L1/L0 from graph]
  C -->|log-decision| H[append decision/artifact/edge events]
  H --> E
  C -->|graph-status / graph-search / explain| I[sync_decision_graph]
  I --> J[query graph state]

Loading

---

⚡ Quickly spin up Copilot coding agent tasks from anywhere on your macOS or Windows machine with Raycast.