planr 0.0.1 → 1.1.16
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/LICENSE.md +21 -0
- package/README.md +150 -0
- package/docs/ARCHITECTURE.md +75 -0
- package/docs/CI.md +54 -0
- package/docs/CLAUDE_CODE.md +33 -0
- package/docs/CLI_REFERENCE.md +126 -0
- package/docs/CODEX.md +48 -0
- package/docs/CURSOR.md +30 -0
- package/docs/GOALS.md +155 -0
- package/docs/HANDOFFS_AND_STORIES.md +121 -0
- package/docs/IMPORT.md +21 -0
- package/docs/INSTALL.md +113 -0
- package/docs/MCP_CONTRACT.md +70 -0
- package/docs/MCP_GUIDE.md +40 -0
- package/docs/NPM.md +40 -0
- package/docs/OPERATING_MODEL.md +250 -0
- package/docs/RELEASE.md +140 -0
- package/docs/SECURITY.md +8 -0
- package/docs/SKILLS.md +278 -0
- package/docs/TASK_GRAPH_MODEL.md +222 -0
- package/docs/TESTING.md +87 -0
- package/docs/TROUBLESHOOTING.md +26 -0
- package/docs/fixtures/mcp-contract.json +92 -0
- package/docs/planr-spec/ADRS.md +160 -0
- package/docs/planr-spec/AI_SPEC.md +138 -0
- package/docs/planr-spec/ANALYTICS_OBSERVABILITY_SPEC.md +124 -0
- package/docs/planr-spec/API_AND_DATA_MODEL.md +517 -0
- package/docs/planr-spec/BACKEND_IMPLEMENTATION_SPEC.md +178 -0
- package/docs/planr-spec/CLIENT_IMPLEMENTATION_SPEC.md +119 -0
- package/docs/planr-spec/DESIGN_SYSTEM_SPEC.md +102 -0
- package/docs/planr-spec/PRODUCT_SPEC.md +193 -0
- package/docs/planr-spec/QA_ACCEPTANCE_TESTS.md +146 -0
- package/docs/planr-spec/README.md +67 -0
- package/docs/planr-spec/REFERENCES.md +29 -0
- package/docs/planr-spec/RELEASE_READINESS.md +95 -0
- package/docs/planr-spec/SAFETY_PRIVACY_SECURITY.md +169 -0
- package/docs/planr-spec/TASKS.md +932 -0
- package/docs/planr-spec/TECH_ARCHITECTURE.md +143 -0
- package/docs/planr-spec/UX_FLOWS.md +235 -0
- package/docs/planr-spec/V1_1_DIFFERENTIATION_CONTRACT.md +177 -0
- package/docs/planr-spec.zip +0 -0
- package/npm/bin/planr.js +54 -0
- package/npm/native/darwin-arm64/planr +0 -0
- package/npm/native/darwin-x86_64/planr +0 -0
- package/npm/native/linux-arm64/planr +0 -0
- package/npm/native/linux-x86_64/planr +0 -0
- package/package.json +27 -8
- package/plugins/planr/.claude-plugin/plugin.json +11 -0
- package/plugins/planr/.codex-plugin/plugin.json +25 -0
- package/plugins/planr/agents/planr-reviewer.md +12 -0
- package/plugins/planr/agents/planr-worker.md +10 -0
- package/plugins/planr/skills/planr/SKILL.md +52 -0
- package/plugins/planr/skills/planr-goal/SKILL.md +69 -0
- package/plugins/planr/skills/planr-loop/SKILL.md +114 -0
- package/plugins/planr/skills/planr-loop/agents/planr-reviewer.toml +17 -0
- package/plugins/planr/skills/planr-loop/agents/planr-worker.toml +14 -0
- package/plugins/planr/skills/planr-plan/SKILL.md +58 -0
- package/plugins/planr/skills/planr-review/SKILL.md +51 -0
- package/plugins/planr/skills/planr-status/SKILL.md +50 -0
- package/plugins/planr/skills/planr-summary/SKILL.md +28 -0
- package/plugins/planr/skills/planr-task-graph/SKILL.md +228 -0
- package/plugins/planr/skills/planr-verify-web/SKILL.md +76 -0
- package/plugins/planr/skills/planr-work/SKILL.md +68 -0
package/LICENSE.md
ADDED
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 regenrek
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|
package/README.md
ADDED
|
@@ -0,0 +1,150 @@
|
|
|
1
|
+
# Planr
|
|
2
|
+
|
|
3
|
+

|
|
4
|
+
|
|
5
|
+
Planr is a local-first planning and execution coordination tool for coding agents. It combines reviewable Markdown plans with a dependency-aware work map so Codex, Claude Code, Cursor, generic MCP clients, and human operators can drive the same work safely — from idea to verified completion.
|
|
6
|
+
|
|
7
|
+
```text
|
|
8
|
+
idea -> product plan -> build plan -> map -> pick -> log -> review/evidence -> close
|
|
9
|
+
```
|
|
10
|
+
|
|
11
|
+
## Why Planr
|
|
12
|
+
|
|
13
|
+

