captain-injectlisted

# Captain inject The user asserted knowledge. Validate it, connect it, persist it. **Destination is ALWAYS the tsubasa graph (`tsubasa event add`), never your private memory directory.** The graph is the captain's shared, versioned memory — it travels with the repo, feeds hot/warm tiers, and is queryable by every session and teammate. Private memory hides knowledge on one machine. ## Steps 1. Classify: event type (note/incident/decision/config_change), entities involved, impact, domains. Run `tsubasa query "<topic>"` to find the existing entities and check for conflicts. 2. **Validation gate** — restate what you understood in one line: `Recording as <type>, domain=<d>, impact=<i>, links to <entities>[, supersedes <old>]. Correct?` - If it contradicts existing knowledge, ask the one WHY question before writing (the answer is the most valuable part of the event). 3. On confirmation, append: `tsubasa event add --type <t> --title "..." --impact <i> --domains <d> \ [--supersedes <entity-id>] [--entity id:type:name:desc]... \ [--relation src:pred:tgt]... [--ref kind:id]... --body "<the why>"` 4. Check output for reconciliation notes; if `tsubasa questions` has new open questions relevant to this, raise them now (once, briefly) — otherwise stay silent. ## A directory of knowledge, not a single fact If the user points at a PLACE where knowledge lives ("our postmortems are in docs/incidents", "we keep engineering principles in docs/principle