Record plan provenance at save time and add refinedBy field

[williamthorsen]

Description

When a developer creates a plan using Claude's built-in plan mode and saves it with /save-plan, the plan enters the artifact system with no provenance. If they then run /refine-plan, the plan is reviewed and revised against the codebase — but the provenance system can't distinguish "refined plan of known origin" from "plan of truly unknown origin."

The root cause is that /save-plan doesn't record provenance, and /refine-plan can only preserve or update provenance that already exists. This leaves a traceability gap and prevents the orchestrator from making informed trust decisions about refined plans.

Design

Introduce a refinedBy field in the provenance block to separate authoring from processing:

• skill: the process that authored the plan (origin)
• refinedBy: the process that validated/revised it (single string, set by refine-plan)
• iteration, timestamp, baseSha: unchanged semantics

Example provenance after the typical flow (plan mode → save → refine):

provenance:
  skill: plan-mode
  timestamp: 2026-03-16T08:00:00Z
  baseSha: abc123
  refinedBy: refine-plan
  iteration: 2

Rationale

The orchestrator's trust evaluation currently recognizes design-and-plan, writing-plans, and plan-orchestrable-steps as credible sources. With refinedBy as a separate field, trust evaluation can consider both origin and processing independently — e.g., a plan-mode plan refined by refine-plan might warrant medium trust, while an unrefined plan-mode plan stays low.

Acceptance criteria

Must have

• /save-plan adds a provenance header with skill set to the name of the authoring process (e.g., plan-mode for Claude's built-in planning)
• /refine-plan sets refinedBy: refine-plan on the provenance block rather than overwriting skill
• /refine-plan handles empty-provenance input by setting skill: unknown (or similar) plus refinedBy: refine-plan
• refinedBy is a single string, not a list

Should have

• Orchestrator trust evaluation in /orchestrate updated to consider refinedBy as a trust modifier
• Determine the correct skill name for Claude's built-in plan mode (it uses EnterPlanMode/ExitPlanMode — need to decide on a canonical name)

Nice to have

• Document the provenance field semantics (skill = origin, refinedBy = processing) in a central reference

[williamthorsen]

Insight: Provenance flow consistency verified

The holistic review traced five provenance flows end-to-end and confirmed internal consistency:

1. plan-mode → save → refine → orchestrate → medium trust (capped by refinement-elevated)
2. plan-mode → save → orchestrate (no refinement) → low trust (non-credible source)
3. no provenance → refine → orchestrate → medium trust (skill: unknown + refinedBy: refine-plan)
4. design-and-plan → refine → orchestrate → high trust unaffected (credible source, refinement doesn't lower trust)
5. refinement-elevated + unverifiable freshness → low trust (freshness gate still applies)

All flows produce correct trust tiers. Credible-source plans are unaffected by the presence or absence of refinedBy.