pi-pstack-native 0.0.0-stage → 1.0.1

package/skills/sharpen/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: sharpen
+description: "Make a task deeper, not bigger, then rewrite the prompt. Use for /sharpen."
+disable-model-invocation: true
+---
+
+<!-- Generated by scripts/semantics/generate.mjs; edit the source mapping/adapter, not this file. -->
+
+# Pi adapter for the pinned pstack source
+
+The behavior source is the `vendor/upstream/0.15.36/pstack/` snapshot at `c742dd61706fbacc1b95f1a20b7b988cf096ce6c`. Generated supported Skill/playbook entrypoints retain the upstream Markdown after this Pi prelude. The eleven core workflows have critical-rule mappings; preserving a source body does not prove that a model followed it. The full source inventory is pinned separately; maintainer semantic sign-off remains pending.
+
+Apply user instructions and repository authority first. Read referenced source Markdown through `pstack_skill` with `upstream/skills/<skill>/...` resource IDs, consuming every page. Statechart's 0.15.36 TypeScript runtime and its test corpus are bundled under `skills/statechart/scripts`; the older 0.15.32 `.mjs` tools are retained for compatibility. Java/TLC and optional renderers are external dependencies. Other Cursor plugins, private APIs, drivers and cloud resources are not supplied.
+
+For Statechart execution, run `node <skill-dir>/../../dist/statechart/statechart.js SPEC.tla [--config FILE] [--view FILE] [--out DIR]`. This compiled copy is required in installed packages because Node does not strip TypeScript inside `node_modules`. The upstream source and test corpus remain unchanged.
+
+## Platform substitutions
+
+- Task workers use `pstack_agents` and `pstack_workflow` Pi AgentSessions. The parent owns the playbook. Parallel writers use Git worktrees; integrated delivery uses an explicit integrator and verification. These are local processes, not cloud VMs or OS sandboxes.
+- `/setup-pstack` previews model roles and suggested panels using models visible in the current Pi session; edit only what needs changing. Existing choices are preserved. Panels with the same model in several seats do not provide model diversity. Model roles use `models.json`; pass the playbook and, for named roles such as Reflect's `tooling`, `judgment`, `divergent`, and `synthesizer`, `modelRole` when dispatching. Explicit node models take precedence.
+- Pi `thinkingLevel` replaces Cursor's reasoning slug conventions. Optional same-family fallback chooses a registered model from the same provider and reports it; a supported lower reasoning level may be used and reported. Unknown families are not guessed, Cursor `-fast` aliases are not rewritten, and authentication/inference failures are not automatically retried.
+- For an unconfigured panel, plans suggest available Pi models and disclose repeated seats. Unresolvable configured seats are dropped or replaced with an available survivor or the parent, with notes. A known-family parent gets a judge only from another recognized family; if none is available, the plan produces candidates only and the coordinator must inspect, choose, integrate and verify them. A failed or unaccepted candidate is excluded only after the other candidates settle; verified survivors remain eligible and the dropout is recorded.
+- Arena's cross-judge uses confined `pstack_candidates` access to verified worktrees. The integrator independently reads and compares candidates before selecting and grafting. Architect's template includes a separate implementation phase after the selected sketch; the coordinator still owns upstream grounding (`how`/`why`) and optional checkpoints.
+- Interrogate creates a worktree for each adversary, copies the reviewed staged, unstaged and untracked changes, and runs a separate repro-verifier on each worktree. No adversary changes are integrated. Both sessions must report command, observed and expected output; synthesis can only carry reproductions present in a verifier report. These sessions use Pi's ordinary writable-agent shell permissions; the verification-policy allowlist controls native gate commands, not their interactive shell. Model reports are not independently attested receipts: the coordinator must inspect actual command evidence and the effect of any repro edits before claiming a finding is verified.
+- Swarm supports partition, best-of, first-pass and rank-all race templates. First-pass waits for a candidate's deterministic acceptance, requests cooperative cancellation of the remaining sessions, and waits for them to settle. Rank-all reports every rank without automatically integrating a winner. Mixed partition/race still needs an explicit DAG.
+- Custom Mode maps to sticky `/poteto-mode`. `/loop` maps to `/pstack-loop`, which requires an active Pi host and cannot promise cloud-root scheduling or exact delivery across a crash.
+- Use an available named CLI/UI driver for real-surface proof. Without one, return blocked or inconclusive with the exact reason; unit tests, fake providers and worker reports cannot replace a live lane.
+
+## Explicit policy deviations
+
+- Native exact-head/base ledgers invalidate verification when either changes, including patch-preserving restacks; upstream can reuse some patch-ID-stable verdicts.
+- Read-only reviewer, scout and verifier sessions inspect confined source and evidence but cannot run shell commands or live MCP. Deterministic commands run in an authorized runner or writable lane. For external investigation, the parent supplies evidence snapshots and verifies decisive citations.
+- Autopilot templates prepare local DAG artifacts. The coordinator remains responsible for the owner lifecycle, early PRs, periodic audit, rebase discipline, countersigns and stop propagation. A stack template alone does not deliver a remote PR stack. Babysit stops at merge-ready; shipping and remote writes require the actual applicable authorization.
+- Opening a PR does not start a babysit. Finish the phase or stack before a requested babysit unless an explicitly assigned full-autonomy owner owns the loop and has reported code-ready. Babysit stops before merge; operator-reserved items never merge automatically.
+
+## Unsupported operations
+
+`Cursor-private-PR-provenance`, `Cursor-watch-READY`, `Cursor-cleanup-plugin` and `Bugbot-pass-dismissal` are unsupported. GitHub/Origin and native states are alternatives with their own evidence boundaries, not proof that a Cursor operation ran. `make-bot-ui` and the Cursor automation event pack require Cursor-specific surfaces. Report these limitations rather than marking unavailable operations complete.
+
+## Evidence boundary
+
+`SEMANTICS.json` records selected critical-rule mappings, exact source lines, deviations, bound tests and file fingerprints. Inventory counts, source hashes, deterministic checks, Pi SDK/fake-provider tests, real-model runs and maintainer semantic review are separate evidence levels. Advancing the source pin and passing CI do not establish complete Cursor/Pi equivalence or maintainer approval.
+
+
+---
+
+## Pinned upstream instructions
+
+Source: cursor/plugins@c742dd61706fbacc1b95f1a20b7b988cf096ce6c, pstack/skills/sharpen/SKILL.md. The following body is retained verbatim.
+
+
+I want a deeper version of this task, not a bigger one. Before rewriting it, do four things:
+
+1. Say what a top professional in this field would do here that I'm not asking for.
+2. Name the rawest material they would start from instead of what has already been digested for me.
+3. Name the specific methods and tools they would use.
+4. Say what, other than you or me, would show the result is right.
+
+Then rewrite my prompt to ask for exactly that.
+
+Leave choices that are mine to make open instead of deciding them.
+
+
+## Pi execution tools
+
+Use `pstack_agents` for one child and `pstack_workflow` / `pstack_graph` for an explicit DAG. Roles are `architect`, `worker`, `reviewer`, `verifier`, `synthesizer` and `integrator`. Parallel writers use isolated worktrees, then an integrator. A verifier directly depends on the artifact owner. Inspect workflow status on recovery; completed nodes are not replayed. Check remote state before retrying external effects. `pstack_worktrees` cleans only owned clean worktrees.

