planr 1.10.0-alpha.6 → 1.10.0-alpha.7

package/docs/contracts/EVIDENCE_CONTRACT_V1.md

@@ -6,7 +6,8 @@ Evidence Contract v1 is Planr's local-first contract for proving acceptance crit
 
 ## Ownership
 
-- Product and build plans own authored acceptance criteria and the reviewed `ProofObligation` records bound to those criteria.
+- Typed build-plan frontmatter owns authored criterion identity as one non-empty, unique, closed list of `{id, title}` entries. Acceptance prose is narrative only.
+- Explicit Evidence migration owns materialization of reviewed `ProofObligation` records bound to those declared criteria.
 - The Evidence domain owns `ProofObligation`, `ObservationRequirement`, `VerificationCapabilityManifest`, `VerificationCapabilityInstance`, `EvidenceAttempt`, `UntrustedEvidenceProposal`, `EvidenceReceipt`, `CoverageVerdict`, `EvidencePolicy`, `ProofPreset`, and `EvidenceWaiver`.
 - Planr assigns trusted provenance only from Planr-observed execution, verified host events, accepted MCP attestation, validated artifact import, or explicit approval-backed user attestation.
 - Public JSON, agent-authored JSON, adapter stdout, logs, and artifacts may propose claims, but they cannot construct trusted provenance, execution identity, freshness, target binding, receipt digest, or closure authority.
@@ -20,8 +21,8 @@ Evidence Contract v1 is Planr's local-first contract for proving acceptance crit
 - Route Audit remains the owner of requested, resolved, and effective routing evidence. Evidence may consume a mapped provenance view, but it must not copy requested route declarations into effective execution proof.
 - Agent Profiles, model-routing capability classes, usage-policy capability classes, MCP protocol capabilities, and context tags are dispatch or protocol metadata. They are not verification capability instances and do not prove runtime availability.
 - Planr logs remain narrative and supporting records. A `kind = verification` log is a claim that can be referenced, but it never satisfies a binding observation.
-- A repository without a binding Evidence policy is explicitly non-binding. A repository whose policy requires binding Evidence but whose plan has no materialized `ProofObligation` is `binding_unsatisfied`: Planr returns a hold before leasing or creating a FeatureRun, persists a capability hold when an existing run reaches readiness, rejects closure, final review, and stop activation, and never substitutes logs or an empty receipt lineage.
-- Migration is the sole obligation-materialization path. It is explicit, plan-scoped, previewable, idempotent, and materializes ordinary immutable `ProofObligation` rows; it must not rewrite plans, logs, reviews, artifacts, or historical claims.
+- A repository without a binding Evidence policy and without binding plan obligations is explicitly non-binding. A binding plan is `binding_unsatisfied` unless its authoritative active obligations match the declared build-plan criterion set exactly: zero, partial, duplicate, or undeclared bindings all fail closed. Planr returns a hold before leasing or creating a FeatureRun, persists a capability hold when an existing run reaches readiness, rejects coverage settlement, closure, final review, and stop activation, and never substitutes logs or an empty receipt lineage.
+- Migration is the sole obligation-materialization path. It is explicit, plan-scoped, previewable, idempotent, and accepts only an exact declared criterion binding set before materializing ordinary immutable `ProofObligation` rows. It must not rewrite plans, logs, reviews, artifacts, or historical claims.
 - Planr artifacts remain files or references with digests. An artifact alone is not trusted evidence unless a trusted receipt binds it to the source revision, target, environment, execution identity, observation results, and policy.
 
 ## Versioning And Compatibility
@@ -62,6 +63,8 @@ Custom observation types must reference a versioned JSON Schema and a registrati
 
 A reviewed, binding or advisory contract for one acceptance criterion.
 
+For a binding build plan, `criterion_id` must name one criterion declared in that plan's checked frontmatter. The obligation does not create criterion identity.
+
 Required fields:
 
 - `id`, `schema_version`, `criterion_id`, `plan_id`, optional `item_id`.
@@ -200,7 +203,7 @@ Coverage gap/failure reason codes:
 
 Operator aliases are rendered as aliases only and resolve to the canonical codes above: `capability_unavailable` -> `missing_capability`, `dependency_unavailable` -> `external_dependency_unavailable`, `policy_failed` -> `stale_policy`, `trust_failed` -> `untrusted_provenance`, and `stale_evidence` -> `stale_source`. Unknown aliases are classified as `verifier_failed` rather than `product_failed`.
 
