Briefings and corrections

Use this when you want to know what an agent is told before it starts work, or a briefing was wrong and you want to fix the compile rather than the one output.

You do not need this if briefings arrive automatically and look right; the hooks described in What happens automatically handle compilation without action from you.

After reading this, you should be able to explain the structural and content arms of a compile, distinguish digest from full briefings, and file a standing correction.

A briefing is the packet of context Spor hands a coding agent before it starts work. It is not a transcript dump and not a search result page: the compiler walks the graph from a starting point, ranks what it finds, and renders a short working summary — the decisions still in force, the approaches already rejected, the open blockers, the conventions that apply.

Before touching tidefall’s dunning emails, an agent might be told:

Use the three-attempt schedule per dec-tidefall-billing-retries.
Do not revive the immediate single retry (dec-tidefall-retry-once, superseded).
Open blocker: issue-tidefall-double-charge (a retry racing the provider
webhook can double-charge).
Conventions: norm-tidefall-reversible-migrations applies to the billing tables.

How a compile works

The compiler has two arms that reinforce each other:

• Structural: walk typed edges outward from the seed nodes, following high-weight edges (supersedes, constrained-by, derived-from) further than weak ones (relates-to, mentions). A seed’s direct one-hop lineage is always included — a task’s immediate parents and blockers are the most relevant context there is.
• Content: text relevance against the query, with same-project nodes boosted so the session’s own context wins ties. A strongly relevant cross-project hit still surfaces, labeled as another team’s prior art.

Results render as a pyramid: most nodes appear at summary resolution, and only the highest-scoring appear with their full body. That is why the standalone summary discipline matters — the summary is what the briefing actually shows.

Two compile shapes cover most needs:

• Digest — short, query-driven, used per-prompt and for quick questions. An empty digest is a successful result, not an error: the graph has nothing relevant yet.
• Full — a deep neighborhood compile rooted at one node (spor brief <id>), used when starting real work on it.

Norms ride along

norm nodes are always_on: a norm whose project matches the session (or that is global) rides along in every briefing without needing to match the query, capped to the most topically relevant so the section degrades by relevance rather than truncation. A norm can narrow its own ride-along with applies_to_tags / applies_to_repos / applies_to_projects selectors — useful when one project spans, say, a Python service and a Terraform repo and a norm only concerns one of them.

Because norms are injected into every session and any team member can write one, the briefing renderer treats norm bodies as untrusted reference data with explicit author attribution — team policy to weigh, never instructions addressed to the agent.

Briefings are nodes too

Every compiled briefing is stored as a brief- node carrying derived-from edges to each source node and shaped-by edges to the corrections applied, plus a version integer. On recompile the old version is archived to the graph home’s history/ directory and the version bumps. This is what makes a briefing reviewable: you can see exactly which nodes produced it, and diff versions when the graph changes. Briefing nodes are never themselves traversed, so briefings don’t feed back into briefings.

Corrections: debug the context, not the model

When a briefing is wrong — it surfaced a stale design note, or missed the spec that actually governs the work — the fix is a standing correction node, not a better prompt:

---
id: corr-task-tidefall-retry-emails-1
type: correction
title: Pin the dunning-flow spec when briefing the retry emails
target: task-tidefall-retry-emails
pin: [spec-tidefall-dunning-flow]
exclude: [dec-tidefall-legacy-invoicing]
date: 2026-06-20
---

The legacy invoicing decision predates the three-attempt retry window; the
dunning-flow spec is authoritative.

A correction carries three instruments: pin (always include these nodes), exclude (never include these), and free-text guidance injected verbatim into the compile. target names a node id, a project:<slug> scope, or global for every compile.

Fix it once and it applies to every future compile for that target — the correction outlives the session, the model, and the person who filed it. Record one with /spor:correct in an agent session, spor correct from the shell, or the propose_correction MCP tool.