package/skills/show-me-your-work/SKILL.md

@@ -0,0 +1,132 @@
+---
+name: show-me-your-work
+description: "Keep a reviewable decision trail for long-running or unattended work: a TSV log with one row per decision (what, why, evidence, result). Local by default; commit it when a reviewer needs the trail to trust the result. Use for /show-me-your-work, autonomous or multi-phase runs, or work a human reviews after stepping away."
+disable-model-invocation: true
+---
+
+<!-- Generated by scripts/semantics/generate.mjs; edit the source mapping/adapter, not this file. -->
+
+# Pi adapter for the pinned pstack source
+
+The behavior source is the `vendor/upstream/0.15.36/pstack/` snapshot at `c742dd61706fbacc1b95f1a20b7b988cf096ce6c`. Generated supported Skill/playbook entrypoints retain the upstream Markdown after this Pi prelude. The eleven core workflows have critical-rule mappings; preserving a source body does not prove that a model followed it. The full source inventory is pinned separately; maintainer semantic sign-off remains pending.
+
+Apply user instructions and repository authority first. Read referenced source Markdown through `pstack_skill` with `upstream/skills/<skill>/...` resource IDs, consuming every page. Statechart's 0.15.36 TypeScript runtime and its test corpus are bundled under `skills/statechart/scripts`; the older 0.15.32 `.mjs` tools are retained for compatibility. Java/TLC and optional renderers are external dependencies. Other Cursor plugins, private APIs, drivers and cloud resources are not supplied.
+
+For Statechart execution, run `node <skill-dir>/../../dist/statechart/statechart.js SPEC.tla [--config FILE] [--view FILE] [--out DIR]`. This compiled copy is required in installed packages because Node does not strip TypeScript inside `node_modules`. The upstream source and test corpus remain unchanged.
+
+## Platform substitutions
+
+- Task workers use `pstack_agents` and `pstack_workflow` Pi AgentSessions. The parent owns the playbook. Parallel writers use Git worktrees; integrated delivery uses an explicit integrator and verification. These are local processes, not cloud VMs or OS sandboxes.
+- `/setup-pstack` previews model roles and suggested panels using models visible in the current Pi session; edit only what needs changing. Existing choices are preserved. Panels with the same model in several seats do not provide model diversity. Model roles use `models.json`; pass the playbook and, for named roles such as Reflect's `tooling`, `judgment`, `divergent`, and `synthesizer`, `modelRole` when dispatching. Explicit node models take precedence.
+- Pi `thinkingLevel` replaces Cursor's reasoning slug conventions. Optional same-family fallback chooses a registered model from the same provider and reports it; a supported lower reasoning level may be used and reported. Unknown families are not guessed, Cursor `-fast` aliases are not rewritten, and authentication/inference failures are not automatically retried.
+- For an unconfigured panel, plans suggest available Pi models and disclose repeated seats. Unresolvable configured seats are dropped or replaced with an available survivor or the parent, with notes. A known-family parent gets a judge only from another recognized family; if none is available, the plan produces candidates only and the coordinator must inspect, choose, integrate and verify them. A failed or unaccepted candidate is excluded only after the other candidates settle; verified survivors remain eligible and the dropout is recorded.
+- Arena's cross-judge uses confined `pstack_candidates` access to verified worktrees. The integrator independently reads and compares candidates before selecting and grafting. Architect's template includes a separate implementation phase after the selected sketch; the coordinator still owns upstream grounding (`how`/`why`) and optional checkpoints.
+- Interrogate creates a worktree for each adversary, copies the reviewed staged, unstaged and untracked changes, and runs a separate repro-verifier on each worktree. No adversary changes are integrated. Both sessions must report command, observed and expected output; synthesis can only carry reproductions present in a verifier report. These sessions use Pi's ordinary writable-agent shell permissions; the verification-policy allowlist controls native gate commands, not their interactive shell. Model reports are not independently attested receipts: the coordinator must inspect actual command evidence and the effect of any repro edits before claiming a finding is verified.
+- Swarm supports partition, best-of, first-pass and rank-all race templates. First-pass waits for a candidate's deterministic acceptance, requests cooperative cancellation of the remaining sessions, and waits for them to settle. Rank-all reports every rank without automatically integrating a winner. Mixed partition/race still needs an explicit DAG.
+- Custom Mode maps to sticky `/poteto-mode`. `/loop` maps to `/pstack-loop`, which requires an active Pi host and cannot promise cloud-root scheduling or exact delivery across a crash.
+- Use an available named CLI/UI driver for real-surface proof. Without one, return blocked or inconclusive with the exact reason; unit tests, fake providers and worker reports cannot replace a live lane.
+
+## Explicit policy deviations
+
+- Native exact-head/base ledgers invalidate verification when either changes, including patch-preserving restacks; upstream can reuse some patch-ID-stable verdicts.
+- Read-only reviewer, scout and verifier sessions inspect confined source and evidence but cannot run shell commands or live MCP. Deterministic commands run in an authorized runner or writable lane. For external investigation, the parent supplies evidence snapshots and verifies decisive citations.
+- Autopilot templates prepare local DAG artifacts. The coordinator remains responsible for the owner lifecycle, early PRs, periodic audit, rebase discipline, countersigns and stop propagation. A stack template alone does not deliver a remote PR stack. Babysit stops at merge-ready; shipping and remote writes require the actual applicable authorization.
+- Opening a PR does not start a babysit. Finish the phase or stack before a requested babysit unless an explicitly assigned full-autonomy owner owns the loop and has reported code-ready. Babysit stops before merge; operator-reserved items never merge automatically.
+
+## Unsupported operations
+
+`Cursor-private-PR-provenance`, `Cursor-watch-READY`, `Cursor-cleanup-plugin` and `Bugbot-pass-dismissal` are unsupported. GitHub/Origin and native states are alternatives with their own evidence boundaries, not proof that a Cursor operation ran. `make-bot-ui` and the Cursor automation event pack require Cursor-specific surfaces. Report these limitations rather than marking unavailable operations complete.
+
+## Evidence boundary
+
+`SEMANTICS.json` records selected critical-rule mappings, exact source lines, deviations, bound tests and file fingerprints. Inventory counts, source hashes, deterministic checks, Pi SDK/fake-provider tests, real-model runs and maintainer semantic review are separate evidence levels. Advancing the source pin and passing CI do not establish complete Cursor/Pi equivalence or maintainer approval.
+
+
+---
+
+## Pinned upstream instructions
+
+Source: cursor/plugins@c742dd61706fbacc1b95f1a20b7b988cf096ce6c, pstack/skills/show-me-your-work/SKILL.md. The following body is retained verbatim.
+
+
+# Show me your work
+
+Keep one canonical log.
+
+## The format
+
+A single TSV file, one row per decision. Cells stay single-line. Evidence is a pointer, not prose.
+
+Copy `references/decision-log-template.tsv` (the header row) to start a clean log. Columns:
+
+- **ts.** ISO8601 timestamp.
+- **phase.** The phase or workstream.
+- **decision.** What was chosen or done, one line.
+- **why.** The reason in plain words. If a principle drove it, say it plainly, not as a jargon tag.
+- **evidence.** A link or path that proves it: commit SHA, PR number, `file:line`, or an artifact, trace, or screenshot path. Never a paragraph.
+- **result.** The outcome or predicate state: `tests green`, `reverted`, `pixel-diff 0`, `INCONCLUSIVE`, `open`.
+
+An example, plain-spoken so a reviewer reads it at a glance.
+
+```
+ts	phase	decision	why	evidence	result
+2026-05-24T09:02:00Z	frame	counted the work first, about 100 components and roughly 75 hours	wanted to know the size before starting a long run	commit 3a9f1c2	found 5 things to sort out before starting
+2026-05-24T09:40:00Z	harness	took screenshots of the old version before changing anything	so we can compare old against new and catch any visual change	scripts/snapshot.sh, baseline/	saved 120 reference screenshots
+2026-05-24T11:15:00Z	widget	moved the widget styles over without changing how it looks	keep the change small and the result identical	commit 7c21e0a, pixel-diff 0	looks identical, tests pass
+2026-05-24T12:30:00Z	widget	threw out a helper's work because its screenshots were blank	checked the real files instead of trusting its summary	worktree reset	reverted, tightened the instructions for next time
+```
+
+## Logging a row
+
+Write each entry the way you'd tell a teammate what you did. Plain words, concrete actions, no AI speak or abstract jargon (the **unslop** skill applies to log text too).
+
+Use the helper `scripts/log.sh <logfile> <phase> <decision> <why> <evidence> <result>`. It stamps `ts`, writes the header on first use, strips stray tabs/newlines, and prefixes any cell starting with `=`, `+`, `-`, or `@` with a single quote. A bare `printf` appending a row works too, but mind those same bytes if cells come from generated or user-supplied text.
+
+Log decision points and checkpoints, not every action: a fork chosen, a unit completed with its verification result, a pivot or revert with its trigger, a blocker surfaced, a gate fixed. For loop runs, one row per iteration. Skip the trivial and self-evident.
+
+A run is one agent conversation, including its later turns and any summary of it. A pickup, a replacement agent, or a new chat starts a new run. When a run adds to a log that already has rows, its first row has phase `start`, and so does its first row after another run's `start` row. So a run that comes back to a log in a later turn first reads the log's last rows to see whether another run wrote since. A `start` row names the `ts` range of the rows before it that this run did not write, and its evidence names this run, such as its agent id. Use phase `start` for nothing else.
+
+## Where it lives
+
+By default the log is a working artifact, not committed. Keep it at `decisions.tsv` in the work dir, or `.audit/<task-slug>.tsv` when several efforts run at once, and leave it out of git.
+
+Commit it only when the work is ambitious enough that a reviewer needs the trail to trust the result.
+
+## Rules
+
+- Append-only. A wrong call gets a new row that supersedes it. Never edit or delete history.
+- Prefer evidence produced by committed scripts over hand-made one-offs (the **encode-lessons-in-structure** principle skill).
+
+## Audit the log against the transcript
+
+At the end of the run, before handing back, check the log told the truth. Read this run's transcript under the active workspace's `agent-transcripts/` directory (the system prompt names the path). Don't glob across `~/.cursor/projects/*/`. That reads unrelated private chats. Walk this run's rows against what actually happened. Each stretch of them begins at one of this run's `start` rows, or at the first row if this run created the log, and ends at the next `start` row of another run:
+
+- Check that every row maps to a real decision or action.
+- Check that each row's evidence resolves and shows what the row claims.
+- A fork, pivot, or abandoned approach that shaped the work but isn't logged is a gap. Add it.
+
+Correct the log, not the story. The audit never edits or removes a row, even an invented one. When a row records neither a real decision nor a real action, or its claim or evidence is wrong, add a row that supersedes it with what actually happened and a pointer that resolves. This audit does not check rows outside this run's stretches. If this run's own work shows one of them is wrong, supersede it like any wrong call.
+
+## Cross-model review of the trail
+
+Before handing back, spawn a subagent on a different model family from the one that did the work. Self-review is not a substitute. The subagent reads the audit trail and the run's transcript, then flags what the user should pay attention to. Not a redo of the work, a scan for what's suboptimal or risky. Pick each subagent's reasoning level and fast or standard speed for the job, per the Subagents section of the **poteto-mode** skill.
+
+- Decisions logged with weak or absent evidence.
+- Verification steps skipped or claimed without proof in the transcript.
+- Choices that look risky in hindsight (premature, scope-creeping, papering over a symptom).
+- Gaps the user would otherwise miss on a casual skim.
+
+Every reply for a run that produced a trail ends with an "Attention" section. Lead with the reviewer's model on its own line (`reviewed by <model>`), then list each flag pointing to specific rows or moments. "No flags" is a valid value. The model name is not.
+
+## Reviewing the trail
+
+Read top to bottom, follow the evidence pointers, spot-check. GitHub renders a committed TSV as a table. `column -s$'\t' -t decisions.tsv` renders it in a terminal.
+
+## Composing this skill
+
+Other skills route their audit trail here instead of inventing one. Reference it by name and let it own the format. Don't restate the columns.
+
+
+## Pi execution tools
+
+Use `pstack_agents` for one child and `pstack_workflow` / `pstack_graph` for an explicit DAG. Roles are `architect`, `worker`, `reviewer`, `verifier`, `synthesizer` and `integrator`. Parallel writers use isolated worktrees, then an integrator. A verifier directly depends on the artifact owner. Inspect workflow status on recovery; completed nodes are not replayed. Check remote state before retrying external effects. `pstack_worktrees` cleans only owned clean worktrees.

