PROP-047 — Progress Control: the campaign toolchain

1. Mandate — the process layer

01The owner's boundary ruling (2026-08-22, chat, near-verbatim): «факты являются чем-то, поверх чего можно построить совершенно разные процессы рефакторингов, и не факт, что наша текущая кампания и способ вообще делать кампании — самый лучший. Всё, что касается самого синтаксиса, IR, операций над фактами — в модуль facts (это будет использовать широкая общественность); в progress оставить наши инструменты для рефакторингов vibevm и потихоньку доделывать, чтобы когда-то они стали достаточно хороши, чтобы показать миру.» This document is that progress layer: the tool, its config, evidence providers, campaign data contracts, and the maintenance discipline. The grammar it operates on is PROP-043 (spec://org.vibevm.core/vibevm/modules/vibe-facts/PROP-043), and the dependency points strictly upward: progress knows facts; facts never knows progress.

02The needs this layer answers (moved verbatim from the founding motivation of PROP-043 §1):

1. 03an algorithmic tool that reports the state of the whole observed tree and enforces exhaustiveness when a campaign demands it;
2. a substrate for the actualization campaign: mark every claim, verify it against the code, and drive the drift down — with the markup remaining afterwards as the steering mechanism for further development.

• 04The vibevm adapter contributes the vibe progress CLI surface (§3), the facts.toml discovery, and the specmap evidence provider (§4). All vibevm-specific knowledge lives here.

2. Scope configuration — moved to the facts home

05Scope configuration is a facts-layer concern and lives in PROP-043 §6 (owner correction 2026-08-22: «what is observed» is a universal question every facts consumer answers — the campaign toolchain merely consumes the same scope through the facts core). The config file is facts.toml; progress.toml is read as a silent legacy fallback for the transition. This heading keeps its number so the section map below stays stable.

3. The tool — vibe progress

• 06A subcommand of vibe (adapter over the standalone core).
• Native output is XML; --md renders the table form (source · stage · state · action · comment); --json emits the state projections of §5.2.
• All subcommands are incremental over the content-hash cache (§5.1).

