GGLYPHDLABS
← Technical notesIMPLEMENTED

Spark-Dex: A Manifestation Sidecar for IDE Agents

Separating what an AI says, what a project contains, and what evidence can actually support

Abstract

A coding model can say that a task is complete before the expected file exists, after a test result has become stale, or while an unresolved human decision still blocks the work. Ordinary chat and terminal logs make these conditions difficult to distinguish because language, intention, execution, and verification appear in one chronological stream.

Spark-Dex is a local-first manifestation sidecar runtime for IDE agents. It runs beside the editor and maintains a persistent Manifest describing the work that is becoming real. Model statements become proposals. Human authorization remains distinct. Filesystem and command observations record material change. Receipts support verification. A browser surface renders the current state without treating confident language as evidence.

Spark-Dex is not presently a public protocol, a hosted service, or a finished end-user application. It is an implemented research instrument and reference runtime that tests a narrower proposition: an IDE agent becomes more inspectable when project state and evidence are represented outside the chat transcript.

Classification

The most accurate category is manifestation sidecar.

A sidecar does not replace the IDE, repository, model, terminal, or application preview. It operates alongside them and reconciles their claims into a separate work-state object. This distinguishes Spark-Dex from three adjacent categories:

  • Chat interface: preserves language but does not establish whether the described state exists.
  • Application preview: renders one artifact but does not represent the larger undertaking, its authority, or its evidence.
  • Agent protocol: standardizes communication between systems. Spark-Dex has an API and event model, but those interfaces have not yet earned the stability, interoperability, or external implementations required to call them a protocol.

The intended division is:

human + IDE agent
        ↓ proposals and actions
Spark-Dex Manifest
        ↓ observed state + receipts
localhost manifestation surface

What is different

Spark-Dex makes four states explicit:

  1. Proposed — the model has described or requested a change.
  2. Accepted — an authorized actor has admitted the change into the work.
  3. Materialized — the project or an external system has actually changed.
  4. Verified — current evidence satisfies the declared completion condition.

These states are not synonyms. A valid file mutation can still be unverified. A passing test can become stale after a later edit. A convincing completion statement can remain an unsupported claim. Spark-Dex therefore treats progress as an evidenced delta in shared state rather than a sentence in a transcript.

The Manifest is the durable center. It can retain goals, constraints, tasks, decisions, artifacts, observations, receipts, blockers, and a hash-linked event history. Models remain replaceable producers of proposed mutations. The Manifest owns continuity.

What has been achieved

The current reference implementation establishes the following bounded mechanisms:

  • a local-first Node.js runtime with no required cloud service;
  • a CLI, HTTP API, JavaScript SDK, and localhost browser surface;
  • append-only Manifest events and replayable state;
  • task transitions that keep proposal, acceptance, materialization, and verification separate;
  • command, file, JSON, HTTP, and manual evidence receipts;
  • invalidation of file-backed evidence after the referenced file changes;
  • workspace path confinement, optimistic revision checks, and cross-process write locking;
  • secret redaction safeguards for captured command output;
  • model-agnostic operation inside Cursor or another coding environment;
  • automated behavioral checks for the packaged reference runtime.

The public Glyphd Labs instrument demonstrates the state logic without shipping the private development runtime or calling a deterministic browser fixture a production result.

What has not been achieved

Spark-Dex has not yet established:

  • a stable cross-vendor protocol with independent implementations;
  • a first-class Cursor extension or universal automatic adapter for IDE model events;
  • reliable attribution under concurrent human, agent, formatter, build, and background-process edits;
  • automatic generation of trustworthy acceptance criteria for arbitrary work;
  • multi-user identity, remote authorization, or production-grade network exposure;
  • measured reduction in false completion, resume time, review effort, or cognitive load;
  • long-duration evidence that the Manifest remains more accurate than disciplined repository and issue-tracker practice;
  • external security review or production hardening;
  • a public downloadable distribution through Glyphd Labs.

These are not minor polish items. They are the boundary between an implemented mechanism and a broadly dependable operating layer.

Benchmarkable claims

The important claims are behavioral rather than aesthetic. A future matched-condition study should compare ordinary IDE-agent chat with Spark-Dex-assisted work on the same repositories, tasks, models, and reviewers. Candidate metrics include:

  • unsupported completion-claim rate;
  • time required to determine the actual project state;
  • stale-evidence detection rate;
  • acceptance-criteria coverage;
  • recovery accuracy after reopening a task;
  • reviewer disagreement about whether work is complete;
  • additional interaction and recording overhead;
  • false refusal and false invalidation rates;
  • human confidence calibration against observable reality.

The existing SurfaceDelta benchmark is the nearest institute contract because both systems separate generated prose from schema-bound state change. A dedicated Spark-Dex benchmark remains future work.

Next steps

  1. Stabilize the event vocabulary around proposal, authority, observation, receipt, invalidation, and verification.
  2. Build a narrow Cursor adapter that emits Manifest events without requiring the model to remember formatting instructions.
  3. Add a repository observer that distinguishes human edits, model edits, generated output, and external process mutations.
  4. Define a matched-condition benchmark and publish a founder-local run packet before making productivity or accuracy claims.
  5. Test interruption, branch switching, failed commands, stale receipts, concurrent edits, and reopened sessions across several real repositories.
  6. Decide whether the proven common event subset deserves extraction as a public protocol.

Publication boundary

The public demo proves only that the authored browser-local fixture obeys its deterministic state contract. The separate Spark-Dex reference runtime is implemented, but this note does not claim production reliability, measured developer benefit, universal IDE support, or protocol adoption.

Source register

  • N17-S01 — “Generating Language Is Not the Same as Doing What the Language Says,” Glyphd Labs P01.
  • N17-S02 — “Work, Return, Verification, Acceptance,” Glyphd Labs N05.
  • N17-S03 — “The Two-Note Proof,” Glyphd Labs N16.
  • N17-S04 — Spark-Dex v0.1.0 reference implementation and user guide, private development repository, 2026-07-30.