package/skills/statechart/SKILL.md

@@ -0,0 +1,132 @@
+---
+name: statechart
+description: "Check a TLA+ model of a system that moves between states, such as a product flow, a protocol, or a service, and draw it as a Mermaid statechart. The report gives the shortest path to each state that breaks a rule. Use for /statechart, or to show a bug as a path through states."
+disable-model-invocation: true
+---
+
+<!-- Generated by scripts/semantics/generate.mjs; edit the source mapping/adapter, not this file. -->
+
+# Pi adapter for the pinned pstack source
+
+The behavior source is the `vendor/upstream/0.15.36/pstack/` snapshot at `c742dd61706fbacc1b95f1a20b7b988cf096ce6c`. Generated supported Skill/playbook entrypoints retain the upstream Markdown after this Pi prelude. The eleven core workflows have critical-rule mappings; preserving a source body does not prove that a model followed it. The full source inventory is pinned separately; maintainer semantic sign-off remains pending.
+
+Apply user instructions and repository authority first. Read referenced source Markdown through `pstack_skill` with `upstream/skills/<skill>/...` resource IDs, consuming every page. Statechart's 0.15.36 TypeScript runtime and its test corpus are bundled under `skills/statechart/scripts`; the older 0.15.32 `.mjs` tools are retained for compatibility. Java/TLC and optional renderers are external dependencies. Other Cursor plugins, private APIs, drivers and cloud resources are not supplied.
+
+For Statechart execution, run `node <skill-dir>/../../dist/statechart/statechart.js SPEC.tla [--config FILE] [--view FILE] [--out DIR]`. This compiled copy is required in installed packages because Node does not strip TypeScript inside `node_modules`. The upstream source and test corpus remain unchanged.
+
+## Platform substitutions
+
+- Task workers use `pstack_agents` and `pstack_workflow` Pi AgentSessions. The parent owns the playbook. Parallel writers use Git worktrees; integrated delivery uses an explicit integrator and verification. These are local processes, not cloud VMs or OS sandboxes.
+- `/setup-pstack` previews model roles and suggested panels using models visible in the current Pi session; edit only what needs changing. Existing choices are preserved. Panels with the same model in several seats do not provide model diversity. Model roles use `models.json`; pass the playbook and, for named roles such as Reflect's `tooling`, `judgment`, `divergent`, and `synthesizer`, `modelRole` when dispatching. Explicit node models take precedence.
+- Pi `thinkingLevel` replaces Cursor's reasoning slug conventions. Optional same-family fallback chooses a registered model from the same provider and reports it; a supported lower reasoning level may be used and reported. Unknown families are not guessed, Cursor `-fast` aliases are not rewritten, and authentication/inference failures are not automatically retried.
+- For an unconfigured panel, plans suggest available Pi models and disclose repeated seats. Unresolvable configured seats are dropped or replaced with an available survivor or the parent, with notes. A known-family parent gets a judge only from another recognized family; if none is available, the plan produces candidates only and the coordinator must inspect, choose, integrate and verify them. A failed or unaccepted candidate is excluded only after the other candidates settle; verified survivors remain eligible and the dropout is recorded.
+- Arena's cross-judge uses confined `pstack_candidates` access to verified worktrees. The integrator independently reads and compares candidates before selecting and grafting. Architect's template includes a separate implementation phase after the selected sketch; the coordinator still owns upstream grounding (`how`/`why`) and optional checkpoints.
+- Interrogate creates a worktree for each adversary, copies the reviewed staged, unstaged and untracked changes, and runs a separate repro-verifier on each worktree. No adversary changes are integrated. Both sessions must report command, observed and expected output; synthesis can only carry reproductions present in a verifier report. These sessions use Pi's ordinary writable-agent shell permissions; the verification-policy allowlist controls native gate commands, not their interactive shell. Model reports are not independently attested receipts: the coordinator must inspect actual command evidence and the effect of any repro edits before claiming a finding is verified.
+- Swarm supports partition, best-of, first-pass and rank-all race templates. First-pass waits for a candidate's deterministic acceptance, requests cooperative cancellation of the remaining sessions, and waits for them to settle. Rank-all reports every rank without automatically integrating a winner. Mixed partition/race still needs an explicit DAG.
+- Custom Mode maps to sticky `/poteto-mode`. `/loop` maps to `/pstack-loop`, which requires an active Pi host and cannot promise cloud-root scheduling or exact delivery across a crash.
+- Use an available named CLI/UI driver for real-surface proof. Without one, return blocked or inconclusive with the exact reason; unit tests, fake providers and worker reports cannot replace a live lane.
+
+## Explicit policy deviations
+
+- Native exact-head/base ledgers invalidate verification when either changes, including patch-preserving restacks; upstream can reuse some patch-ID-stable verdicts.
+- Read-only reviewer, scout and verifier sessions inspect confined source and evidence but cannot run shell commands or live MCP. Deterministic commands run in an authorized runner or writable lane. For external investigation, the parent supplies evidence snapshots and verifies decisive citations.
+- Autopilot templates prepare local DAG artifacts. The coordinator remains responsible for the owner lifecycle, early PRs, periodic audit, rebase discipline, countersigns and stop propagation. A stack template alone does not deliver a remote PR stack. Babysit stops at merge-ready; shipping and remote writes require the actual applicable authorization.
+- Opening a PR does not start a babysit. Finish the phase or stack before a requested babysit unless an explicitly assigned full-autonomy owner owns the loop and has reported code-ready. Babysit stops before merge; operator-reserved items never merge automatically.
+
+## Unsupported operations
+
+`Cursor-private-PR-provenance`, `Cursor-watch-READY`, `Cursor-cleanup-plugin` and `Bugbot-pass-dismissal` are unsupported. GitHub/Origin and native states are alternatives with their own evidence boundaries, not proof that a Cursor operation ran. `make-bot-ui` and the Cursor automation event pack require Cursor-specific surfaces. Report these limitations rather than marking unavailable operations complete.
+
+## Evidence boundary
+
+`SEMANTICS.json` records selected critical-rule mappings, exact source lines, deviations, bound tests and file fingerprints. Inventory counts, source hashes, deterministic checks, Pi SDK/fake-provider tests, real-model runs and maintainer semantic review are separate evidence levels. Advancing the source pin and passing CI do not establish complete Cursor/Pi equivalence or maintainer approval.
+
+
+---
+
+## Pinned upstream instructions
+
+Source: cursor/plugins@c742dd61706fbacc1b95f1a20b7b988cf096ce6c, pstack/skills/statechart/SKILL.md. The following body is retained verbatim.
+
+
+# Statechart
+
+The chart shows how a system moves between states, in the words of the person who reads it. That person, the reader, decides whether the behavior is right.
+
+## Run
+
+Work in a scratch folder outside the repo. Write a TLA+ spec and its config. Then run:
+
+```sh
+<skill dir>/scripts/statechart SPEC.tla [--config FILE] [--view FILE] [--out DIR]
+```
+
+`scripts/statechart.ts` is TypeScript, so run it with a runtime that can execute TypeScript.
+
+The first run installs TLC and Java with mise and needs the network.
+
+## Write the spec
+
+- Write each rule that the reader agrees to as an INVARIANT. A rule can be about a screen, a result, a stored value, or a message. If the model has no variable for a rule, add the variable. Never weaken a rule to make it hold.
+- Write `Next` as a disjunction of the actions, such as `YouPressPlay \/ YouPressStop`. If you do not, TLC names every step `Next`.
+- A state with no step out breaks `NoDeadlock`, also when it is a correct end state. When an INVARIANT or a PROPERTY already has that name, the rule is `CHECK_DEADLOCK`. Add to `Next` an action that is true only in the end states and changes nothing, such as `Done == phase \in {"paid", "failed"} /\ UNCHANGED vars`, and give it a label in `step()`.
+
+## Pick the chart
+
+You do the work that needs judgment: the words on each state and arrow, the phases and their colors, the title, and the report to the reader. Put your work in a view module, and give it with `--view`.
+
+To show the reader's words, the view exports `state(vars)`. The value that `state()` returns picks the form:
+
+- A string gives a flat chart: `export const state = (v) => (v.paid ? "Paid" : "Paying");`
+- An array gives parent states: `export const state = (v) => v.main.split(".");`
+- An object gives one parallel region for each key: `export const state = (v) => ({ Playback: v.playback, Volume: v.volume });`
+
+Label each state with what the reader can see or cares about, such as "Paying" or "Lease held, write pending". Keep variable names out of labels. In `vars`, a TLA+ sequence is an object with keys from 1, so `v.pc[1]` is `pc[1]`. A set is an array.
+
+The view can also export `step(action, from, to)`. It gets the TLC action name and the values before and after the step, and it returns the label of the arrow. Write each step label as the user sees it happen, such as "you press play" or "the connect fails". Do not name the code or the TLA+ action. Two actions that end the same in the chart get the same label, so that they share one arrow.
+
+When a step can occur only in some conditions, end its label with the condition in brackets, in the reader's words, such as `you press play [while the file loads]`. In a regions chart, the command writes the condition on the other regions on the arrow, in the words of their labels, such as `[when Offline]`. Your brackets replace it, and two arrows from one state can then look the same. So in a regions chart, do not write brackets for a condition on another region. When a value that no label shows decides where a step goes, name the result in the label, such as "the roster read fails".
+
+The view can also export these:
+
+- `group(vars)` returns the name of a phase. Each chart state gets the color of its group. When the model states behind one chart state are in different groups, that state gets no color.
+- `colors` gives each group name a color class.
+- `title` is a string that the chart shows at the top.
+
+The command calls `state()` and `group()` at most once for each model state, and `step()` at most once for each step. The chart and the report both use those answers. So make each function depend only on its arguments.
+
+The chart does not draw a step that stays in one label. Split a label when the reader must see such a step.
+
+Aim for about 20 arrows or fewer, because a busier chart is hard to read. First return coarser labels from `state()`. Give one label to values that act the same, and leave out a detail that the reader does not need, such as a call in flight whose return changes nothing. Keep each state of a bug path, and keep each mark. When a merge changes a `breaks` state to `mayBreak`, it hides where a rule breaks. Do not merge two states that break different rules, because the reader then cannot see which rule breaks where. If the chart is still too busy, return `null` from `step()` for the steps that the reader does not need, such as a reset that every state has, or a step whose arrow repeats what other arrows show. Obey these rules when you hide steps:
+
+- Keep each chart state reachable by arrows from a start state.
+- Keep at least one arrow out of each chart state that has a step out in the model.
+- Hide all the steps of an arrow, or none of them. When you hide only some, its condition gets narrower.
+- In the hand-off, say which steps the chart hides.
+
+## Read the report
+
+- In the chart, a state that breaks a rule has the class `breaks`. When only some model states behind it break the rule, it has the class `mayBreak`. The Legend names the rules of each mark. When two rules break, it names both on one mark, so say in the hand-off which state breaks which rule. In a regions chart, a state gets a mark when each combination of region states that includes it can break a rule. When a combination can break a rule and none of its states has a mark, each state in that combination gets a mark.
+- TLC goes past a state that breaks a rule, so the chart shows the states after a bug.
+- Because TLC goes past bugs, a model with no limit on its states can run without end. Keep the constants small, or add a CONSTRAINT.
+- With a VIEW or a SYMMETRY, TLC counts states that it treats as the same as one state, and the chart draws that one state. An arrow can lead to it rather than to the state that the step reaches, and the report says so.
+- TLC checks the rules in each state past a CONSTRAINT or an ACTION_CONSTRAINT, but it does not explore that state or check it for deadlock. When TLC's shortest path for a rule ends in such a state, the chart draws that state, and the report gives that path. The chart does not draw the other states past the bound. A deadlock in such a state does not show. TLC also checks the rules after each step that an ACTION_CONSTRAINT excludes, also when it reaches the next state another way. When TLC's shortest path for a rule ends with such a step, the chart draws that step.
+- The command checks the rules with TLC on the config as written, with one worker. When a rule breaks, the command removes that rule and runs TLC again, until no rule breaks. After the first break, each run stops at 100,000 distinct states, so that a large model does not run without end. When a run reaches that bound or stops on an error, the report lists the rules that it did not check under "Rules not checked", and the chart does not mark them. A rule that is not checked can hold or break. To check it, remove the rules that break from the config, or make the model smaller. The bound adds a module that changes TLC's order of the variables, so for a property TLC can find a different counterexample than a run without the bound.
+- `tlc.out` is what TLC printed on the config as written. When the chart does not show the bug path of a rule that breaks, `tlc-RULE.out` is what TLC printed for the run that found it. When TLC repeats its first warning, plain TLC prints it twice, but `tlc.out` shows it once, because TLC leaves the second copy out of the output that this command reads. That happens only when Java runs with `-XX:+UseParallelGC`, since otherwise TLC's first warning is its advice to pass that flag, which it prints once.
+
+## Show the chart
+
+Show `chart.mmd` to the user as a `mermaid` code block. The chart has a budget of 500 states, counted by TLC on the config as written. Above that, the chart draws only the paths to the rules that break, and when no rule breaks, the command writes no `chart.mmd`. It still checks each rule, and the report gives the state count and each bug path. To see the whole graph, make the model smaller.
+
+Render charts with Pele. When the user asks for an image, or a chart is too large to read as text, follow `references/render.md`. Do not use a different renderer unless the user asks for it.
+
+## Hand off
+
+Give each chart and its Mermaid text to the person who must decide. Add one line for each bug: the rule, the reader's sentence for that rule, and the path as the report numbers it. Say what the model leaves out. Give the command that makes the files again, with a new `--out` folder.
+
+When the model describes code, replay each bug path against the real code, as a test or a live repro, one step for each action. If a bug does not occur, think that the model is wrong until you show that it is not.
+
+
+## Pi execution tools
+
+Use `pstack_agents` for one child and `pstack_workflow` / `pstack_graph` for an explicit DAG. Roles are `architect`, `worker`, `reviewer`, `verifier`, `synthesizer` and `integrator`. Parallel writers use isolated worktrees, then an integrator. A verifier directly depends on the artifact owner. Inspect workflow status on recovery; completed nodes are not replayed. Check remote state before retrying external effects. `pstack_worktrees` cleans only owned clean worktrees.

