Skip to main content

Capability Reporting

How does Engineering prove that a capability is real?

Engineering should emit a capability heartbeat after a merge that realizes Dream demand. The heartbeat gives Dream enough structure to run ops-close-vvfl-loop without rereading the whole PR.

Standard​

The report names:

  • capability proven;
  • PR number and merge date;
  • originating demand or bridge;
  • proof command and result;
  • Dream entity satisfied;
  • residual gap, if any.

The Stackmates skill eng-capability-surface owns this report. It composes git-pr-merge-cleanup, sm-comms, and receipt emission. It does not edit Dream files.

Action​

After a Stackmates merge, run the Engineering capability surface instead of editing Dream directly. The output should be a #meta heartbeat plus a receipt that Dream can consume.

Minimum message shape:

Capability proven: {name}. PR #{number}. Demand: {P-NNN or bridge}. Test: {pass|fail}. Dream entity: {entity}.

Dream then runs ops-close-vvfl-loop to decide whether the proof changes REALITY, sharpens DREAM, or exposes a vicious side effect.

Checks​

  • The report uses --from=intelligence-engine.
  • The message goes to dream-team on #meta.
  • The proof is specific enough to classify full, partial, no realization, or vicious.
  • Dream consumes the report before filing a stronger demand.

Failure Modes​

  • PR as proof: a merge exists, but no outcome, test, or Dream entity is named.
  • Dream mutation: Engineering edits Dream files instead of sending proof through drmg.
  • Unconsumed heartbeat: the report lands in #meta, but no receipt or mirror update follows.
  • Partial proof hidden: a failed or partial test is reported as if the capability were fully REALITY.

Context​

Questions​

What new Reality does this merge prove?

  • Which Dream entity does the merge satisfy?
  • What command or test proves the claim?
  • What residual gap should stay DREAM?