# Glossary Source: https://flow-next.dev/reference/glossary/ The canonical Flow-Next vocabulary - specs, tasks, R-IDs, handover objects, receipts, Ralph, pilot, land, tracker projection, and the rest of the terms the docs lean on. The canonical vocabulary for these docs. Terms are load-bearing: skills, docs, and reviews use them in exactly these senses. Two related things share the name. The repo-root [`GLOSSARY.md`](https://github.com/gmickel/flow-next/blob/main/GLOSSARY.md) is deliberately much shorter - a twelve-term dictionary of the words whose synonyms cause real ambiguity for contributors and agents working on flow-next itself, each with the aliases to avoid. The `GLOSSARY.md` that `/flow-next:setup` seeds into *your* project (and that survives uninstall) is your project’s vocabulary, unaffected by either. This page is the full reference list for reading the docs. ## Jump to a term [Ask stage / question valve](https://flow-next.dev/reference/glossary/#ask-stage--question-valve) · [Backlog mode (`pilot.autonomy`)](https://flow-next.dev/reference/glossary/#backlog-mode-pilotautonomy) · [Briefing package](https://flow-next.dev/reference/glossary/#briefing-package) · [Carmack-level review](https://flow-next.dev/reference/glossary/#carmack-level-review) · [Chart](https://flow-next.dev/reference/glossary/#chart) · [Classification (prime)](https://flow-next.dev/reference/glossary/#classification-prime) · [completed-blocker rule](https://flow-next.dev/reference/glossary/#completed-blocker-rule) · [Cross-model review](https://flow-next.dev/reference/glossary/#cross-model-review) · [D-ID](https://flow-next.dev/reference/glossary/#d-id) · [Decision log (`pilot-log`)](https://flow-next.dev/reference/glossary/#decision-log-pilot-log) · [Decision record](https://flow-next.dev/reference/glossary/#decision-record) · [Delivery shape](https://flow-next.dev/reference/glossary/#delivery-shape) · [dependency projection](https://flow-next.dev/reference/glossary/#dependency-projection) · [discovery ceremony](https://flow-next.dev/reference/glossary/#discovery-ceremony) · [Doctor](https://flow-next.dev/reference/glossary/#doctor) · [Fast scout tier](https://flow-next.dev/reference/glossary/#fast-scout-tier) · [Feature map (code index)](https://flow-next.dev/reference/glossary/#feature-map-code-index) · [Feature map (user-POV drive map)](https://flow-next.dev/reference/glossary/#feature-map-user-pov-drive-map) · [features\_anchored](https://flow-next.dev/reference/glossary/#features_anchored) · [Frontier (chart)](https://flow-next.dev/reference/glossary/#frontier-chart) · [Frozen-at-handover](https://flow-next.dev/reference/glossary/#frozen-at-handover) · [Global criterion (G-ID)](https://flow-next.dev/reference/glossary/#global-criterion-g-id) · [Green receipt](https://flow-next.dev/reference/glossary/#green-receipt) · [Handover object](https://flow-next.dev/reference/glossary/#handover-object) · [Hard gate](https://flow-next.dev/reference/glossary/#hard-gate) · [HTML artifact mode](https://flow-next.dev/reference/glossary/#html-artifact-mode) · [Implementer tier](https://flow-next.dev/reference/glossary/#implementer-tier) · [Land](https://flow-next.dev/reference/glossary/#land) · [No-plan route](https://flow-next.dev/reference/glossary/#no-plan-route) · [Lavish (lavish-axi)](https://flow-next.dev/reference/glossary/#lavish-lavish-axi) · [merge-base snapshot](https://flow-next.dev/reference/glossary/#merge-base-snapshot) · [Operability ladder](https://flow-next.dev/reference/glossary/#operability-ladder) · [Pilot](https://flow-next.dev/reference/glossary/#pilot) · [PR artifact](https://flow-next.dev/reference/glossary/#pr-artifact) · [PR-as-cognitive-aid](https://flow-next.dev/reference/glossary/#pr-as-cognitive-aid) · [provenance ledger](https://flow-next.dev/reference/glossary/#provenance-ledger) · [QA stage (`pipeline.qa`)](https://flow-next.dev/reference/glossary/#qa-stage-pipelineqa) · [R-ID](https://flow-next.dev/reference/glossary/#r-id) · [Ralph](https://flow-next.dev/reference/glossary/#ralph) · [Re-anchoring](https://flow-next.dev/reference/glossary/#re-anchoring) · [Reach](https://flow-next.dev/reference/glossary/#reach) · [Ready](https://flow-next.dev/reference/glossary/#ready) · [Receipt](https://flow-next.dev/reference/glossary/#receipt) · [render lens](https://flow-next.dev/reference/glossary/#render-lens) · [Reviewer tier](https://flow-next.dev/reference/glossary/#reviewer-tier) · [Spec](https://flow-next.dev/reference/glossary/#spec) · [spec artifact](https://flow-next.dev/reference/glossary/#spec-artifact) · [Spec-as-PR](https://flow-next.dev/reference/glossary/#spec-as-pr) · [Supersession](https://flow-next.dev/reference/glossary/#supersession) · [Task](https://flow-next.dev/reference/glossary/#task) · [Thinking scout tier](https://flow-next.dev/reference/glossary/#thinking-scout-tier) · [Tier](https://flow-next.dev/reference/glossary/#tier) · [Tracker](https://flow-next.dev/reference/glossary/#tracker) · [tracker result class](https://flow-next.dev/reference/glossary/#tracker-result-class) · [tracker-key handle](https://flow-next.dev/reference/glossary/#tracker-key-handle) · [Triage skip](https://flow-next.dev/reference/glossary/#triage-skip) · [Triage stage (backlog mode)](https://flow-next.dev/reference/glossary/#triage-stage-backlog-mode) · [Verdict](https://flow-next.dev/reference/glossary/#verdict) · [Worker subagent](https://flow-next.dev/reference/glossary/#worker-subagent) ## Chart Optional decision-map discovery for **one** oversized or unclear idea before capture ([`/flow-next:chart`](https://flow-next.dev/skills/chart/)). Lives at `.flow/charts/.md` + `.json`. Unit of work is a [decision record](https://flow-next.dev/reference/glossary/#decision-record) (D-ID), not a build task. Output is a [briefing package](https://flow-next.dev/reference/glossary/#briefing-package) handed to capture - never a spec and never a `ready` flag. Not a pilot/build-loop stage; skip when intent and boundaries are already stateable. See [Guide](https://flow-next.dev/skills/guide/) for when it is the smallest sufficient route. *Relates to*: Decision record, D-ID, Frontier, Briefing package, Supersession ## Decision record A single chart decision - question body under `.flow/charts//.md` plus a JSON sidecar. Carries type (`research|probe|eval|prototype|interview|task`), attendance (`attended|unattended`), status (`open|resolved|superseded|out-of-scope`), edges (`blocked_by`, `depends_on`), assets, and answer on close. Sized for one agent session (\~100k tokens), same budget as a task. Attended types never self-resolve under unattended drivers (`NEEDS_HUMAN`). *Relates to*: Chart, D-ID ## D-ID Chart-local decision identity, format `.D` (e.g. `fn-140.D3`). Allocated sequentially from D1, append-only, never renumbered or reused - the same discipline as R-IDs. Load-bearing across the ledger, dependent records, briefing membership, and eventual spec citations. Human lists always pair title + D-ID + record link. *Relates to*: Decision record, R-ID ## Frontier (chart) Open, unblocked, unclaimed decisions on a chart - the same word and shape `/flow-next:work` uses for the ready task frontier. `flowctl chart frontier` is the sole selection input for chart work mode. Empty frontier is not completion by itself; briefable requires no open decisions and no parked Open Questions. *Relates to*: Chart, Decision record ## Briefing package Immutable versioned handoff from a briefable chart to capture (B-IDs: B1, B2, …). Clusters resolved decisions (default N=1; split only when genuinely disjoint), names multi-cluster decisions once as shared context, and preserves D-ID/evidence links and supersession history. Chart never writes `.flow/specs/`; capture authors the spec and owns criterion source tags. *Relates to*: Chart, Capture ## Supersession When a later decision invalidates an earlier answer: prior answer stays immutable; ledger line is struck-through, never deleted; dependents cascade (open premise-dependents lose claims; resolved dependents get replacement D-IDs unless `--keep-dependents`). Wrong turns remain visible in the briefing. *Relates to*: Chart, Decision record ## Spec The central artefact of flow-next: a specification at `.flow/specs/.md` (markdown body) plus `.flow/specs/.json` (metadata sidecar, post-1.0). Reviewable on its own; cross-model-reviewed; verifiable against prior handovers; frozen at handover. Replaces the term *epic* from the 0.x line. ## Ready A human-owned boolean on the spec record (default `false`, toggled via `flowctl spec ready` / `spec unready`) marking a spec complete enough to hand to an agent - the entry gate autonomous loops consume. Orthogonal to `status` (`open|done`): a ready spec stays `open` through planning and work. Human-owned or tracker-projected (`tracker.readyState` pulls the configured tracker state onto the local flag, one-way), never agent-inferred. Opt-in and invisible until adopted: the flag is written lazily, non-adopters see no badge, prompts, or warnings anywhere. Its sibling boolean is `no_plan` (see [No-plan route](https://flow-next.dev/reference/glossary/#no-plan-route)) — same lazy, human-owned contract, marking a ready zero-task spec as too small to plan. ## No-plan route The work-level pipeline variation that starts `/flow-next:work` directly from a zero-task spec: an explicit fork mints one minimal implicit task (“implement this spec”) instead of running plan and plan-review. Interactive by default (`--no-plan` or stated intent pre-answers the fork). The durable form is the spec-carried `no_plan` field — the second human-owned boolean beside [`ready`](https://flow-next.dev/reference/glossary/#ready), set at capture time (`/flow-next:capture … --no-plan`) or via `flowctl spec set-no-plan` (refused once tasks exist; `clear-no-plan` undoes it) — which pilot classifies and work honors as the same explicit instruction; autonomous loops keep planning unless a human passed the flag or set the field. Every other contract - receipts, review, done evidence - holds unchanged. ## Task An execution unit under a spec, sized to fit one `/flow-next:work` iteration (\~100k tokens fresh context). Tasks declare dependencies (`requires:`) and may declare which spec acceptance criteria they advance (`satisfies: [R1, R3]`). Implemented by a worker subagent with re-anchored context. ## R-ID A numbered acceptance criterion in a spec, format `**R1:** ...`, `**R2:** ...`. Renumber-forbidden after the first review cycle: deletions leave gaps, new criteria take the next unused number. R-IDs are the load-bearing identity of a requirement across the spec, the tasks that satisfy it, the commits that reference it, and the PR body coverage table. ## Global criterion (G-ID) A numbered standing, project-wide acceptance criterion in the user-owned `.flow/criteria.md`, format `- **G1:** ...` - the R-ID grammar with a `G` prefix, lifted from one spec to the whole project. Parsed and validated by `flowctl criteria list` (unique ids, non-empty prose, gaps allowed); judged agentically by the existing spec completion review, which records per-criterion compliance (`met` / `violated` / `n/a`) in the ordinary review receipt’s additive `criteria: [{id, status, note?}]` array. No separate auditor, no rule engine. The spec is the unit of compliance; G-IDs are stable identity like R-IDs and are never renumbered. Absence of the file is a silent no-op everywhere: criteria-less repos pay zero prompt content. Like structured findings, the compliance record is a portable receipt contract that downstream consumers can render without importing Flow-Next internals. See [Standing Criteria](https://flow-next.dev/reference/standing-criteria/). *Relates to*: R-ID, Receipt ## Handover object A named, reviewable artefact that carries context across a step in the agentic SDLC. flow-next defines six handover states: the spec at business-layer completion (#1) and at full completion (#2) - both the **same** `.flow/specs/.md` file at successive layers, NOT two separate specs - then the implementation plan (#3), the working implementation (#4), the cross-model code review (#5), and the PR-as-cognitive-aid (#6). Each is reviewable on its own, cross-model-verified, and frozen at handover. The chain of handovers replaces the standups / refinement / design-review touchpoints that pre-agentic Agile relied on. ## Re-anchoring Re-reading the spec, the task, and `git log` since branch base before each task starts. Counters context drift in long-running agent sessions per Anthropic guidance. Worker subagents re-anchor on every iteration via a single `flowctl anchor ` call - one deterministic bundle carrying, verbatim, the same information the discrete reads delivered (task + spec records and bodies, git state, memory/glossary indices, dependency done-summaries); the bundle is a floor, not a ceiling. `/flow-next:work` re-anchors every loop turn. Session scope has its own verb: a cold session (new chat, pilot tick, benchmark checkpoint) runs `flowctl brief` first - one deterministic, \~2k-token-bounded workspace picture (open specs, actionable tasks with claim state, recent completions, memory index) with explicit truncation markers and `--full`/`--json` forms; unlike anchor it is budgeted, not verbatim. ## Tier What kind of model a job wants: `reviewer`, `implementer`, `fast scout`, `thinking scout`, or unset (the session model). A tier binds a model to a stage’s *execution*, never to which stages run - which stages run is decided by what you invoked. The four names are a user-facing interface defined in exactly one place, [Orchestration → Tiers](https://flow-next.dev/guides/model-routing/#tiers-what-kind-of-model-a-job-wants); an unrecognized name is treated as unset with one advisory. Written as `: ` lines (optionally `at `) in your own `CLAUDE.md` / `AGENTS.md` [routing block](https://flow-next.dev/guides/model-routing/#the-routing-block). *Avoid*: pin, model tier, capability level, role map *Relates to*: Reach, Cross-model review ## Reach How the active harness obtains a model for a tier: the in-session model, an in-host subagent, shelling out to another CLI, or not available. Documented [once per harness](https://flow-next.dev/guides/model-routing/#reach-how-each-harness-gets-a-model) and never inside a skill - a skill asks for a tier and names no spawn primitive, CLI flag, or vendor path. An undetectable harness takes the generic row and says so. Every missing mechanism degrades to the session model, stated once; nothing fails closed on routing. *Avoid*: dispatch mechanism, availability, probe *Relates to*: Tier ## Reviewer tier The tier for anything grading work someone else produced. The only tier carrying a family rule: a reviewer from the writer’s own family is not an independent verdict. The rule is advice, not enforcement - the receipt records what ran, and nothing fails closed on it. *Avoid*: grader, review model, critic *Relates to*: Tier, Cross-model review ## Implementer tier The tier for work handed to another harness - plan on the session model, implement somewhere cheaper or faster. Absent, the session model implements. Replaced the packaged `delegate:codex` mode in 4.0.0: there is no layer to enable, only a line to write and a bridge recipe to run. *Avoid*: bridged worker, executor, delegate *Relates to*: Tier, Task ## Fast scout tier The tier for mechanical inventory scanning, where the cheapest model is the correct one. *Avoid*: cheap tier, scanner model, fast model, low tier *Relates to*: Tier ## Thinking scout tier The tier for analysis that degrades badly on a fast model - requirement analysis and pattern judgment, not scans. *Avoid*: judgment tier, smart scout, intelligent scout, deep scout *Relates to*: Tier ## Cross-model review A different model reviews the artefact produced by the first model. Applied at every handover. Backends: RepoPrompt (rp), Codex CLI (codex), GitHub Copilot CLI (copilot), Cursor `cursor-agent` CLI (cursor), Claude Code CLI (claude), host-native fresh-context subagent (`host`). The disagreement surface between writing model and reviewing model is where the gaps live. ## Feature map (code index) The `.clawpatch/features/*.json` index produced by `clawpatch map` and consumed by flow-next scouts via `flowctl repo-map`. Semantic feature slices across \~20 languages/frameworks (Zod-validated upstream, `schemaVersion: 1`). Wrapped by the opt-in [`/flow-next:map`](https://flow-next.dev/skills/map/) skill; flow-next core (flowctl) never imports or requires clawpatch - when `.clawpatch/` is absent, scouts gracefully fall back to grep/glob. Local-per-developer and git-ignored by default. *Relates to*: [Feature map (user-POV drive map)](https://flow-next.dev/reference/glossary/#feature-map-user-pov-drive-map), features\_anchored ## Feature map (user-POV drive map) The committed directory at `.flow/features/` recording, from the user’s point of view, what each user-facing feature is, how a user reaches it, how an agent drives it, and which traps waste a verification run. An index carrying the operating rules plus one file per feature, each with a `**Surface:**` identifier and exactly four sections (Sub-features / How to get to it (user POV) / Driving it / Gotchas). Seeded and maintained by [`/flow-next:features`](https://flow-next.dev/skills/features/); read by [`/flow-next:qa`](https://flow-next.dev/skills/qa/) and [Drive](https://flow-next.dev/skills/flow-next-drive/) on an existence check, for navigation only. The spec still supplies what to prove, and live captured evidence is still the only ship basis. Committed, unlike the code index above. *Relates to*: [Feature map (code index)](https://flow-next.dev/reference/glossary/#feature-map-code-index), [Doctor](https://flow-next.dev/reference/glossary/#doctor), QA stage ## Doctor The one read-only check `/flow-next:features` runs to answer “is this instance worth driving”: right build/version, port owned by this run, auth valid. It observes and never mutates. All three must pass before a drive, and it re-runs on each fresh session and after any failed drive. Two ownership rules ride with it - never drive an instance this run did not start, and never kill by process name. *Relates to*: [Feature map (user-POV drive map)](https://flow-next.dev/reference/glossary/#feature-map-user-pov-drive-map) ## features\_anchored Optional scout output field listing feature slices from the [feature map code index](https://flow-next.dev/reference/glossary/#feature-map-code-index) that overlap the current scope. Emitted by `repo-scout` when `.clawpatch/features/*.json` is present; omitted when absent. Each entry carries a `last_mapped` timestamp so downstream skills can flag staleness (informational signal, not a block). ## Receipt A review-layer JSON artefact that gates Ralph state transitions. `flowctl impl-review` writes a receipt at `.flow/review-receipts/.json` with verdict (`SHIP` / `NEEDS_WORK` / `MAJOR_RETHINK` / `NEEDS_HUMAN`), confidence anchors, introduced vs pre-existing finding counts, and deferred / suppressed counts. `NEEDS_HUMAN` records a reviewer request for human adjudication; its receipt and status persist before the workflow exits with `ESCALATE:`. Ralph reads review receipts to decide loop progression. A Green receipt is the gate-layer counterpart, not a review-layer receipt. *Relates to:* [Green receipt](https://flow-next.dev/reference/glossary/#green-receipt) ## Green receipt The gate-layer artifact: a per-file JSON record at `.flow/tmp/green-receipts/-.json` proving one exact command passed at one exact commit. Honored only when hash, path, and age match; otherwise the full gate runs. A reuse always leaves a loud `GATE_SKIPPED` line. Format: [Receipts](https://flow-next.dev/reference/receipts/#green-receipts). ## Worker subagent A subagent dispatched by `/flow-next:work` to implement a single task with fresh context. Re-anchors on the spec + task + git state (one `flowctl anchor` bundle - same information as the old discrete reads, one call), implements the task, records evidence (commits + tests + done summary), and exits. The fresh context per task is what enables N tasks to run in parallel without context-bleed. ## Carmack-level review The strict cross-model review tier flow-next runs by default. References John Carmack review standard. Five confidence anchors (0/25/50/75/100) gate findings; `<75` suppressed except P0 @ 50+; introduced vs pre-existing classification means only introduced findings count toward the verdict. ## Triage skip A deterministic whitelist pre-check that returns `SHIP` without invoking a review backend, for trivial diffs: lockfile-only / docs-only / release-chore / generated-file-only. `flowctl triage-skip` is the helper. On by default in Ralph mode; opt-out via `--no-triage` or `FLOW_RALPH_NO_TRIAGE=1`. ## PR-as-cognitive-aid A structured PR body synthesizing nine flow-next state streams (spec with R-IDs, per-task done summary + evidence commits, decisions / bug / architecture-patterns memory, glossary changes, strategy alignment, deferred review findings, the diff itself) into a reviewable artefact. Body sections: TL;DR, R-ID coverage table, Critical changes, How to review this PR (trust-calibration coaching block), Review plan (every changed area risk-bucketed into Must review / Spot-check / Safe to skim with a cap of \~30% of the focus budget), Decisions, Memory, Glossary/strategy deltas, Open items. Produced by [`/flow-next:make-pr`](https://flow-next.dev/skills/make-pr/). ## Ralph The deprecated repo-local autonomous harness: an external shell loop that drives a fresh agent session per task with cross-model review gates, hook-enforced guardrails, and receipt-based proof-of-work. It consumes **fully planned** specs only and never runs the planning fan-out. Full page: [Ralph](https://flow-next.dev/autonomy/ralph/). ## Pilot The single-tick build-loop conductor ([`/flow-next:pilot`](https://flow-next.dev/skills/pilot/)). One tick advances one ready spec by one pipeline stage and ends with a terminal `PILOT_VERDICT` line; the host’s `/loop` or `/goal` owns iteration. Selection consumes the `ready` gate, and two healthy no-advance ticks clear that flag. Full page: [Pilot](https://flow-next.dev/autonomy/pilot/). ## Backlog mode (`pilot.autonomy`) Pilot’s opt-in wide-autonomy behavior, gated by `pilot.autonomy` in `{ready (default), backlog}`. A backlog tick enumerates the full open set (flow specs plus tracker issues at the promoted lane), selects the top dep-ordered actionable item, triages it, and either advances it one stage or parks it behind an async question. It never authors a spec, never sets `ready`, and never merges. Full page: [Backlog mode](https://flow-next.dev/autonomy/pilot/#backlog-mode). ## Triage stage (backlog mode) The classify-and-route stage backlog mode runs in front of pilot’s own classify, on the selected item only. It reads the spec agentically, never from a computed score: **workable** advances, **dep-unsatisfied** sequences behind its blocker, and **ready-but-thin** is kicked back with a question. ## Ask stage / question valve Backlog mode’s async human-in-the-loop valve: stuck becomes a question rather than a stall, and never an interactive prompt. Each question is written into the spec’s `## Open Questions` behind a stable anchor and projected to the tracker when the bridge is active, then the item is parked (`ASKED`) and the loop moves on. ## Decision log (`pilot-log`) The per-tick record backlog mode writes via `flowctl pilot-log append`, stored as row files under `.flow/pilot-runs/` (`{tick, id, action, stage, costTokens}`). It is what makes the factory-efficiency readout possible: how much moved with no question, with one async answer, or parked, and at what cost. ## Land The cadence-tick ship loop ([`/flow-next:land`](https://flow-next.dev/autonomy/land/)). One tick discovers the open PRs the build loop authored (branch match **and** the make-pr breadcrumb, both required), walks each through the gate tree, and takes at most one action class per PR per tick, ending with a `LAND_VERDICT` line. It is the only place in flow-next licensed to auto-merge. Full page: [Land](https://flow-next.dev/autonomy/land/). ## QA stage (`pipeline.qa`) The optional live-app QA pass ([`/flow-next:qa`](https://flow-next.dev/skills/qa/)) as a config-gated pilot stage (`pipeline.qa`, default off). When on, pilot runs one live pass over the complete build at all-tasks-done, before make-pr. Full page: [Live-app QA](https://flow-next.dev/guides/live-qa/). ## Verdict The structured tick outcome a loop skill prints for transcript-blind drivers, always the last line of a tick: `PILOT_VERDICT=`, `LAND_VERDICT=`, `CHART_VERDICT=`, `RESOLVE_PR_VERDICT=`. Terminal names are never renamed, because drivers grep them. Grammar and tables: [Driving a loop](https://flow-next.dev/autonomy/driving-a-loop/#the-verdict-line-is-the-contract). ## Spec-as-PR A team workflow where the spec is opened as a draft PR for review BEFORE any code lands. Reviewing a 50-line spec is higher-leverage than reviewing a 500-line implementation. Once merged, the spec is frozen on main; implementation PRs reference the merged spec. ## Frozen-at-handover The R-ID invariant. Once a spec has been reviewed once, R5 means the same thing forever. A reviewer reading R5 in a six-month-old commit, a new team member reading R5 in the spec, and `/flow-next:make-pr` emitting R5 coverage all refer to the same acceptance criterion. Renumber-forbidden after first review cycle. ## Tracker An external issue tracker (Linear, GitHub Issues, GitLab, or Jira) that flow-next *projects* a spec to via [`/flow-next:tracker-sync`](https://flow-next.dev/integrations/tracker-sync/). The tracker is a **co-editable mirror**: body, status, and comments sync two-way, but it is **projection, not coordination**. The `.flow/specs/.md` spec stays the source of truth and the quality layer, and the tracker never drives flow state or spawns agents. The skill owns semantic judgment; `flowctl tracker` owns deterministic provider operations. Distinct from `/flow-next:sync` (plan-sync). ## merge-base snapshot The common-ancestor body the tracker-sync 3-way merge compares against - a **paired** snapshot taken at the last sync point: both a flow-form body and a tracker-form body, plus content hashes (the echo fence). Stored in the spec-JSON `tracker` block (`mergeBaseFlow` / `mergeBaseTracker` / `baseHashFlow` / `baseHashTracker`) and written atomically as a unit (a one-sided update is rejected, so neither half pins to a stale sync point). Advances with `lastSyncedAt` on a real reconcile, never on a no-op echo. ## discovery ceremony The detect, surface, ask, never-assume flow `/flow-next:tracker-sync` runs before enabling the bridge. It probes destination and credential signals, surfaces what is present and absent, asks the user, and writes `tracker.*` config **only on confirmation**, with provenance. `flowctl tracker resolve` then persists normalized destination metadata and capabilities under `tracker.resolved`. No signal means nothing written; the bridge stays off. Resolution precedence is env > config > ask. ## tracker-key handle A tracker identifier (e.g. `WOR-17`) used as a **resolvable flow id**, the hybrid id model. **Tracker-first** specs are canonically `wor-17-slug` (tasks `wor-17-slug.M`); bare `wor-17` / `wor-17.M` resolve as aliases. **Flow-first** specs keep `fn-NN-slug` and store `WOR-17` in `tracker.identifier` as a resolvable display alias. Resolution is case-insensitive (`show wor-17`, `work wor-17` resolve); the native `fn-` scheme is reserved (`fn-N` allocation counts `fn-*` only); one tracker team per repo; **ids never rename** on link. ## dependency projection Tracker-sync’s projection of a spec’s local `depends_on_epics` edges into tracker relations through `flowctl tracker relate`. Linear and Jira use native directional blocked-by relations. GitHub records a `sub_issues` hierarchy proxy and returns structured degradation because GitHub has no issue-level blocked-by relation. GitLab uses native blocked-by when `tracker.resolved.capabilities.blockedBy` is true; otherwise it uses a directionless relation plus a provenance-fenced `` body block. Flow stays authoritative, operations are idempotent, and only direct edges project. ## tracker result class The exhaustive failure taxonomy every `flowctl tracker` invocation returns: `invalid_input`, `inactive`, `unresolved`, `auth`, `rate_limited`, `transport`, `not_found`, `capability`, `conflict`, `stale_id`, `external_action_required`, with fixed exit codes 2 through 12. Callers branch on the class, never on provider error text. ## provenance ledger The per-spec `depRelations` list (in the `.flow/specs/.json` `tracker` block, atomic write) records **which** dependency relations tracker-sync created so projection is idempotent and provenance-aware. Each entry is `{key, dep_spec, from_tracker_id, to_tracker_id, type, source, updatedAt}`, where `key` is an opaque hash of the directed issue pair (never a raw issue key inline - trackers auto-linkify keys even inside HTML comments). Projection is additive-only: flowctl never removes tracker relations. A missing ledgered relation that remains declared locally is deferred as a conflict instead of silently recreated. Mirrors the merge-base hash-provenance shape, minus its paired-snapshot constraint. ## completed-blocker rule The tracker-sync semantics for a dependency whose **local** dep spec is `done` (its issue Done/Closed): the projected blocked-by relation stays **visible** on the tracker (preserving the real historical ordering on the board) but does **NOT** feed back into Flow `ready=true` gating - readiness already treats done deps as satisfied, and dependency projection must not regress that. Keys off the *local* dep-spec status (flow is authoritative), never a remote fetch. ## render lens A regenerable human-review artifact (HTML) derived from a markdown source of truth; never the storage format, always re-derivable. flow-next ships two: the spec artifact and the PR artifact, both living at fixed deterministic paths under `.flow/artifacts//` (never timestamped - Lavish keys annotation sessions on the absolute path). Every lens is self-contained single-file HTML (inline CSS/JS, zero external requests), carries a staleness stamp in its footer, and is never parsed back as state - regeneration always overwrites the same file. ## HTML artifact mode The opt-in feature (2.0.0+) that makes participating skills (capture, plan, make-pr) emit render lenses alongside their markdown output. Activated via `flowctl config set artifacts.html.enabled true` (OFF by default, offered once by `/flow-next:setup`); when active, skills load the shared disclosure reference - the single carrier of all generation rules and the anti-slop design contract. With the mode off, skills load nothing extra: zero token cost, zero behavior change. Markdown and tracker-sync remain the sole source of truth. ## spec artifact The spec’s render lens at `.flow/artifacts//spec.html`. ONE generation pathway with state-dependent rendering: spec-only view before tasks exist (the business-review surface) and the added plan layer (task dependency DAG with critical path, R-ID to task coverage matrix) once tasks exist. Links back from the spec markdown via the idempotent `` marker line (replaced in place, repo-relative target). The only artifact that enters the Lavish annotate loop. ## PR artifact The PR’s render lens at `.flow/artifacts//pr.html`, emitted by `/flow-next:make-pr` after the structured cognitive aid. A **read-only review instrument**: diff-derived (never from commit messages), verified against the spec’s R-ID export before publishing - mismatches render as visibly flagged rows, warn-in-artifact, never blocking. A current v1 lens embeds the exact HTML-safe semantic carrier and stays local-only so it cannot advance and stale its own reviewed head; only the labeled legacy fallback may use the narrow artifact commit. It never enters the annotate loop - review conversation belongs to the code host. ## Lavish (lavish-axi) An optional detect-on-PATH companion (npm: `lavish-axi`) for annotating spec artifacts in the browser - never wrapped, bundled, or required (same shape as clawpatch/`/flow-next:map`). Feedback is pull-only and session-spanning: annotations queue in the global `~/.lavish-axi/state.json` (not per-workspace), survive agent death, and any later agent session drains them via the `lavish-axi poll` CLI, mapping each annotation to a markdown-source edit followed by lens regeneration. Sessions key on the absolute artifact path (different worktrees = separate sessions); the local server idle-stops after \~30 min and `lavish-axi ` resumes it - absence or idle-stop is invisible because the artifact is a self-contained static page. Autonomous contexts never open a session and never poll. ## Operability ladder Prime’s tiered measure of whether an agent can actually *operate* a repo, scored from executed evidence rather than file existence: tier 1 = the build command actually runs, tier 2 = tests are discoverable and run, tier 3 = the app boots to a ready signal. Tiers are per-surface with a min-deployable headline (a monorepo carries per-member tiers, never one repo tier); a shape whose realistic ceiling is tier 1-2 reports “N/N at ceiling” and is offered a sideways move into observability/drivability instead of a fabricated tier bump. The verdict headline names the current operability tier and the single cheapest move up. *Relates to:* [Hard gate](https://flow-next.dev/reference/glossary/#hard-gate), [Classification (prime)](https://flow-next.dev/reference/glossary/#classification-prime) ## Hard gate One of prime’s three pass/fail gates that catch the existence-passes-but-execution-fails failure mode: G1 = the detected build command actually runs (or tier >= 1 operability evidence exists), G2 = tests are discoverable when a test framework is claimed, G3 = the agent instruction file’s quoted commands resolve and execute. Any failing gate is NAMED in the verdict headline with its error and caps the computed maturity level at 2, so a repo cannot reach a high “readiness level” on existence checks alone. *Relates to:* [Operability ladder](https://flow-next.dev/reference/glossary/#operability-ladder), [Classification (prime)](https://flow-next.dev/reference/glossary/#classification-prime) ## Delivery shape Axis 5 of prime’s classification: the multi-valued kind(s) of thing a repo delivers (web-service, CLI, library, desktop app, prose/docs, and so on). The `flowctl prime classify` emitter emits raw shape markers (bin exports, framework markers, serve/health code, desktop markers, prose ratio); the skill resolves the final shape value(s) from those markers. Delivery shape selects the per-shape playbook and sets the realistic operability-tier ceiling (a library or prose repo honestly tops out below a bootable web service). *Relates to:* [Classification (prime)](https://flow-next.dev/reference/glossary/#classification-prime), [Operability ladder](https://flow-next.dev/reference/glossary/#operability-ladder) ## Classification (prime) Prime’s Phase 0.5 five-axis profile of a repo: lifecycle (greenfield / hybrid / brownfield), topology (two independent bits: monorepo, constellation-member), size/legibility band, stack(s), and delivery shape(s), plus an orthogonal `assessment_scope` (repository / workspace-member / constellation-home-base). The deterministic signals come from the `flowctl prime classify --json` emitter (bounded, pure-stdlib, no LLM); the skill layers judgment on top (Axis-5 shape reasoning, final per-axis confidence, bounded clarification asks, playbook selection). Classification parameterizes everything downstream: scout dispatch hints, N/A denominators, report shape, and playbook selection. `--classify-only` prints just this block for cheap portfolio triage. *Relates to:* [Operability ladder](https://flow-next.dev/reference/glossary/#operability-ladder), [Delivery shape](https://flow-next.dev/reference/glossary/#delivery-shape), [Hard gate](https://flow-next.dev/reference/glossary/#hard-gate)