package/skills/statechart/references/render.md

@@ -0,0 +1,93 @@
+# Render a chart
+
+Render each `.mmd` file that you show with the npm package `pele@1.9.0`, and give the user the SVG. Install Pele once, outside the repo. Write each SVG next to its `.mmd` file, with the same name. The API is at https://pele.run/api. Pass `{ limit: 1_000_000, outputLimit: 8_000_000, maxEdges: 10_000 }` as the options of `render`. Pele's defaults are smaller than a chart of 500 states can be. When Pele throws a `PeleError`, show the user the Mermaid text and the error.
+
+## Colors
+
+Pele ignores Mermaid `theme` and `themeVariables`. Set its `--pele-*` CSS variables on `.pele`. https://pele.run/theming lists them. The command gives each state the color class of its group, such as `class sN teal`. It marks each bad state with `class sN breaks` or `class sN mayBreak`, each state on the shortest path to a bug with `class sN bugPath`, and each state that a PROPERTY counterexample repeats forever with `class sN repeats`. Pele puts these classes on the state's node. Color the classes with CSS.
+
+The `.mmd` file has a `classDef` line for `breaks` and for `mayBreak`, so that any Mermaid viewer shows the bug marks. It has no `classDef` for the group colors, `bugPath`, or `repeats`. Pele writes each `classDef` color as a `style` attribute on the node, and a `style` attribute wins over a normal CSS rule. So the rules for the marks below use `!important`. Without it, a dark theme keeps the light mark colors. A bug mark sets the fill and the text, and `bugPath` and `repeats` set the border. Put the mark rules after the group colors, so that a mark shows over the group color.
+
+These colors are suggestions. They are the colors of the old skill. Put them in a `<style>` element at the start of each SVG. Each SVG then follows the light or dark setting of the viewer.
+
+```css
+.pele {
+  --pele-bg: #ffffff;
+  --pele-fg: #1c1c1c;
+  --pele-muted: #656565;
+  --pele-line: #808080;
+  --pele-surface: #fcfcfc;
+  --pele-surface-alt: #f1f1f1;
+  --pele-border: #c9c9c9;
+}
+.pele .blue rect { fill: #c3e0ff; }
+.pele .orange rect { fill: #f0d3bf; }
+.pele .purple rect { fill: #e3d5ff; }
+.pele .yellow rect { fill: #f0dcbf; }
+.pele .teal rect { fill: #bfe3df; }
+.pele .tan rect { fill: #e5d9ce; }
+.pele .pink rect { fill: #ffcbe6; }
+.pele .breaks rect {
+  fill: #ffecee !important;
+  stroke: #e72e3b !important;
+  stroke-width: 2.5px !important;
+}
+.pele .breaks text {
+  fill: #cd2834 !important;
+}
+.pele .mayBreak rect {
+  fill: #fff3e6 !important;
+  stroke: #e8730c !important;
+  stroke-width: 2.5px !important;
+}
+.pele .mayBreak text {
+  fill: #b85a06 !important;
+}
+.pele .bugPath rect {
+  stroke: #1680f3 !important;
+  stroke-width: 2.5px !important;
+}
+.pele .repeats rect {
+  stroke: #9b35d6 !important;
+  stroke-width: 2.5px !important;
+  stroke-dasharray: 6 3;
+}
+@media (prefers-color-scheme: dark) {
+  .pele {
+    --pele-bg: #1f1f1f;
+    --pele-fg: #f5f5f5;
+    --pele-muted: #acacac;
+    --pele-line: #939393;
+    --pele-surface: #121212;
+    --pele-surface-alt: #2c2c2c;
+    --pele-border: #4e4e4e;
+  }
+  .pele .blue rect { fill: #1b3857; }
+  .pele .orange rect { fill: #573117; }
+  .pele .purple rect { fill: #3c2e57; }
+  .pele .yellow rect { fill: #573d17; }
+  .pele .teal rect { fill: #174641; }
+  .pele .tan rect { fill: #3d3127; }
+  .pele .pink rect { fill: #57233e; }
+  .pele .breaks rect {
+    fill: #2e2021 !important;
+    stroke: #cf2b35 !important;
+  }
+  .pele .breaks text {
+    fill: #ff6463 !important;
+  }
+  .pele .mayBreak rect {
+    fill: #2e2619 !important;
+    stroke: #d0700f !important;
+  }
+  .pele .mayBreak text {
+    fill: #ffa257 !important;
+  }
+  .pele .bugPath rect {
+    stroke: #116dd2 !important;
+  }
+  .pele .repeats rect {
+    stroke: #9a3fcf !important;
+  }
+}
+```