|
|
14
|
+
|
|
15
|
+
Flat todo lists break down the moment real work has structure. Planr models work as a dependency graph because that is what work actually is:
|
|
16
|
+
|
|
17
|
+
- **Readiness is computed, not guessed.** An item becomes `ready` only when its blockers are closed; `planr pick` returns work that is actually startable.
|
|
18
|
+
- **Parallel agents need atomic claims.** Picks are atomic claims enforced by the database — one item, one owner, no checklist races.
|
|
19
|
+
- **"Done" is gated, not asserted.** Closure requires log-backed evidence (files, commands, tests) and open reviews block their target.
|
|
20
|
+
- **State survives sessions.** Markdown plans hold scope and acceptance criteria; the SQLite graph holds live status across handoffs, restarts, and agent switches.
|
|
21
|
+
- **Failure is structured.** Stale picks, timeouts, and retries are detectable and recoverable (`planr recover sweep`).
|
|
22
|
+
|
|
23
|
+
Three layers make that work: **Plans** (reviewable Markdown packages), the **Map** (live dependency graph with picks, reviews, logs), and **Agent loops** (skills, CLI, and MCP workflows for every major coding agent). Full model: [Task Graph Model](docs/TASK_GRAPH_MODEL.md) and [Operating Model](docs/OPERATING_MODEL.md).
|
|
24
|
+
|
|
25
|
+
## Install
|
|
26
|
+
|
|
27
|
+
```bash
|
|
28
|
+
brew install instructa/tap/planr
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
Or via npm (ships platform-native binaries, no toolchain needed):
|
|
32
|
+
|
|
33
|
+
```bash
|
|
34
|
+
npm install -g planr
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
Or with the release installer:
|
|
38
|
+
|
|
39
|
+
```bash
|
|
40
|
+
curl -fsSL https://raw.githubusercontent.com/instructa/planr/main/scripts/install.sh | sh
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
Then initialize a project (also provisions the worker/reviewer subagent roles for your client):
|
|
44
|
+
|
|
45
|
+
```bash
|
|
46
|
+
planr project init "My Product" --client all
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
Manual downloads, from-source builds, and client wiring details: [Install Guide](docs/INSTALL.md).
|
|
50
|
+
|
|
51
|
+
## Install The Plugin (Skills)
|
|
52
|
+
|
|
53
|
+
The plugin under `plugins/planr` carries the nine Planr skills plus the `planr-worker` and `planr-reviewer` subagent roles. The `planr` CLI (above) is required separately.
|
|
54
|
+
|
|
55
|
+
<a id="install-plugin-codex"></a>
|
|
56
|
+
<details>
|
|
57
|
+
<summary><strong>Codex</strong></summary>
|
|
58
|
+
|
|
59
|
+
```bash
|
|
60
|
+
codex plugin marketplace add instructa/planr
|
|
61
|
+
codex plugin add planr@planr
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
</details>
|
|
65
|
+
|
|
66
|
+
<a id="install-plugin-claude-code"></a>
|
|
67
|
+
<details>
|
|
68
|
+
<summary><strong>Claude Code</strong></summary>
|
|
69
|
+
|
|
70
|
+
Inside a Claude Code session:
|
|
71
|
+
|
|
72
|
+
```text
|
|
73
|
+
/plugin marketplace add instructa/planr
|
|
74
|
+
/plugin install planr@planr
|
|
75
|
+
```
|
|
76
|
+
|
|
77
|
+
Restart Claude Code afterwards. Skills are namespaced (`/planr:planr`, `/planr:planr-loop`), and the plugin registers the `planr-worker` and `planr-reviewer` subagents automatically.
|
|
78
|
+
|
|
79
|
+
</details>
|
|
80
|
+
|
|
81
|
+
<a id="install-plugin-cursor"></a>
|
|
82
|
+
<details>
|
|
83
|
+
<summary><strong>Cursor</strong></summary>
|
|
84
|
+
|
|
85
|
+
Pending marketplace review. Until the plugin is listed, wire Planr in via MCP and the CLI prompt:
|
|
86
|
+
|
|
87
|
+
```bash
|
|
88
|
+
planr install cursor # writes .cursor/mcp.json
|
|
89
|
+
planr prompt cli --client cursor
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
</details>
|
|
93
|
+
|
|
94
|
+
<a id="install-plugin-opencode"></a>
|
|
95
|
+
<details>
|
|
96
|
+
<summary><strong>opencode</strong></summary>
|
|
97
|
+
|
|
98
|
+
No plugin yet. Use Planr as an MCP server and paste the CLI prompt into your agent instructions:
|
|
99
|
+
|
|
100
|
+
```bash
|
|
101
|
+
planr mcp # stdio MCP server
|
|
102
|
+
planr prompt cli
|
|
103
|
+
```
|
|
104
|
+
|
|
105
|
+
</details>
|
|
106
|
+
|
|
107
|
+
## Tell Your Agent
|
|
108
|
+
|
|
109
|
+
Two skills drive everything. `$planr` routes any request to the right stage skill from live map state; `$planr-loop` drives one feature through work, live verification, and independent review until the map is clean.
|
|
110
|
+
|
|
111
|
+
Start a new product from an idea:
|
|
112
|
+
|
|
113
|
+
```text
|
|
114
|
+
Use $planr.
|
|
115
|
+
|
|
116
|
+
Create a production-ready Habit Tracker web app plan. Create the product plan,
|
|
117
|
+
split an MVP build plan, check it, then build the Planr map. Do not implement yet.
|
|
118
|
+
```
|
|
119
|
+
|
|
120
|
+
Ship one feature autonomously until verified:
|
|
121
|
+
|
|
122
|
+
```text
|
|
123
|
+
Use $planr-loop.
|
|
124
|
+
|
|
125
|
+
Goal: ship the weekly overview feature. DONE when every in-scope map item is closed
|
|
126
|
+
with log evidence, all reviews are closed complete, and a live verification log shows
|
|
127
|
+
the feature working in the browser. Iteration budget: 10.
|
|
128
|
+
```
|
|
129
|
+
|
|
130
|
+
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: [Two Journeys](docs/SKILLS.md#two-journeys-new-project-vs-existing-project). Watch progress anytime with `planr map show`.
|
|
131
|
+
|
|
132
|
+
## Docs
|
|
133
|
+
|
|
134
|
+
- [Install](docs/INSTALL.md)
|
|
135
|
+
- [Skills](docs/SKILLS.md)
|
|
136
|
+
- [Long-Running Goals](docs/GOALS.md)
|
|
137
|
+
- [CLI Reference](docs/CLI_REFERENCE.md)
|
|
138
|
+
- [MCP Guide](docs/MCP_GUIDE.md)
|
|
139
|
+
- [Codex](docs/CODEX.md) · [Claude Code](docs/CLAUDE_CODE.md) · [Cursor](docs/CURSOR.md)
|
|
140
|
+
- [Operating Model](docs/OPERATING_MODEL.md)
|
|
141
|
+
- [Task Graph Model](docs/TASK_GRAPH_MODEL.md)
|
|
142
|
+
- [Architecture](docs/ARCHITECTURE.md)
|
|
143
|
+
- [Testing](docs/TESTING.md)
|
|
144
|
+
- [Troubleshooting](docs/TROUBLESHOOTING.md)
|
|
145
|
+
- [Specification Package](docs/planr-spec/README.md)
|
|
146
|
+
- More: [Changelog](CHANGELOG.md), [Import](docs/IMPORT.md), [Security](docs/SECURITY.md), [Handoffs And Stories](docs/HANDOFFS_AND_STORIES.md), [npm Package](docs/NPM.md)
|
|
147
|
+
|
|
148
|
+
## License
|
|
149
|
+
|
|
150
|
+
MIT. See `LICENSE.md`.
|
|
@@ -0,0 +1,75 @@
|
|
|
1
|
+
# Planr Architecture
|
|
2
|
+
|
|
3
|
+
Planr V1 is a single Rust binary with explicit module ownership. The crate stays small enough that a Cargo workspace would add more process overhead than value today, and there is only one deployable: the `planr` CLI. The source tree is split by ownership boundary inside that crate instead of using a premature workspace.
|
|
4
|
+
|
|
5
|
+
## Repository Layout
|
|
6
|
+
|
|
7
|
+
- `src/`: the Rust CLI (module ownership below).
|
|
8
|
+
- `tests/e2e.rs`: real CLI, MCP, HTTP, import, review-gate, run-log, and concurrent-pick tests.
|
|
9
|
+
- `plugins/planr/`: the installable plugin payload — all nine skills, the worker and reviewer subagent roles, and the per-host plugin manifests.
|
|
10
|
+
- `.agents/plugins/marketplace.json`, `.claude-plugin/marketplace.json`: marketplace manifests pointing Codex and Claude Code at `plugins/planr`.
|
|
11
|
+
- `docs/`: user and contributor guides; `docs/planr-spec/` is the production specification package for Planr V1.
|
|
12
|
+
- `examples/real-world-flow.md`: executable real-world operator flow.
|
|
13
|
+
- `scripts/`: installer and release packaging scripts.
|
|
14
|
+
- `npm/`: the npm wrapper package.
|
|
15
|
+
|
|
16
|
+
## Module Ownership
|
|
17
|
+
|
|
18
|
+
- `src/main.rs`: process composition root. Owns top-level module wiring, process startup, database opening, error printing, and dispatch into `App`.
|
|
19
|
+
- `src/cli.rs`: CLI contract boundary. Owns `clap` command definitions, option parsing types, value enums, and command DTOs used by app dispatch.
|
|
20
|
+
- `src/app/mod.rs`: application composition boundary. Owns the `App` runtime state, top-level dispatch, shared app-local row helpers, and app submodule wiring.
|
|
21
|
+
- `src/app/commands.rs`: CLI use-case orchestration. Owns project, plan, map, item, link, pick, approval, log, close, review, context, search, doctor, and install command handlers.
|
|
22
|
+
- `src/app/flow.rs`: compound work-flow boundary. Owns evidence log writing (with heartbeat folding), the close transition core, review-request creation, the pick work packet, and the `done` command that chains them for CLI, HTTP, and MCP surfaces.
|
|
23
|
+
- `src/app/git_review.rs`: Git and PR review evidence boundary. Owns worktree detection, scoped changed-file provenance, PR URL context, and dirty-worktree safety projections.
|
|
24
|
+
- `src/app/mcp.rs`: MCP stdio boundary. Owns MCP protocol request routing, tool calls, resource reads, and prompt responses.
|
|
25
|
+
- `src/app/packages.rs`: package import/export boundary. Owns reusable JSON templates, preview-before-import, review artifact package import, and local-first encrypted bundle metadata.
|
|
26
|
+
- `src/app/http.rs`: localhost HTTP/SSE boundary. Owns HTTP request parsing, routes, SSE stream output, and HTTP response mapping.
|
|
27
|
+
- `src/app/repository.rs`: application data access helpers. Owns Planr query/update helpers over projects, plans, graph items, links, runs, logs, artifacts, events, approvals, search, and map projections.
|
|
28
|
+
- `src/app/lease.rs`: worker lease ownership. Owns the single pick query (`PickFilter`: exclude, work type, plan scope), worker ownership checks, runtime heartbeat/progress/pause state, and stale-pick detection.
|
|
29
|
+
- `src/app/review.rs`: review-gate application logic. Owns review annotations, feedback ingestion, evidence artifacts, review closure, and review target lookup.
|
|
30
|
+
- `src/app/recovery.rs`: recovery automation logic. Owns item retry policy configuration, task conditions, stale/timed-out sweeps, retry scheduling, and recovery result projections.
|
|
31
|
+
- `src/app/review_workspace.rs`: local review workspace boundary. Owns the browser review HTML, workspace data projection, and privacy-minimized Git diff evidence.
|
|
32
|
+
- `src/app/surfaces.rs`: non-CLI runtime surfaces. Owns trace, scrub, artifact, event, debug, export, and import command handlers.
|
|
33
|
+
- `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.
|
|
34
|
+
- `src/app/audit.rs`: goal contract audit boundary. Owns the clause-by-clause `plan audit` verdict (items settled, reviews complete, approvals clear, verification logged) and its human rendering.
|
|
35
|
+
- `src/model.rs`: JSON-facing data transfer types. Owns serializable Planr DTOs used by CLI JSON, MCP, HTTP, and tests.
|
|
36
|
+
- `src/storage/mod.rs`: SQLite connection boundary. Owns default database path, connection setup, pragma configuration, and storage submodule exports.
|
|
37
|
+
- `src/storage/schema.rs`: SQLite schema boundary. Owns DDL, additive schema upgrade helpers, and schema version recording.
|
|
38
|
+
- `src/storage/rows.rs`: SQLite row mapping boundary. Owns row-to-DTO and row-to-JSON mapping functions.
|
|
39
|
+
- `src/planpack.rs`: Markdown package generation. Owns project context templates and product/build plan file templates.
|
|
40
|
+
- `src/integrations.rs`: agent-client integration descriptors. Owns Codex, Claude Code, Cursor, and MCP install metadata.
|
|
41
|
+
- `src/util.rs`: small CLI-boundary utilities. Owns ids, timestamps, path helpers, output formatting, and safe file writes.
|
|
42
|
+
|
|
43
|
+
## Boundary Rules
|
|
44
|
+
|
|
45
|
+
- Command parsing belongs in `src/cli.rs`; process startup belongs in `src/main.rs`; command execution belongs under `src/app/`.
|
|
46
|
+
- `src/main.rs` must stay small enough to be only a composition root. It must not own product use cases.
|
|
47
|
+
- `src/app/mod.rs` must stay small enough to wire runtime state and dispatch. It must not absorb app submodule behavior.
|
|
48
|
+
- SQLite schema belongs in `src/storage/schema.rs`; row mapping belongs in `src/storage/rows.rs`; app data access helpers belong in `src/app/repository.rs`.
|
|
49
|
+
- Markdown templates belong in `planpack.rs`; command handlers should request generated file sets instead of embedding large template bodies.
|
|
50
|
+
- Agent install metadata belongs in `integrations.rs`; client-specific strings should not drift across command handlers and docs.
|
|
51
|
+
- DTO changes belong in `model.rs`; JSON response shapes should reuse those DTOs before adding ad hoc maps.
|
|
52
|
+
- Utility code must stay narrow. If a helper starts owning product behavior, move it to the owning module instead of growing `util.rs`.
|
|
53
|
+
- Do not add catch-all `common`, `shared`, or broad utility modules. New modules must name a durable ownership boundary.
|
|
54
|
+
|
|
55
|
+
## Single-Crate Decision
|
|
56
|
+
|
|
57
|
+
Planr remains a single crate for V1 because:
|
|
58
|
+
|
|
59
|
+
- there is one deployable binary and no separate service or reusable library boundary;
|
|
60
|
+
- the current behavior contract is tighter when CLI, MCP, HTTP, storage, and docs ship together;
|
|
61
|
+
- module-level ownership now gives the needed architecture separation without duplicating Cargo settings or release packaging;
|
|
62
|
+
- npm, release, and external consumer tests assume one native binary named `planr`.
|
|
63
|
+
|
|
64
|
+
A Cargo workspace should be introduced only after a concrete deployable, reuse, compilation, or team ownership boundary exists and package/release scripts are updated in the same change.
|
|
65
|
+
|
|
66
|
+
## Future Extract Points
|
|
67
|
+
|
|
68
|
+
If Planr grows past the V1 binary shape, the first clean extraction path is:
|
|
69
|
+
|
|
70
|
+
- `planr-core`: `model.rs`, graph invariants, plan package contracts, and pure use-case types.
|
|
71
|
+
- `planr-storage`: `src/storage/*`, storage repositories, schema upgrades, and import/export packages.
|
|
72
|
+
- `planr-cli`: `src/cli.rs`, human output, and install helpers.
|
|
73
|
+
- `planr-server`: `src/app/http.rs`, `src/app/mcp.rs`, and runtime server adapters.
|
|
74
|
+
|
|
75
|
+
Do not extract those crates until a real reuse, compile-time, or ownership boundary exists.
|
package/docs/CI.md
ADDED
|
@@ -0,0 +1,54 @@
|
|
|
1
|
+
# CI
|
|
2
|
+
|
|
3
|
+
Planr CI is defined in `.github/workflows/ci.yml` and `.github/workflows/security.yml`.
|
|
4
|
+
|
|
5
|
+
## Required Gates
|
|
6
|
+
|
|
7
|
+
The main CI workflow runs:
|
|
8
|
+
|
|
9
|
+
```bash
|
|
10
|
+
cargo fmt --check
|
|
11
|
+
cargo clippy --all-targets -- -D warnings
|
|
12
|
+
cargo test
|
|
13
|
+
shellcheck scripts/*.sh
|
|
14
|
+
cargo build --release
|
|
15
|
+
npm pack --dry-run
|
|
16
|
+
node npm/bin/planr.js --version
|
|
17
|
+
cargo audit --deny warnings
|
|
18
|
+
```
|
|
19
|
+
|
|
20
|
+
The security workflow runs a GitHub Actions security scan with pinned `zizmor`.
|
|
21
|
+
|
|
22
|
+
## Local Reproduction
|
|
23
|
+
|
|
24
|
+
Run the full local gate:
|
|
25
|
+
|
|
26
|
+
```bash
|
|
27
|
+
scripts/ci-local.sh
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
`scripts/ci-local.sh` also runs the external consumer E2E project when `/Users/kregenrek/projects/planr-test` exists:
|
|
31
|
+
|
|
32
|
+
```bash
|
|
33
|
+
cd /Users/kregenrek/projects/planr-test
|
|
34
|
+
npm test
|
|
35
|
+
npm run test:npm-planr
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
Run local security and leak checks:
|
|
39
|
+
|
|
40
|
+
```bash
|
|
41
|
+
scripts/security-local.sh
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
This uses BetterLeaks for secret history scanning and Trivy for filesystem vulnerability, secret, and misconfiguration scanning.
|
|
45
|
+
|
|
46
|
+
## Supply Chain
|
|
47
|
+
|
|
48
|
+
Dependabot is configured in `.github/dependabot.yml` for:
|
|
49
|
+
|
|
50
|
+
- Cargo dependencies
|
|
51
|
+
- npm dependencies
|
|
52
|
+
- GitHub Actions
|
|
53
|
+
|
|
54
|
+
GitHub Actions use read-only default permissions and pin checkout by commit SHA.
|
|
@@ -0,0 +1,33 @@
|
|
|
1
|
+
# Claude Code Integration
|
|
2
|
+
|
|
3
|
+
## Plugin (preferred for skills)
|
|
4
|
+
|
|
5
|
+
The Planr repository is a Claude Code plugin. Install it to get the skills (namespaced as `/planr:planr`, `/planr:planr-loop`, ...) plus the `planr-worker` and `planr-reviewer` subagents:
|
|
6
|
+
|
|
7
|
+
```text
|
|
8
|
+
/plugin marketplace add instructa/planr
|
|
9
|
+
/plugin install planr@planr
|
|
10
|
+
```
|
|
11
|
+
|
|
12
|
+
See [Skills](SKILLS.md) for the skill workflow. For autonomous goal runs with `/goal` or `/loop` on top of Planr state, see [Long-Running Goals](GOALS.md).
|
|
13
|
+
|
|
14
|
+
## MCP
|
|
15
|
+
|
|
16
|
+
```bash
|
|
17
|
+
planr install claude --dry-run
|
|
18
|
+
planr install claude
|
|
19
|
+
planr doctor --client claude
|
|
20
|
+
```
|
|
21
|
+
|
|
22
|
+
Dry-run prints both project-scope `.mcp.json` content and the user-scope CLI form. The non-dry command writes only this repository's `.mcp.json`.
|
|
23
|
+
|
|
24
|
+
Claude Code should treat Planr map state as authoritative and use Markdown plans as context.
|
|
25
|
+
|
|
26
|
+
For repo-local review feedback, write JSON to a file and ingest it:
|
|
27
|
+
|
|
28
|
+
```bash
|
|
29
|
+
planr review ingest <item-id> --from .planr/tmp/claude-review.json
|
|
30
|
+
planr review artifact <review-item-id>
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
Planr does not install shell hooks or edit global Claude Code configuration. The review item remains open until `planr review close` records the final verdict.
|
|
@@ -0,0 +1,126 @@
|
|
|
1
|
+
# CLI Reference
|
|
2
|
+
|
|
3
|
+
Generated from `planr --help` shape for V1.
|
|
4
|
+
|
|
5
|
+
```text
|
|
6
|
+
planr project init [--client codex|claude|cursor|all] [--force] [name]
|
|
7
|
+
planr project show [--json]
|
|
8
|
+
planr project list [--json]
|
|
9
|
+
planr plan new "App idea" [--platform web] [--ai] [--backend]
|
|
10
|
+
planr plan refine <plan-id> [--note "..."]
|
|
11
|
+
planr plan split <plan-id> --slice "MVP backend"
|
|
12
|
+
planr plan check <plan-id>
|
|
13
|
+
planr plan audit <plan-id>
|
|
14
|
+
planr plan show <plan-id>
|
|
15
|
+
planr plan archive <plan-id>
|
|
16
|
+
planr map show
|
|
17
|
+
planr map build --from <plan-id>
|
|
18
|
+
planr map lane --critical
|
|
19
|
+
planr map pressure
|
|
20
|
+
planr map status
|
|
21
|
+
planr map preview --close <item-id>
|
|
22
|
+
planr map unlocks <item-id>
|
|
23
|
+
planr map lookahead [--from <item-id>] [--limit 10]
|
|
24
|
+
planr item create "title" --description "..." [--after <item-id>] [--timeout-seconds N] [--max-retries N] [--retry-backoff fixed|exponential] [--retry-delay-ms N] [--pre "..."] [--post "..."]
|
|
25
|
+
planr item breakdown <item-id> --into "A" --into "B" [--into "C"]
|
|
26
|
+
planr item insert "title" --description "..." --after <item-id> [--before <item-id>] [--preview|--confirm]
|
|
27
|
+
planr item amend <item-id> --note "..." [--tag amendment]
|
|
28
|
+
planr item replan <parent-id> --into "A, B, C" [--preview|--confirm]
|
|
29
|
+
planr link add <from-item> <to-item> --type blocks
|
|
30
|
+
planr pick
|
|
31
|
+
planr pick release <item-id> [--force]
|
|
32
|
+
planr pick heartbeat [item-id]
|
|
33
|
+
planr pick progress <item-id> --percent 0..100 [--note "..."]
|
|
34
|
+
planr pick pause <item-id> [--note "..."]
|
|
35
|
+
planr pick resume <item-id>
|
|
36
|
+
planr pick stale [--older-than-seconds 900] [--release]
|
|
37
|
+
planr recover sweep [--older-than-seconds 900] [--apply]
|
|
38
|
+
planr approval request <item-id> [--reason "..."]
|
|
39
|
+
planr approval approve <item-id> --by "name" [--comment "..."]
|
|
40
|
+
planr approval deny <item-id> --by "name" [--comment "..."]
|
|
41
|
+
planr approval list [--open]
|
|
42
|
+
planr artifact add "name"|--name "name" [--item <item-id>] [--kind evidence] [--path file] [--content "..."] [--mime text/plain]
|
|
43
|
+
planr artifact show <artifact-id>
|
|
44
|
+
planr artifact list [--item <item-id>]
|
|
45
|
+
planr event list [--item <item-id>] [--limit 50]
|
|
46
|
+
planr debug bundle [--item <item-id>] --preview
|
|
47
|
+
planr log add --item <item-id> --summary "..." [--files a --files b | --files a,b] [--cmd "..."] [--kind completion|progress|verification]
|
|
48
|
+
planr review request <item-id>
|
|
49
|
+
planr review annotate <item-id> --message "..." [--severity info|warning|blocking] [--file path] [--line N] [--author "..."]
|
|
50
|
+
planr review ingest <item-id> (--from feedback.json|--stdin)
|
|
51
|
+
planr review artifact <review-item-id> [--out .planr/reviews/custom.review.md]
|
|
52
|
+
planr review evidence <item-id> [--pr-url https://...]
|
|
53
|
+
planr review close <review-item-id> --verdict complete|not-complete|unclear [--close-target]
|
|
54
|
+
planr close [item-id] --summary "..." [--next]
|
|
55
|
+
planr done [item-id] --summary "..." [--files a --files b] [--cmd "..."] [--tests "..."] [--review] [--next]
|
|
56
|
+
planr context add "text" [--item <item-id>] [--tag discovery]
|
|
57
|
+
planr search "query"
|
|
58
|
+
planr doctor [--client codex|claude|cursor|all]
|
|
59
|
+
planr install codex|claude|cursor [--dry-run]
|
|
60
|
+
planr prompt cli|mcp|http [--client codex|claude|cursor|all]
|
|
61
|
+
planr mcp
|
|
62
|
+
planr serve --port 7526
|
|
63
|
+
planr import <file> [--preview] [--confirm]
|
|
64
|
+
planr export --out planr.json [--include-plans] [--include-logs] [--template-name "..."] [--tag tag]
|
|
65
|
+
```
|
|
66
|
+
|
|
67
|
+
Global flags: `--db <path>`, `--json`, `--no-color`. They are valid in both positions: `planr --json pick` and `planr pick --json` behave identically.
|
|
68
|
+
|
|
69
|
+
## JSON Envelope Convention
|
|
70
|
+
|
|
71
|
+
With `--json`, responses follow one convention so agents never guess where data lives:
|
|
72
|
+
|
|
73
|
+
- Errors: `{"error": {"code": "...", "message": "..."}}` with a non-zero exit code. Codes include `not_found`, `invalid_transition`, `already_closed`, `bad_request`, `locked`, `parse_error`, and `internal_error`. `invalid_transition` messages carry the exact repair command for the current state (e.g. which review to close, which approval to resolve, or that blockers must settle first) — the error is the instruction.
|
|
74
|
+
- List fields on logs (`files`, `commands`, `tests`, `review_findings`) are always arrays — `[]` when empty, never `null`.
|
|
75
|
+
- The affected single item is always available under the top-level `item` key (`pick`, `close`, `item create/update/cancel`, `pick release`, `item breakdown`, approval and runtime commands). Action-specific keys like `closed`, `cancelled`, or `released` carry the id and stay for context.
|
|
76
|
+
- Collections use plural keys: `items`, `plans`, `logs`, `reviews`, `artifacts`, `approvals`, `events`.
|
|
77
|
+
- Other single objects use their semantic key: `plan`, `log`, `review`, `artifact`, `context`.
|
|
78
|
+
- Optional guidance appears under `hint` or `next` when a follow-up command is the expected move.
|
|
79
|
+
|
|
80
|
+
`plan check` validates path, YAML frontmatter, and that required sections have content: build plans need `## Scope Decision`, `## Verification`, and `## Acceptance Criteria` filled; product plans need `## Problem`, `## Requirements`, and `## Success Criteria` filled in `PRODUCT_SPEC.md`. Each warning is structured — `{"file", "section", "message", "fix"}` — and names the exact file to edit plus the re-run command, so a failed check is a repair instruction, not a riddle.
|
|
81
|
+
|
|
82
|
+
`plan audit <plan-id>` is the one-call contract verdict for a plan's map scope. It evaluates four clauses with evidence: `items_settled` (open items listed), `reviews_complete` (open review items listed), `approvals_clear` (requested/denied approvals listed), and `verification_logged` (logs with `--kind verification` on scope items). The stored goal contract (`planr context --tag goal-contract` mentioning the plan id) is included; the verification clause is binding only when such a contract exists. `holds: true` means the contract is satisfied — loop agents use this as their stop condition instead of stitching the verdict together from `map status`, `log list`, and `approval list`. Also available as MCP `planr_plan_audit`.
|
|
83
|
+
|
|
84
|
+
`map build` chains the created items in plan order with `blocks` links — build plan steps are ordered, so the map inherits that order instead of leaving everything flat. The output lists every created item with its status, the created links, and the next command; adjust order with `planr link add` before picking if execution order differs from document order.
|
|
85
|
+
|
|
86
|
+
`item breakdown` follows the same contract: each `--into` flag carries one child title (a single value may also pack newline- or comma-separated titles), children are chained with `blocks` links in the given order, and the parent parks as a blocked gate until they settle. The output lists every child with id and status, the chain links, and the next command — across CLI and MCP `planr_item_breakdown`.
|
|
87
|
+
|
|
88
|
+
`review ingest` accepts hook-compatible JSON and records it as feedback only. It never closes review work and never approves an item by itself.
|
|
89
|
+
|
|
90
|
+
```json
|
|
91
|
+
{
|
|
92
|
+
"reviewer": "local-reviewer",
|
|
93
|
+
"verdict": "not-complete",
|
|
94
|
+
"findings": ["Add the missing failing-path test"],
|
|
95
|
+
"annotations": [
|
|
96
|
+
{
|
|
97
|
+
"message": "The close path needs regression coverage",
|
|
98
|
+
"severity": "blocking",
|
|
99
|
+
"file": "tests/e2e.rs",
|
|
100
|
+
"line": 42
|
|
101
|
+
}
|
|
102
|
+
]
|
|
103
|
+
}
|
|
104
|
+
```
|
|
105
|
+
|
|
106
|
+
`review request` (and `done --review`) moves a picked or running target to `in_review`: work is finished, evidence is logged, the item waits on its gate. The owner keeps the pick and can still log evidence; `in_review` items are never handed out by `pick`.
|
|
107
|
+
|
|
108
|
+
`review close` writes `.planr/reviews/<review-item-id>.review.md` and registers it as a review artifact. A `not-complete` or `unclear` verdict creates fix and follow-up review work; the follow-up review gates the same target item, so the chain keeps working with `--close-target`. With `--close-target` (complete verdicts only) the reviewed item is closed in the same command, provided it already has a completion log; the artifact is rendered after the target transition, so it snapshots the final target status. `--close-target` is also available through MCP `planr_review_close` and HTTP `POST /v1/reviews/{id}/close` (`"close_target": true`). `review close` responses include the same `remaining` progress snapshot as `done` and `close`. `--reviewer <id>` records the checker's identity on the review log, artifact, and event (defaults to the worker id), keeping maker and checker distinguishable in the audit trail. Closing an already-settled review fails with error code `already_closed` instead of silently duplicating evidence logs. The maker/checker split is derived, not declared: `review_mode` compares the closing reviewer identity against the target item's lease holder and reports `single_agent`, `independent`, or `unattributed` in the response, review log, artifact, and event — no ceremony note required.
|
|
109
|
+
|
|
110
|
+
`trace item` on a review item inlines the target item and its evidence logs under `target`, so a reviewer's first trace already contains what is being audited. The human (non-JSON) mode renders the packet: status, owner, links, logs.
|
|
111
|
+
|
|
112
|
+
`done` is the compound worker command: it writes a completion log, then requests a review (`--review`) or closes the item, and optionally picks the next ready item (`--next`). Without `--next`, the response's `next` field carries the exact follow-up command instead (`planr pick --work-type review --json` after a review request, `planr pick --json` after a close), so every settlement output ends in an action. It chains the same single-owner operations as `log add`, `review request`, `close`, and `pick` — identical evidence, fewer commands. `done`, `close`, and `review close` report what the settlement `unlocked` (id, title, work type of every item that became ready), `done` and `close` echo the item's `post_condition` at completion time, and a `hint` asks for `--cmd`/`--tests` evidence when downstream items depend on an item that closed without any. `done`, `close`, `review close`, and the pick packet include a `remaining` progress snapshot so loop agents can evaluate their stop condition without an extra `map status` call. `remaining.counts` always carries the full status vocabulary (`pending`, `ready`, `picked`, `running`, `in_review`, `blocked`, `failed`, `cancelled`, `closed`, `closed_partial`) with explicit zeros — a missing count never has to be inferred.
|
|
113
|
+
|
|
114
|
+
`pick --json` returns one flat work packet in which every fact appears exactly once: `item`, `links`, `logs`, `runtime`, `recovery`, `conditions`, `approval`, recall context (`contexts`, `relevant_contexts`, `upstream_handoffs`, `review_history`, `source_links`, `possible_file_conflicts`), `close_effect`, `privacy`, `deeper_reads`, and `remaining`. Worker identity lives in `item.worker_id` and `runtime.worker_id`. Empty collections and inactive gates are omitted — a missing key means "empty". No separate `trace item` call is needed. Evidence written via `log add` or `done` by the pick owner refreshes the runtime heartbeat automatically. The same packet shape is returned by MCP `planr_pick_item`, HTTP `POST /v1/pick`, and `done --next`.
|
|
115
|
+
|
|
116
|
+
`pick --work-type <type>` restricts the lease to one work type, so checker agents pick only `review` items and makers only work items. `pick --plan <plan-id>` restricts the lease to one plan's items, so plan-scoped goal runs never pick work outside their contract even when other plans share the board; an unknown plan id is an error, never a silent unscoped pick. Both filters are available on MCP `planr_pick_item` and HTTP `POST /v1/pick` (`work_type`, `plan`). A null pick is never blind: `{"item": null}` carries a `reason` (`empty_map`, `all_settled`, `nothing_ready`, `ready_items_excluded_by_filter`) and the `remaining` snapshot. When ready work exists but the active filters rejected all of it, `excluded` lists each ready item with the cause (`work_type` mismatch, outside the `--plan` scope, or just requested by this worker) and `repair` carries the exact pick commands that would lease that work — across CLI, MCP, and HTTP. On a review item, `close_effect` previews the full `--close-target` cascade: it lists the work that closing the review (and with it the reviewed item) would unlock.
|
|
117
|
+
|
|
118
|
+
`review evidence` reports Git worktree status scoped to files named by item logs or artifacts. Dirty files without item provenance are listed as unrelated and are not treated as agent-owned evidence. `--pr-url` records an item-scoped PR reference before returning the evidence package.
|
|
119
|
+
|
|
120
|
+
`recover sweep` previews by default. With `--apply`, timed-out picked work that has a retry budget (`max_retries > 0`) is marked `failed` with an `item_timed_out` event; stale work and timeouts without a retry budget are released back to `ready`. Failed work re-enters `ready` once its retry delay has elapsed (`retry_delay_ms`, doubled per retry under `exponential` backoff) until the budget is exhausted. Every transition records a recovery event. Item pre/post conditions are visible in pick context, trace output, and close previews; post conditions are reported as manual verification gates instead of being guessed automatically.
|
|
121
|
+
|
|
122
|
+
`serve` exposes the local review workspace at `/review` and its JSON projection at `/v1/review-workspace`.
|
|
123
|
+
|
|
124
|
+
`prompt` prints ready-to-use agent instructions without editing global config. Use `prompt cli` for shell agents, `prompt mcp` for MCP setup text, and `prompt http` for localhost automation/review workspace usage.
|
|
125
|
+
|
|
126
|
+
`export` writes a reusable Planr JSON package with package requirements metadata, graph state, contexts, optional logs, optional plan file snapshots, and review artifact snapshots. `import` previews JSON packages by default and mutates only with `--confirm`.
|
package/docs/CODEX.md
ADDED
|
@@ -0,0 +1,48 @@
|
|
|
1
|
+
# Codex Integration
|
|
2
|
+
|
|
3
|
+
## Plugin (preferred for skills)
|
|
4
|
+
|
|
5
|
+
The Planr repository is a Codex plugin. Install it to get the `$planr`, `$planr-loop`, and stage skills without copying folders:
|
|
6
|
+
|
|
7
|
+
```bash
|
|
8
|
+
codex plugin marketplace add instructa/planr
|
|
9
|
+
codex plugin add planr@planr
|
|
10
|
+
```
|
|
11
|
+
|
|
12
|
+
See [Skills](SKILLS.md) for the skill workflow and subagent role templates.
|
|
13
|
+
|
|
14
|
+
## Long-Running Goals With `/goal`
|
|
15
|
+
|
|
16
|
+
Codex `/goal` is the recommended orchestrator for autonomous Planr runs: `/goal` supplies continuation pressure, Planr supplies durable state, evidence, reviews, and recovery. Prep once with `$planr-goal`, then start:
|
|
17
|
+
|
|
18
|
+
```text
|
|
19
|
+
$planr-goal <your goal>
|
|
20
|
+
/goal Use $planr-loop on plan <plan-id>. The loop contract is stored in planr context (tag: goal-contract). Continue until the contract holds or the iteration budget is exhausted.
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
The stop condition lives in Planr (`--tag goal-contract`), so a dead session resumes with the same starter line from zero chat context. Full workflow, recovery, and per-host variants: [Long-Running Goals](GOALS.md).
|
|
24
|
+
|
|
25
|
+
## MCP
|
|
26
|
+
|
|
27
|
+
```bash
|
|
28
|
+
planr install codex --dry-run
|
|
29
|
+
planr doctor --client codex
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
The dry-run prints the MCP server snippet for `planr mcp`. Verify the client-side registration with the Codex CLI command shown by your local Codex installation.
|
|
33
|
+
|
|
34
|
+
Codex should use the same public flow as every other client:
|
|
35
|
+
|
|
36
|
+
```text
|
|
37
|
+
map -> pick -> work -> log -> review -> close
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
Review hooks can feed Planr without changing global Codex settings:
|
|
41
|
+
|
|
42
|
+
```bash
|
|
43
|
+
codex review --json > .planr/tmp/codex-review.json
|
|
44
|
+
planr review ingest <item-id> --from .planr/tmp/codex-review.json
|
|
45
|
+
planr review annotate <item-id> --message "Needs regression coverage" --severity blocking
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
Ingested feedback is evidence only. A reviewer or agent must still close the review item explicitly with `planr review close`.
|
package/docs/CURSOR.md
ADDED
|
@@ -0,0 +1,30 @@
|
|
|
1
|
+
# Cursor Integration
|
|
2
|
+
|
|
3
|
+
## Plugin
|
|
4
|
+
|
|
5
|
+
The repository carries a Cursor plugin manifest (`.cursor-plugin/plugin.json`) bundling the Planr skills. Marketplace listing is pending review; until it is listed, use MCP plus the CLI prompt below. See [Skills](SKILLS.md) for the skill workflow and [Long-Running Goals](GOALS.md) for running goal loops without a native `/goal` primitive.
|
|
6
|
+
|
|
7
|
+
## MCP
|
|
8
|
+
|
|
9
|
+
```bash
|
|
10
|
+
planr install cursor --dry-run
|
|
11
|
+
planr install cursor
|
|
12
|
+
planr doctor --client cursor
|
|
13
|
+
```
|
|
14
|
+
|
|
15
|
+
Dry-run prints `.cursor/mcp.json` content. The non-dry command writes the project-scoped config.
|
|
16
|
+
|
|
17
|
+
Planr V1 defaults to MCP stdio. Local HTTP/SSE is available through:
|
|
18
|
+
|
|
19
|
+
```bash
|
|
20
|
+
planr serve --port 7526
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
Cursor tasks can attach review feedback through either MCP stdio or the local HTTP API:
|
|
24
|
+
|
|
25
|
+
```bash
|
|
26
|
+
planr review annotate <item-id> --message "Cursor review note" --severity warning
|
|
27
|
+
planr review ingest <item-id> --from .planr/tmp/cursor-review.json
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
The project-scoped `.cursor/mcp.json` is the only file written by `planr install cursor`. Review ingestion does not auto-close or auto-approve work.
|