-Explicit Evidence migration input uses `schema_version = "planr.evidence.migration.v1"`, a single `plan_id`, and an `obligations[]` array of full `ProofObligation` objects whose `plan_id` matches the migration plan and whose `binding` is `true`. Preview is non-mutating. Apply is atomic for the migration payload: any conflict or malformed obligation leaves the plan with no newly bound partial obligations. Reapplying an identical payload is `unchanged`.
+Explicit Evidence migration input uses `schema_version = "planr.evidence.migration.v1"`, a single `plan_id`, and an `obligations[]` array of full `ProofObligation` objects whose `plan_id` matches the migration plan and whose `binding` is `true`. The payload's criterion bindings must exactly match the checked build-plan frontmatter set. Preview is non-mutating. Apply is atomic for the migration payload: any conflict, malformed obligation, missing criterion, duplicate criterion, or undeclared criterion leaves the plan with no newly bound partial obligations. Reapplying an identical payload is `unchanged`.
 
 Process adapters may report a host boundary failure only with an exact single-field JSON line on stdout or stderr:
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "planr",
-  "version": "1.10.0-alpha.6",
+  "version": "1.10.0-alpha.7",
   "description": "Local-first planning and execution coordination for coding agents.",
   "license": "MIT",
   "repository": {

package/plugins/planr/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "planr",
   "description": "Skill-driven planning and execution loop for coding agents: one planr entry point, an autonomous planr-loop, and evidence-backed task graph skills powered by the planr CLI.",
-  "version": "1.10.0-alpha.6",
+  "version": "1.10.0-alpha.7",
   "author": {
     "name": "instructa"
   },

package/plugins/planr/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "planr",
-  "version": "1.10.0-alpha.6",
+  "version": "1.10.0-alpha.7",
   "description": "Skill-driven planning and execution loop for coding agents: one $planr entry point, an autonomous $planr-loop, and evidence-backed task graph skills powered by the planr CLI.",
   "author": {
     "name": "instructa",

package/plugins/planr/skills/planr-goal/SKILL.md

@@ -32,13 +32,13 @@ planr plan check <plan-id>
 planr map build --from <plan-id>
 ```
 
-Fill required plan sections directly. Replace the placeholder task with independently verifiable `TASK-00n` slices before `planr map build`. A small coherent change is one implementation item plus one signal-bearing independent review; do not split mechanical stages into separate implementation/review pairs. Larger scopes still use multiple slices where ownership, dependencies, or independently observable outcomes genuinely differ. Preserve real execution order with `blocks` links. When registry routes use `work_type`, annotate tasks before mapping or retag them afterward; this is prep work, not a user question.
+Fill required plan sections directly. Give every build plan a non-empty, unique frontmatter `criteria` list with only stable `id` and `title` fields; prose under `## Acceptance Criteria` remains narrative and never supplies identity. Replace the placeholder task with independently verifiable `TASK-00n` slices before `planr map build`. A small coherent change is one implementation item plus one signal-bearing independent review; do not split mechanical stages into separate implementation/review pairs. Larger scopes still use multiple slices where ownership, dependencies, or independently observable outcomes genuinely differ. Preserve real execution order with `blocks` links. When registry routes use `work_type`, annotate tasks before mapping or retag them afterward; this is prep work, not a user question.
 
 When the repository provides a versioned verification policy and source-bound receipt runner, make that policy the verification owner in the plan. Record the selected profile, exact receipt path/digest, source revision, and the command that validates the receipt. Do not enumerate broad suites independently in every task when the policy already selects them.
 
 ## Durable Contract
 
-For plans with binding Evidence, require the repository to define the observation obligations and capability policy before execution, then run readiness. Store one contract per plan:
+For plans with binding Evidence, require the repository owner to materialize obligations from the checked frontmatter criterion IDs through explicit `planr.evidence.migration.v1` migration before execution, then run readiness. Never write obligations directly or duplicate `app/proof` completeness rules in the goal contract. Store one contract per plan:
 
 ```bash
 planr evidence readiness --scope plan --id <plan-id>

package/plugins/planr/skills/planr-plan/SKILL.md

@@ -45,6 +45,7 @@ A product plan package must include:
 A build plan must include:
 
 - source plan;
+- a non-empty `criteria` frontmatter list whose entries contain only a stable `id` and `title`;
 - scope decision;
 - ownership target;
 - existing leverage;
@@ -53,6 +54,16 @@ A build plan must include:
 - verification;
 - acceptance criteria.
 
+Author criterion identity only in frontmatter, for example:
+
+```yaml
+criteria:
+  - id: criterion-api-health
+    title: API health is observable from the target service
+```
+
+Keep the `## Acceptance Criteria` section as readable narrative, never an identity source. Do not infer criterion IDs from prose or decide obligation completeness in this skill; `plan check`, explicit Evidence migration, and the canonical `app/proof` authority own those decisions.
+
 ## Route-Aware Tagging
 
 Before writing the task list, check whether the project declares model routing: `planr agents list --json`. If routes exist, their `work_type` selectors are the project's use-case vocabulary (e.g. `frontend`, `backend`, `design`) — and tagging is your job, not the user's; never ask a human to name work types.
@@ -72,4 +83,4 @@ Planning is complete only when `planr plan check <plan-id>` passes and the next
 
 When the map is built, linked, and tagged, end by naming the execution handoff explicitly — the user should never have to guess the next prompt: `Use $planr-loop on plan <build-plan-id>. Stop condition: all items closed with evidence, reviews complete, canonical Evidence coverage holds.` (On hosts with a /goal primitive, `$planr-goal` wraps the same loop for long-running autonomous runs.)
 
-`plan check` rejects empty scaffolds: build plans must have content in `## Scope Decision`, `## Verification`, and `## Acceptance Criteria`; product plans must have content in `## Problem`, `## Requirements`, and `## Success Criteria` of `PRODUCT_SPEC.md`. Write those sections before checking — do not pad them to satisfy the gate.
+`plan check` rejects empty scaffolds: build plans need a valid unique `criteria` frontmatter list plus content in `## Scope Decision`, `## Verification`, and `## Acceptance Criteria`; product plans must have content in `## Problem`, `## Requirements`, and `## Success Criteria` of `PRODUCT_SPEC.md`. Write those sections before checking — do not pad them to satisfy the gate.