planr 1.10.0-alpha.1 → 1.10.0-alpha.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +2 -2
- package/docs/ARCHITECTURE.md +1 -1
- package/docs/documentation/CONTRACT.md +1 -1
- package/docs/fixtures/mcp-contract.json +2 -0
- package/npm/native/darwin-arm64/planr +0 -0
- package/npm/native/darwin-arm64/planr-host-capability-validator +0 -0
- package/npm/native/darwin-x86_64/planr +0 -0
- package/npm/native/darwin-x86_64/planr-host-capability-validator +0 -0
- package/npm/native/linux-arm64/planr +0 -0
- package/npm/native/linux-arm64/planr-host-capability-validator +0 -0
- package/npm/native/linux-x86_64/planr +0 -0
- package/npm/native/linux-x86_64/planr-host-capability-validator +0 -0
- package/package.json +1 -1
- package/plugins/planr/.claude-plugin/plugin.json +1 -1
- package/plugins/planr/.codex-plugin/plugin.json +1 -1
- package/plugins/planr/skills/planr-goal/SKILL.md +3 -2
- package/plugins/planr/skills/planr-loop/SKILL.md +7 -6
- package/plugins/planr/skills/planr-loop/references/recovery-and-verification.md +5 -4
- package/plugins/planr/skills/planr-plan/SKILL.md +1 -1
- package/plugins/planr/skills/planr-status/SKILL.md +3 -1
- package/plugins/planr/skills/planr-verify-web/SKILL.md +7 -6
- package/plugins/planr/skills/planr-work/SKILL.md +6 -3
package/README.md
CHANGED
|
@@ -206,8 +206,8 @@ Use $planr-goal to prepare an autonomous goal for the weekly overview feature.
|
|
|
206
206
|
context (tag: goal-contract).
|
|
207
207
|
|
|
208
208
|
Goal: ship the weekly overview feature. DONE when every in-scope map item is closed
|
|
209
|
-
with
|
|
210
|
-
the feature working in the browser. Iteration budget: 10.
|
|
209
|
+
with implementation evidence, all reviews are closed complete, and canonical Evidence
|
|
210
|
+
coverage proves the feature working in the browser. Iteration budget: 10.
|
|
211
211
|
```
|
|
212
212
|
|
|
213
213
|
Mid-project work (a new feature, refactor, or fix on an existing project) works the same — it gets its own feature-scoped plan and extends the existing map. Both journeys with example prompts: [Prompt Recipes](https://planr.so/docs/agents/prompt-recipes). Coding agents inspect progress with the compact default `planr map show` or, preferably, `planr map show --json`. The tree preserves exact dependency vocabulary while marking satisfied edges as `blocks✓`; active `blocks` stay red. The boxed `planr map show --view diagram` renderer is exclusively for human supervision and uses neutral `then` routes once those dependencies are satisfied. Agents must not invoke it. Humans can add `--full` for complete status, title, worker, critical-lane, and pressure details. Interactive map output colors states automatically; `--no-color` and `NO_COLOR` keep it plain.
|
package/docs/ARCHITECTURE.md
CHANGED
|
@@ -34,7 +34,7 @@ Planr V1 is a single Rust binary with explicit module ownership. The crate stays
|
|
|
34
34
|
- `src/app/review_workspace.rs`: local review workspace boundary. Owns the browser review HTML, workspace data projection, and privacy-minimized Git diff evidence.
|
|
35
35
|
- `src/app/surfaces.rs`: non-CLI runtime surfaces. Owns trace, scrub, artifact, event, debug, export, and import command handlers.
|
|
36
36
|
- `src/app/inspection.rs`: local inspection helpers. Owns debug bundles, context/link snapshots, pick context, secret scans, export value assembly, run recording, search results, and Planr-directory import parsing.
|
|
37
|
-
- `src/app/audit.rs`: goal contract audit boundary. Owns the clause-by-clause `plan audit` verdict (items settled, reviews complete, approvals clear,
|
|
37
|
+
- `src/app/audit.rs`: goal contract audit boundary. Owns the clause-by-clause `plan audit` verdict (items settled, reviews complete, approvals clear, canonical Evidence coverage) and its human rendering. Claim-only verification logs remain isolated to frozen pre-Evidence compatibility.
|
|
38
38
|
- `src/app/application.rs`: shared surface-mutation boundary. Owns the approval request/approve/deny, context, log, artifact, and close mutations reused verbatim by CLI, MCP, and HTTP handlers so the three surfaces cannot drift.
|
|
39
39
|
- `src/app/repository/`: focused data-access submodules (`item.rs`, `plan.rs`, `project.rs`, `link.rs`, `context.rs`, `evidence.rs`, `search.rs`) split out of `src/app/repository.rs` by entity ownership.
|
|
40
40
|
- `src/model.rs`: JSON-facing data transfer types and typed vocabulary. Owns serializable Planr DTOs plus the `ItemStatus`, `WorkType`, `LinkKind`, and `ApprovalStatus` enums with their parsing and display behavior, used by CLI JSON, MCP, HTTP, storage rows, and tests.
|
|
@@ -34,7 +34,7 @@ Use these terms exactly. Prefer the lowercase form in prose unless it starts a s
|
|
|
34
34
|
| pick | An atomic lease of one ready item to one worker. | assignment, claim unless explaining the concept |
|
|
35
35
|
| worker | The identity holding the active pick. | agent when ownership specifically matters |
|
|
36
36
|
| log | Durable evidence or progress attached to an item. | transcript |
|
|
37
|
-
| verification log | A log
|
|
37
|
+
| verification log | A claim-only narrative log for a live oracle; frozen pre-Evidence compatibility may inspect it. | binding Evidence receipt or coverage verdict |
|
|
38
38
|
| review | A graph gate that checks evidence and can create fix/follow-up work. | approval; approvals are a separate human gate |
|
|
39
39
|
| approval | An explicit requested/approved/denied human decision on an item. | review |
|
|
40
40
|
| context | A durable discovery, decision, constraint, or goal contract. | memory |
|
|
@@ -47,6 +47,7 @@
|
|
|
47
47
|
"planr_evidence_obligation_list",
|
|
48
48
|
"planr_evidence_obligation_show",
|
|
49
49
|
"planr_evidence_migrate",
|
|
50
|
+
"planr_evidence_rebind",
|
|
50
51
|
"planr_evidence_classifications",
|
|
51
52
|
"planr_evidence_capability_list",
|
|
52
53
|
"planr_evidence_capability_show",
|
|
@@ -58,6 +59,7 @@
|
|
|
58
59
|
"planr_evidence_receipts",
|
|
59
60
|
"planr_evidence_coverage",
|
|
60
61
|
"planr_evidence_explain",
|
|
62
|
+
"planr_evidence_readiness",
|
|
61
63
|
"planr_eval_suite_check",
|
|
62
64
|
"planr_eval_run",
|
|
63
65
|
"planr_eval_show",
|
|
Binary file
|
|
Binary file
|
|
Binary file
|
|
Binary file
|
|
Binary file
|
|
Binary file
|
|
Binary file
|
|
Binary file
|
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "planr",
|
|
3
3
|
"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.",
|
|
4
|
-
"version": "1.10.0-alpha.
|
|
4
|
+
"version": "1.10.0-alpha.2",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "instructa"
|
|
7
7
|
},
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "planr",
|
|
3
|
-
"version": "1.10.0-alpha.
|
|
3
|
+
"version": "1.10.0-alpha.2",
|
|
4
4
|
"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.",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "instructa",
|
|
@@ -36,10 +36,11 @@ When the repository provides a versioned verification policy and source-bound re
|
|
|
36
36
|
|
|
37
37
|
## Durable Contract
|
|
38
38
|
|
|
39
|
-
Store one contract per plan:
|
|
39
|
+
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:
|
|
40
40
|
|
|
41
41
|
```bash
|
|
42
|
-
planr
|
|
42
|
+
planr evidence readiness --scope plan --id <plan-id>
|
|
43
|
+
planr context add "GOAL CONTRACT <plan-id>: DONE when every in-scope item is closed with implementation evidence, all reviews are complete, approvals are clear, and canonical Evidence coverage proves <goal oracle>. Iteration budget: 10." --tag goal-contract
|
|
43
44
|
```
|
|
44
45
|
|
|
45
46
|
Never weaken it mid-run. Workers use `planr pick --plan <plan-id>`; termination uses `planr plan audit <plan-id> --json`. Reviews are required only where they add signal; evidence-backed setup work may close directly. Where deployment is in scope, the contract must retain human deployment approval and a bounded live oracle against the deployed result.
|
|
@@ -18,11 +18,12 @@ At the start of the host thread that drives an active goal, run `planr stop acti
|
|
|
18
18
|
Each iteration follows the Planr stage protocols:
|
|
19
19
|
|
|
20
20
|
1. `planr plan audit <plan-id> --json`; `holds: true` exits.
|
|
21
|
-
2.
|
|
22
|
-
3.
|
|
23
|
-
4.
|
|
24
|
-
5.
|
|
25
|
-
6.
|
|
21
|
+
2. For a binding Evidence plan, run `planr evidence readiness --scope plan --id <plan-id>`. Repair typed schema/capability/runtime gaps before product work. Use `planr evidence rebind --input <file>` and the returned preview digest only when an immutable adapter/obligation binding must be corrected without changing acceptance semantics.
|
|
22
|
+
3. Use `$planr-plan` or `$planr-task-graph` only when scope or graph structure is missing.
|
|
23
|
+
4. Dispatch `$planr-work` for exactly one ready item scoped to `<plan-id>`; makers must use `planr pick --work-type code --plan <plan-id>`, never an unscoped pick, select the repository verification policy, and finish implementation with `planr done <item-id> ... --review`.
|
|
24
|
+
5. Run the configured target-platform method with `planr evidence run --input <run-file>`, then evaluate `planr evidence coverage --scope criterion --id <criterion-id>` and inspect gaps with `planr evidence explain ...`. Deployment still requires prior human approval and a bounded live oracle. Narrative logs never substitute for binding receipts.
|
|
25
|
+
6. Dispatch `$planr-review`; the checker independently inspects the diff and validates the exact-source receipt, replaying only cheap, missing, failing, or explicitly high-risk evidence. Findings create fix work, while `complete --close-target` settles the target.
|
|
26
|
+
7. Repeat from audit.
|
|
26
27
|
|
|
27
28
|
One picked item per iteration. A small coherent change stays one implementation item with one signal-bearing review; do not create a new review boundary for every mechanical stage or for an already-reviewed successful live smoke. Use plain `done` only for low-signal setup/inspection work. Maker and checker stay separate when the host supports another agent; a maker never self-reviews when an independent checker is available, and never manufactures independence by changing worker identity. The reviewer must exercise independent judgment even when it relies on a green receipt rather than replaying an expensive gate. A worker may use `done --next`, which never returns its own review.
|
|
28
29
|
|
|
@@ -45,7 +46,7 @@ For generated Codex roles: The `spawn_agent` tool call itself must include `agen
|
|
|
45
46
|
|
|
46
47
|
“Done” means the feature ran. For web dispatch `$planr-verify-web`; for CLI execute the built binary; for API use real requests; for iOS launch the simulator. Log the replayable command. A passing bounded live oracle is evidence for the existing review boundary, not a reason to start another full reviewer replay. If the capability is missing, record a blocker context, request approval, and pause—never fake proof.
|
|
47
48
|
|
|
48
|
-
Recovery starts in a fresh session with audit, map state, the stored contract, and the next scoped pick. Read [recovery and platform details](references/recovery-and-verification.md) only when that branch is active.
|
|
49
|
+
Recovery starts in a fresh session with audit, map state, Evidence readiness/explain, the stored contract, and the next scoped pick. A terminal unchanged Stop gap remains terminal; use `planr stop resume --plan <plan-id>` only after an explicit operator decision to reopen its bounded continuation window. Read [recovery and platform details](references/recovery-and-verification.md) only when that branch is active.
|
|
49
50
|
|
|
50
51
|
## Hard Rules
|
|
51
52
|
|
|
@@ -16,9 +16,10 @@ Use `planr pick stale --older-than-seconds 900` before releasing abandoned owner
|
|
|
16
16
|
Verification:
|
|
17
17
|
|
|
18
18
|
```bash
|
|
19
|
-
planr
|
|
20
|
-
|
|
21
|
-
|
|
19
|
+
planr evidence readiness --scope criterion --id <criterion-id>
|
|
20
|
+
planr evidence run --input <run-file>
|
|
21
|
+
planr evidence coverage --scope criterion --id <criterion-id>
|
|
22
|
+
planr evidence explain --scope criterion --id <criterion-id>
|
|
22
23
|
```
|
|
23
24
|
|
|
24
|
-
Use browser automation for web, the built binary for CLI, real requests for API/backend, and simulator launch plus exercised flow for iOS. If tooling is unavailable,
|
|
25
|
+
Use a capability whose declared observations cover the criterion: browser automation for rendered web behavior, the built binary for CLI, real requests for API/backend, and simulator launch plus exercised flow for iOS. If tooling is unavailable, preserve the typed blocker, request approval when appropriate, and pause. Do not replace it with a weaker method that observes different facts.
|
|
@@ -68,6 +68,6 @@ Match by the task's actual work (UI/components/styling -> a `frontend` route, AP
|
|
|
68
68
|
|
|
69
69
|
Planning is complete only when `planr plan check <plan-id>` passes and the next command is clear: split further, build map, or ask the user for a blocking decision.
|
|
70
70
|
|
|
71
|
-
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,
|
|
71
|
+
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.)
|
|
72
72
|
|
|
73
73
|
`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.
|
|
@@ -34,9 +34,11 @@ When a loop or `/goal` run asks whether its stop condition holds, use the one-ca
|
|
|
34
34
|
|
|
35
35
|
```bash
|
|
36
36
|
planr plan audit <plan-id> --json
|
|
37
|
+
planr evidence readiness --scope plan --id <plan-id>
|
|
38
|
+
planr evidence explain --scope plan --id <plan-id>
|
|
37
39
|
```
|
|
38
40
|
|
|
39
|
-
|
|
41
|
+
Audit answers `holds: true/false` from settled items, reviews, approvals, and canonical Evidence coverage. Readiness reports configuration/runtime blockers before execution; explain reports exact receipt applicability and gaps. Report `contract holds` or `contract open` plus the exact unmet clauses straight from these outputs. Use `planr search "GOAL CONTRACT"` only to read the contract text itself.
|
|
40
42
|
|
|
41
43
|
## Verdicts
|
|
42
44
|
|
|
@@ -41,15 +41,16 @@ Detect a running dev server before anything else and use it. Never start a secon
|
|
|
41
41
|
|
|
42
42
|
Exercise the flow the item changed — not the homepage. Interact, assert on rendered output, capture a screenshot when the tier supports it.
|
|
43
43
|
|
|
44
|
-
|
|
44
|
+
Use the repository's configured web capability to create trusted Evidence, then evaluate coverage:
|
|
45
45
|
|
|
46
46
|
```bash
|
|
47
|
-
planr
|
|
48
|
-
|
|
49
|
-
|
|
47
|
+
planr evidence readiness --scope criterion --id <criterion-id>
|
|
48
|
+
planr evidence run --input <run-file-for-the-configured-web-method>
|
|
49
|
+
planr evidence coverage --scope criterion --id <criterion-id>
|
|
50
|
+
planr evidence explain --scope criterion --id <criterion-id>
|
|
50
51
|
```
|
|
51
52
|
|
|
52
|
-
|
|
53
|
+
The observation contract decides what must be proved. Native Browser, CDP, Playwright, Computer Use, and HTTP probes are configurable methods, not a universal ranking. HTTP can fully prove an HTTP criterion but cannot satisfy rendered interaction, persistence, accessibility, console, or visual observations it never captured.
|
|
53
54
|
|
|
54
55
|
Attach screenshots or traces as artifacts on the item:
|
|
55
56
|
|
|
@@ -58,7 +59,7 @@ planr artifact add "verify-web screenshot" --item <item-id> --path <screenshot-p
|
|
|
58
59
|
planr artifact add "verify-web recording" --item <item-id> --path <recording.mp4> --kind video
|
|
59
60
|
```
|
|
60
61
|
|
|
61
|
-
The replay
|
|
62
|
+
The replay contract and trusted method identity are mandatory. The reviewer validates the receipt and reruns it only when it is cheap, missing, failing, or explicitly high-risk; a verification that cannot be replayed when needed is not evidence. A successful bounded live smoke joins the existing coherent review boundary and does not automatically trigger another full build or reviewer replay.
|
|
62
63
|
|
|
63
64
|
For a deployment oracle, require an approved deployment decision before the deploy begins. After deployment, keep the live check bounded to the changed routes, content, or interaction and record the deployed source/receipt identity in the summary.
|
|
64
65
|
|
|
@@ -33,13 +33,16 @@ Record the receipt path, digest, source revision, selected profile/gates, and co
|
|
|
33
33
|
|
|
34
34
|
Put build/serve commands in `--cmd` and test runs in `--tests` — both are recorded as evidence. When the pick packet carries a `routing` block, also report the registry profile you actually ran on: add `--profile <profile-id>` to `done`/`log add`, or export `PLANR_PROFILE` once per session. It is part of the evidence — a mismatch with the declared route is advisory (never blocks the close) and surfaces in `planr trace item` so silent host overrides get caught. Include the decisive output line in `--summary` (e.g. "12 tests passed", "GET /videos returned 3 entries"): reviewers see your recorded command strings, not your terminal, so the summary must carry what you observed, not just what you ran. Single-quote `--files` values that contain `$` (route files like `watch.$videoId.tsx`), or the shell expands them before planr sees them. `done --review` writes the completion log, requests the review, and moves the item to `in_review` (you keep ownership; it is waiting on the gate, not abandoned) — the response names the target's new status and the plan-scoped reviewer pick command; add `--next` to pick the following item in the same call. Without `--review` it closes the item directly (only for items that need no review gate). Running `done` on a ready item you never picked adopts it: the lease is written retroactively under your worker id so the review always has a maker. The response reports what your settlement `unlocked`, echoes the item's post condition, and hints when downstream work depends on an item closed without command/test evidence.
|
|
35
35
|
|
|
36
|
-
|
|
36
|
+
Binding verification (browser flow, executed binary, real requests) must produce a trusted Evidence receipt and coverage verdict:
|
|
37
37
|
|
|
38
38
|
```bash
|
|
39
|
-
planr
|
|
39
|
+
planr evidence readiness --scope criterion --id <criterion-id>
|
|
40
|
+
planr evidence run --input <run-file>
|
|
41
|
+
planr evidence coverage --scope criterion --id <criterion-id>
|
|
42
|
+
planr evidence explain --scope criterion --id <criterion-id>
|
|
40
43
|
```
|
|
41
44
|
|
|
42
|
-
The
|
|
45
|
+
The configured method must be copy-paste replayable: a real shell command, host capture, or committed verifier, never prose such as "start server; curl /; check stats". Reviewers validate the exact-source receipt and selectively replay cheap, missing, failing, or explicitly high-risk evidence. `planr log add` remains useful for narrative handoffs, but a free-form `kind=verification` claim has no binding closure authority.
|
|
43
46
|
|
|
44
47
|
Log persistent evidence, not transient noise: a failure you immediately fixed belongs in the final log's narrative, not as a standalone failure log. Only record a failure separately when it blocks the item.
|
|
45
48
|
|