What the model says
No completion claim has been generated.
Spark-Dex Manifestation Runtime
Watch agent language, accepted work state, observed project change, and verification diverge or reconcile
MECHANISMManifest state separated from model language, project observation, and evidence
AUTHORITYHuman acceptance plus current file and command receipts
COMMIT RULEOnly accepted material change with current evidence becomes verified.
FAIL-CLOSED RULEUnsupported completion is refused and stale evidence loses authority.
MANIFEST STATEREADY
8390347fevents0
taskNo Manifest task exists.
receiptNONE
What the work recognizes
No Manifest task exists.
No acceptance decision is recorded.What materially changed
No project mutation is observed.
What can be supported
No verification receipt exists.
- READY
- UNVERIFIED_CLAIM
- PROPOSED
- ACCEPTED
- MATERIALIZED
- VERIFIED
- STALE
- REFUSED
CONTRACT CONTROLS
Operate the lanes in sequence, or deliberately select them out of order. Each action records a deterministic local receipt.
RECEIPTED EVENT LOG
No transition yet. Generate a claim or operate a Manifest control.
FIXTURE ASSERTIONS
NOT YET EXERCISEDGenerated completion language does not change the Manifest.
NOT YET EXERCISEDMaterialization is recorded separately from verification.
NOT YET EXERCISEDA later file mutation invalidates prior evidence.
NOT YET EXERCISEDUnsupported completion is refused rather than silently promoted.
INTERPRETATION
VISIBLE DIFFERENCEThe same task can be claimed, proposed, materialized, verified, or stale without those conditions being collapsed into “done.”
NOT ESTABLISHEDThis fixture does not measure developer performance, agent correctness, or production reliability.
This browser-local instrument demonstrates the authored Spark-Dex state contract. It does not call a model, inspect a repository, execute a command, or expose the separate private reference runtime.
Purpose
Demonstrate why an IDE agent's completion language must remain separate from accepted project state, observed material change, and current verification evidence.
Spark-Dex is represented here as a manifestation sidecar: a state and evidence layer operating beside an IDE and its model. The public instrument is browser-local and deterministic. It does not connect to Cursor, inspect a real repository, call a model, or distribute the separate reference runtime.
Mechanism
The instrument exposes four synchronized but independently governed lanes:
- Agent language — what the model says or proposes.
- Manifest state — what the shared work object currently recognizes.
- Observed reality — what the project observer reports as materially changed.
- Evidence — what current receipts can support.
A completion claim changes only the language lane. Registering and accepting a task changes the Manifest. Recording a file mutation changes observed reality. A passing test receipt can promote the accepted task to verified. Editing the verified file invalidates that receipt and removes the verified state until a current check is attached.
Deterministic fixture
The fixture follows one bounded IDE task: add and verify a login-flow module. All files, commands, hashes, and receipts are illustrative deterministic labels. No filesystem operation occurs.
Required controls
- Generate completion claim
- Register proposed task
- Accept task scope
- Record file mutation
- Attach passing test receipt
- Edit verified file
- Re-run verification
- Attempt unsupported completion
Visible states
READYUNVERIFIED_CLAIMPROPOSEDACCEPTEDMATERIALIZEDVERIFIEDSTALEREFUSED
Core assertions
- Generated completion language does not change the Manifest.
- Materialization is recorded separately from verification.
- A later file mutation invalidates prior evidence.
- Unsupported completion is refused rather than silently promoted.
What this teaches
The useful distinction is not “chat versus agent.” An agent may execute tools and still leave the human with an opaque stream of claims. Spark-Dex adds a separate object that can say:
The agent claims completion.
The task is accepted.
The expected file changed.
The previous test receipt is stale.
Therefore the work is materialized but not verified.
That sentence is less impressive than “done,” but more operationally truthful.
What this does not prove
The fixture does not prove that Spark-Dex improves developer productivity, prevents all false claims, integrates reliably with Cursor, scales to large repositories, or deserves adoption as a protocol. Those claims require matched real-repository studies and versioned run receipts.
Accessibility and execution boundary
All controls are ordinary keyboard-operable buttons. State changes are announced through a polite live region. Reduced motion preserves every meaning. Reset restores the exact initial state. The default instrument uses no network or paid API.