rpi ยท diff
git:20260909.6f499fb to git:20260909.600c2eb
75 added, 88 removed. Audit A to A.
---
name: rpi
description: 'Own an authorized outcome through implementation, checks and fresh final validation; load planning and memory only when useful. Triggers: "run rpi", "run one traversal", "execute this plan", orchestration or worker delegation that implements changes.'
practices:
- bdd-gherkin
- tdd
- design-by-contract
hexagonal_role: domain
consumes:
- plan
- implement
- validate
produces:
- rpi-report.v1
context_rel:
- kind: customer-of
with: plan
- kind: customer-of
with: implement
- kind: customer-of
with: validate
skill_api_version: 1
user-invocable: true
metadata:
graph_root: true
tier: meta
dependencies: [plan, implement, validate]
capabilities: [own_authorized_outcome, report]
effects: [dispatch_core_phases]
canonical_status: canonical
disposition: keep
output_contract: 'concise human-readable result; optional rpi-report.v1 when a caller or declared consumer requests machine-readable evidence'
---
# RPI
Own the authorized outcome through finish. Use the native coding agent and
- shell; BD or the caller's tracker owns work/status/handoffs, Git owns content
- and delivery history. Keep one authoritative work account. AgentOps adds a
- small operating charter and fresh judgment, not a scheduler or a second queue.
+ shell. BD or the caller's tracker owns work and handoffs; Git owns content and
+ delivery. AgentOps supplies a small charter and fresh judgment, not a scheduler.
## Operating charter
- 1. Keep the accepted outcome, scope and real bounds in view. Use the existing
- intent; a trivial clear change needs no Plan, Recall or Learn worksheet.
- 2. Take the smallest action that advances acceptance or resolves a consequential
- uncertainty. Load [Plan](../plan/SKILL.md) only when intent or approach needs
- shaping. Evidence may disprove an assumption: revise the approach within
- unchanged accepted outcome and scope. Acceptance changes need caller authority.
- 3. [Implement](../implement/SKILL.md) the change and repair ordinary known
- defects directly. A failed check with an understood cause is implementation
- work, not a reason for another plan, council or helper.
- 4. Use cheap discriminating checks during edits, then the required integration
- checks. Preserve valid exact-input receipts. Reserve finishing capacity for
- integration, fresh final judgment, repairs and a truthful handoff. Complete
- required checks and known repairs before dispatching final judgment, then
- keep that subject unchanged until the review returns.
- 5. Obtain [Validate](../validate/SKILL.md) in a fresh author-distinct context over
- the exact final subject. Default to the author's model family; cross-model
- review is opt-in. There is no fixed ten-minute cap. Required caller-selected
- reviewers remain required. Every necessary finding stays visible.
- 6. Repair actionable findings within authority and real remaining bounds, then
- obtain fresh judgment over the changed subject. Stop at completed acceptance,
- cancellation, an explicit refusal, a spent real bound, or a genuine causal
- stall that the bounded help below cannot resolve. Activity, saved pages,
- changed digests and repeated reviews are not completed capability.
-
- ## Causal stall and bounds
-
- Unknown cause, recurrence, no progress or evidence of the wrong objective calls
- for causal examination. A genuine causal stall admits **at most one bounded
- fresh helper** for that incident, when authorized and within remaining bounds.
- Give it the failed assumption, evidence and one discriminating question. Resume
- only when the answer supplies a different testable approach; an unhelpful answer
- ends the attempt with the unresolved facts. Do not create a helper chain or
- rename the same incident to obtain another helper. Known failures get direct
- repair. Cancellation, refusal and spent hard time/cost/quota skip help.
-
- Respect actual caller/native limits, including an explicit repair-round bound
- when supplied; no invocation, compaction, helper or new subject renews them.
- A retry count alone is not a spent time or quota budget. Keep compact recovery
- state only when interruption threatens evidence: accepted intent, exact current
- subject, useful receipts, unresolved cause, bounds and helper use, in the native
- handoff source. Prompt text is no proof of native enforcement.
- [Outer-goal guidance](references/outer-goal.md) is optional and outside the core.
+ 1. Use the existing accepted outcome, scope and real bounds. A clear change
+ needs no Plan, Recall or Learn worksheet. Resolve uncertainty only when it
+ could change the implementation or acceptance decision.
+ 2. Take the smallest acceptance-advancing action. [Plan](../plan/SKILL.md)
+ shapes missing intent or revises a disproved approach. Once an implementer
+ can act and a validator can judge, implement; do not keep improving the plan.
+ Approach revisions preserve acceptance and authorized scope.
+ Acceptance changes need caller authority.
+ 3. [Implement](../implement/SKILL.md) and repair ordinary known defects directly.
+ A known test failure needs a fix and a discriminating check, not another
+ planning phase, council or helper.
+ 4. Use focused checks during edits and complete required integration checks
+ before final judgment. Reuse valid exact-input receipts; rerun affected
+ checks after changes. Reserve capacity for integration, review and repair.
+ Keep the final subject unchanged while it is being judged.
+ 5. Obtain [Validate](../validate/SKILL.md) from one fresh author-distinct context
+ in the author's model family unless the caller selects required additional
+ legs. There is no fixed ten-minute cap; explicitly required
+ reviewers remain required. Risk deepens evidence, not reviewer multiplication. Repair
+ actionable findings within authority and remaining bounds, then revalidate
+ the changed exact subject.
+ 6. Stop at completed acceptance, cancellation, refusal, a spent real bound or
+ an unresolved causal stall after the help below. Adjacent improvements are
+ not permission to expand the goal. Report them briefly only when useful;
+ do not turn them into another work batch.
- ## On-demand tools
+ ## Context and handoffs
- - Plan shapes missing intent or revises an approach falsified by evidence.
- - Implement owns edits, direct repairs and factual checks.
- - Validate owns fresh exact-subject judgment; the author cannot issue binding PASS.
- - [Memory](../memory/SKILL.md) recalls applicable reviewed topic pages, or performs
- separately budgeted mining and curation when requested. It is never an entry
- or completion toll. No-match and no-change are valid.
+ Load required contracts once per context, then inspect the source or evidence
+ needed for the next decision. A reference link is available context, not a
+ reading list. Search before opening large files; retrieve relevant sections
+ and expand when uncertainty requires it. Do not reread unchanged material or
+ copy full logs into successive tool results and handoffs.
- Specialists, including anti-ceremony, premortem, council, research and runtime
- adapters, remain optional. Risk increases evidence depth; it does not mandate a
- specialist dispatch. Read [boundaries](references/boundaries.md) when a source,
- review or delivery boundary matters; do not turn the charter into another packet.
+ When delegation is authorized and useful, give each worker task-specific
+ context: accepted intent and scope, exact subject, relevant evidence, remaining
+ bounds and the requested result. Prefer a new task-only context for an
+ independent subtask; resume the original worker for a direct repair when useful.
+ Validators always receive fresh context, without the author's desired verdict.
+ Use observed runtime capabilities; prompt wording does not prove isolation.
- ## Evidence and report
+ Return concise findings, check facts and accessible evidence references. Keep
+ full logs available, showing only decision-relevant excerpts; disclose truncation
+ or missing evidence. Reuse one caller-owned handoff instead of multiplying
+ plans, receipt summaries and status documents. Machine evidence such as `verdict.v2` is optional
+ unless requested or required by a declared consumer. When no machine
+ artifact is requested or required, return the result without creating one.
- Bind the accepted intent and exact subject for the fresh validator, derive
- complete changed paths and factual check receipts, and disclose orphaned
- acceptance evidence when the change affects it. Use the existing provenance
- helpers described in Validate; new proof uses caller-selected protected external
- non-Git storage. Preserve legacy `.agents/` evidence. Do not invent an identity
- or treat a model's declared role as freshness. Missing freshness or necessary
- evidence means NOT_PROVEN; proven acceptance failure means FAIL.
+ ## Causal stall and bounds
- Return the caller-visible result, changed subject, strongest checks and material
- unchecked acceptance. PASS requires all acceptance, exact identity and empty
- `not_checked`; the report never hides remaining work. `NOT_PLANNED` and
- `NOT_BUILT` describe progress, not semantic judgment. Do not append a next action
- as a substitute for finishing authorized work. The interactive response is the
- default; persist `verdict.v2` or `rpi-report.v1` only when the caller requests
- machine-readable evidence or a declared consumer requires it. When no machine
- artifact was requested, do not create a hidden one.
+ Unknown cause, recurrence, no progress or a wrong objective admits
+ at most one bounded fresh helper for that incident within authority and bounds.
+ Give it the failed assumption, evidence and one discriminating question. Resume
+ only with a different testable approach; an unhelpful answer ends the attempt.
+ Do not chain helpers or rename the incident. Known failures get direct repair.
+ Cancellation, refusal and spent hard time/cost/quota skip help.
- ## Prompt
+ Respect actual caller/native limits, including explicit repair-round bounds.
+ Retries, compaction, helpers and new subjects never renew them; retry count
+ alone is not a spent budget. If interruption threatens evidence, preserve
+ accepted intent, exact subject, useful receipts, unresolved cause, bounds and
+ helper use in the native handoff. Prompt text proves no native enforcement.
+ [Outer-goal guidance](references/outer-goal.md) remains optional.
- ```text
- Use rpi to finish this accepted change within its scope and remaining deadline.
- Repair understood failures directly. If an assumption fails, revise the approach
- without changing acceptance. Run required checks and obtain fresh final Validate.
- Use Memory only if an applicable prior constraint would change the next action.
- ```
+ ## Evidence and boundaries
- ## It's working if
+ Bind accepted intent, complete changed paths, exact subject and factual receipts
+ for the fresh validator; disclose affected orphaned acceptance evidence. Use
+ existing provenance helpers rather than a new evidence format. Requested proof
+ uses caller-selected protected external non-Git storage; preserve legacy
+ `.agents/` evidence. Missing identity, freshness or proof means NOT_PROVEN;
+ proven failed acceptance or scope violation means FAIL. PASS needs every
+ criterion verified and empty `not_checked`. Authors cannot issue binding PASS.
- A clear small edit reaches checks without planning or memory paperwork; an
- understood test failure is fixed directly; a disproved assumption changes the
- approach; an unknown recurring failure gets no helper chain; the final exact
- subject receives fresh author-distinct judgment and the report states any gap.
+ [Memory](../memory/SKILL.md), specialists and runtime adapters are on demand;
+ no-match and no-change are valid. Read [boundaries](references/boundaries.md)
+ when authority, scope, evidence or delivery is at issue. The optional
+ [fixed-dispatch adapter](references/bounded-adapter.md) is not the native
+ execution engine. Do not invent a runtime, hidden machine artifact or workflow
+ to finish an ordinary change.
- The grandfathered developer-only Python reference is an optional fixed-dispatch
- adapter with explicit repair rounds, not the native charter's execution engine.
- Its narrower [adapter contract](references/bounded-adapter.md) and tests remain
- available without adding a runtime, command, scheduler or mandatory worksheet.
+ Report the result, strongest checks and material limits. Plans, activity,
+ reviews and saved pages earn no capability credit; NOT_PLANNED and NOT_BUILT
+ are progress descriptions, not semantic verdicts.