Motir

A work item carries an implementation provenance triple — implementationSource / implementationHarness / implementationModel — and markIntegrated's own comment says what it is for:

BYOK/manual self-report (MOTIR-1685): the external agent reports the harness + model it ran with AT integration time

The CLI passes implementationHarness: HARNESS, which is motir-cli/<version>. That is the tool that LAUNCHED the agent, not the agent. And implementationModel is never passed at all, so it is null on every card ever integrated.

So the field that exists to answer "what built this?" answers "motir-cli" for every BYOK card — true of all of them, and therefore says nothing.

The asymmetry that shows it

The PLANNING half of the same triple is recorded honestly. A card created over MCP carries planningHarness: "Claude Code" and planningModel: "claude-opus-5" — the real tool and the real model. Cards on this very story show both sides at once: planning provenance populated and specific, implementation provenance null / null until integration, then motir-cli/<version> / null.

Same triple shape, same purpose, one side truthful.

The channel — who knows what

Neither actor can supply both halves, which is why this has stayed broken:

• The LOOP knows the harness. It launched the agent; --agent 'claude --dangerously-skip-permissions' is right there. Deriving the name from the command it ran needs no cooperation and cannot be misreported.
• Only the AGENT knows the model. Nothing outside the process can see which model answered.

So: derive the harness in the loop, take the model from the agent's self-report, and record null rather than a guess when the agent says nothing. The same division the PR-body card lands on — each writes what it alone knows.

The self-report channel is a real choice and is left to the implementation: a small file at a known path in the workspace is the obvious candidate (local, no API surface, the agent already has a shell), but a comment on the card or an argument on the integration call are defensible. Whatever is picked, an agent that reports nothing must still leave a truthful harness rather than a wrong one.

Scope BOUNDARY

motir auto's integration call, the harness derivation, and the prompt line that asks the agent to report its model. It does NOT change the schema, markIntegrated, or the v1 integration endpoint — all three already accept the triple. It does NOT backfill historical rows: they recorded motir-cli and rewriting them would claim knowledge nobody has. ⚠️ It does NOT fix motir batch, which never calls markIntegrated at all and therefore records NO implementation provenance for any card it runs — a real second gap, named here so it is not mistaken for this card's, and worth its own.

Acceptance criteria

• implementationHarness names the agent that ran — derived from the agent command the loop launched — asserted against a run configured with a recognisable agent.
• implementationModel is populated when the agent reports one and null when it does not, asserted both ways. A guessed or defaulted model is a wrong answer that looks like a right one.
• implementationSource stays byok; nothing here touches the source axis.
• A run whose agent reports nothing still records a truthful harness, never motir-cli/<version>.
• The prompt asks the agent for its model, in both workflow-mode variants.
• No historical row is rewritten.

Context refs

• lib/services/workItemsService.ts — markIntegrated, recordImplementationProvenance, and the MOTIR-1685 comment stating the intent.
• packages/cli/src/commands/dispatch.ts · auto.ts — HARNESS and the two markIntegrated call sites.
• lib/services/dispatchPromptService.ts — where the prompt line goes.
• MOTIR-2406 — the prompt's outcome protocol; this line belongs beside it.
• Story: MOTIR-1855.