• 07scan {#scan} — parse the observed tree, build/update the cache and state projections.
• check {#check} — validation gate: closed vocabularies (with nearest-value hints), well-formedness (unclosed point markers), placement rules (standalone-between-paragraphs), shorthand collisions, foreign-grammar non-collision, lossless folds. --exhaustive additionally requires zero unmarked paragraphs in scope — the campaign gate. Exit codes are stable for CI.
• report — the tree status: XML native, --md table, --json. Filters: --view done|todo|qa|remove|doc|terminal (the six resolution views: state=done · action=continue · stage=test&state=plan|work · action=remove · actionstage=doc · derived terminal artifact closure), --audience user|author|dev|agent (agent admitted 2026-09-11 by PROP-057 through PROP-043 ##AUDIENCE-VALUES; the doc view lists the documentation's obligations and feeds the coverage gate vibe doc check --coverage, PROP-057 §14), per-file and whole-project rollups, explicit-vs-computed columns, and the evidence column when a provider is wired (§4).
• mirror — materialize the per-file cache view (campaign working representation; §5.1) under the campaign zone.
• weave — algorithmic stitch of the observed corpus into one document for whole-context LLM loading. --digest emits the map form (headings + markers + unmarked counts — always fits); --max-tokens N shards the full form with a shard manifest. Measured 2026-07-26 on the 58-file wave-1 corpus: the full weave is one shard of 1 138 441 bytes (≈ a third of a 1M-token window, so the sharder never had to split) and --digest is 200 454 bytes.
• rescan --baseline <file> {#rescan} — the recurrence entry point: three-way compare (sources ↔ markers ↔ baseline, §5.3) emitting new / changed(suspect) / carried-forward unit lists, plus "marker changed outside any campaign" flags.
• baseline [--out <file>] {#baseline} — write the campaign's baseline.json (§5.3), the file rescan consumes. Projects the cache's fact-grain verdicts onto the unit granularity the baseline contract is defined at: a fact rolls up into every unit whose span carries it, the worst verdict wins (drift > unverifiable > confirmed), evidence is the deduplicated union, and the marker snapshot is resolved by the same code path rescan compares against. It re-verifies nothing and invents no verdict — a unit with no judged fact is omitted rather than filled in, so the artifact fails toward re-verifying. Default output is campaigns/<id>/baseline.json.
• seal <path>… — record that a file's verdicts hold for its current text: sets content_hash and campaign.processed_hash to the digest recomputed from disk, plus verified_at. Same shape as ##CMD-GATE — the caller did the real re-derivation and this records it; the command computes, changes and invents no verdict. Reading the cached content_hash instead of the disk would defeat the purpose, since that field is refreshed only by scan and between scans compares one stale value with another. It refuses a file whose markers are not all judged (naming the count and the first few), refuses a path the cache does not carry, prints what it is vouching for before doing it, and is a no-op with no fresh timestamp when the digest already matches. Its refusal is a coverage test, not a recency one — the schema carries one date per file and none per verdict, so "every marker has a verdict" is checkable and "every verdict is fresh" is not; the operator asserting the seal is the real gate (F-075).
• gate {#gate} — record one gate's verdict into the campaign's gate panel in campaign.json. The automation seam: whoever ran the real gate reports the result here, and the dashboard reads it back out. Spawns nothing and computes nothing — gates are recorded, never run here.
• resume {#resume} — render RESUME.md from the campaign journal and state (operates on the campaign zone when present; a no-op outside one).

4. Evidence providers

• 08The core defines a seam: given a unit, return external facts about it.
• The vibevm adapter wires specmap (PROP-014) into it: implements / verifies / deviates edge counts per unit.
• report then flags markup-vs-reality mismatches — e.g. a unit marked test/done with zero verifies edges. An unclassified freeze/done specmap orphan retains the legacy implementation warning; a classified frozen fact is checked only against the artifact kinds in its own @requires set. check can gate on the worst mismatch without inventing an undeclared implementation obligation.
• A project without specmap runs with an empty evidence column; nothing in the core knows the provider's shape.

09Verification verdicts (confirmed / drift / unverifiable) are campaign data and live in the cache and baseline — never in the markup (§5.5).

10Fact-grain evidence (2026-07-24, owner-directed): the specmap side recognises @fact:<ID> fact anchors as addressable units (PROP-014 §2.1, the fact amendment's twin), so implements/verifies edges land per fact and the provider's mismatch checks apply at the campaign grain, not only per section.

11The evidence seam also serves PROP-043 ##TERMINAL-PER-ARTIFACT: for each declared terminal artifact it reports satisfied | missing | unavailable and exact locators when it has them. The facts core itself satisfies self-carried specification/decision/research/plan/disposition artifacts from their explicit declaration on the addressed state=done fact; the vibevm specmap adapter observes exact implements, verifies and documents relations; an external artifact stays unavailable until an observer can check its ref. A provider absence and a known zero are never conflated.

12report renders the authored canonical requires set, each artifact observation, and the derived unclassified | pending | terminal result. A separate terminal view selects only terminal facts; the existing done view remains exactly state=done. XML/Markdown/JSON projections share one row model. Dashboard/state projections consume that result and never recompute it from partial cache fields.

13A terminal observation answers only whether the fact's declared artifact set is currently satisfied by this provider snapshot. Campaign verdicts (confirmed | drift | unverifiable), lifecycle verification evidence and adoption remain separate axes. The observation is never written into authored markup, the tracked cache or a baseline as truth.

5. Data contracts

14All formats are schema-versioned ("schema": 1); all writes are atomic (tmp + rename); the journal is append-only JSONL (a torn tail line is discarded on read).

6. Maintenance discipline

21After the first campaign:

• 22Edit a unit ⇒ update its marker in the same commit. vibe progress check sits in the gate panel and yellows on divergence.
• Task pipelines close the loop: an IMPL task cites markers on entry and updates them on exit (impl/work → impl/done, then test/plan).
• A classified freeze/done fact requires the artifact evidence its own @requires set names; freeze alone never manufactures an implementation obligation. An unclassified frozen fact retains the legacy implementation-edge warning during migration, so introducing terminal contracts cannot silently weaken an existing gate.
• Doc-coverage (units lacking documents edges / doc-view closure) ratchets like specmap orphans.
• Periodic re-verification runs as a recurring campaign (O(delta) via §5.3) and as a health-audit category between runs.

7. Out of scope / future

• 34second-wave corpora (vibevm/vibepacks/org.vibevm.world, org.vibevm.ai-native, ~230–250 authored files) and the fractality specspace (explicitly excluded from wave 1 by owner decision);
• dashboard evolution beyond the minimal read-only page.
• (Terminology note: this surface is always called the dashboard — never "storefront", a term already taken by the vibevm store surface.)