package/skills/statechart/scripts/backends/cfg.ts

@@ -0,0 +1,33 @@
+import { CHART_STATES, type ConfigSection, RERUN_STATES, type Spec } from "../ir.ts";
+
+export function configText(sections: ConfigSection[], extra: string[]) {
+  const lines: string[] = [];
+  for (const s of sections) lines.push(`${s.key} ${s.tokens.join(" ")}`);
+  lines.push(...extra);
+  return lines.join("\n");
+}
+
+export const boundRun = (module: string) =>
+  [
+    `---- MODULE ChartBound ----`,
+    `EXTENDS ${module}`,
+    `ChartTLC == INSTANCE TLC`,
+    `ChartNaturals == INSTANCE Naturals`,
+    `ChartBound == ChartNaturals!<(ChartTLC!TLCGet("distinct"), ${RERUN_STATES})`,
+    `====`,
+  ].join("\n");
+
+export function chartRun({ module, variables, invariants }: Spec, tag: string) {
+  const every: string[] = [];
+  for (const name of invariants) every.push(`(IF ~${name} THEN {"${name}"} ELSE {}) \\cup `);
+  return [
+    `---- MODULE ChartRun ----`,
+    `EXTENDS ${module}`,
+    `ChartTLC == INSTANCE TLC`,
+    `ChartNaturals == INSTANCE Naturals`,
+    `ChartBudget == ChartNaturals!<=(ChartTLC!TLCGet("distinct"), ${CHART_STATES})`,
+    `ChartBroken == ${every.join("")}{}`,
+    `ChartMark == ChartBroken = {} \\/ ChartTLC!PrintT(<<"${tag}", <<${variables.join(", ")}>>, ChartBroken>>)`,
+    `====`,
+  ].join("\n");
+}