@oevery/rsp 3.2.0 → 4.0.0

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.
Files changed (68) hide show
  1. package/README.md +25 -17
  2. package/README.zh-CN.md +25 -17
  3. package/dist/chunk-HFSTLCCK.mjs +3968 -0
  4. package/dist/cli.mjs +3510 -2446
  5. package/dist/entry-RIJQ2X46.mjs +1932 -0
  6. package/package.json +32 -19
  7. package/skills/rsp/SKILL.md +42 -68
  8. package/skills/rsp/references/closeout.md +38 -0
  9. package/skills/rsp/references/context-migration.md +22 -0
  10. package/skills/rsp/references/control-outcome.md +5 -0
  11. package/skills/rsp/references/coordination-recovery.md +25 -0
  12. package/skills/rsp/references/coordination-review.md +15 -0
  13. package/skills/rsp/references/coordination.md +59 -0
  14. package/skills/rsp/references/durable-review.md +74 -9
  15. package/skills/rsp/references/focus-continuation.md +13 -0
  16. package/skills/rsp/references/groups-dependencies.md +6 -4
  17. package/skills/rsp/references/response-language.md +13 -0
  18. package/skills/rsp/references/setup-repair.md +37 -7
  19. package/skills/rsp/references/work-model.md +27 -0
  20. package/skills/rsp-commit/SKILL.md +82 -22
  21. package/skills/rsp-commit/references/message.md +34 -0
  22. package/skills/rsp-doc/SKILL.md +65 -0
  23. package/skills/rsp-doc/agents/openai.yaml +3 -0
  24. package/skills/rsp-doc/references/artifact-lenses.md +43 -0
  25. package/skills/rsp-doc/references/release-communication.md +39 -0
  26. package/skills/rsp-doc/references/skill-authoring.md +36 -0
  27. package/skills/rsp-implement/SKILL.md +62 -21
  28. package/skills/rsp-implement/references/diagnosis.md +10 -0
  29. package/skills/rsp-implement/references/finding-resolution.md +21 -0
  30. package/skills/rsp-implement/references/test-first.md +7 -0
  31. package/skills/rsp-review/SKILL.md +44 -46
  32. package/skills/rsp-review/references/code-review.md +23 -7
  33. package/skills/rsp-review/references/document-review.md +25 -8
  34. package/skills/rsp-review/references/release-communication.md +21 -0
  35. package/skills/{rsp-structural-audit/references/structural-lenses.md → rsp-review/references/structural-review.md} +5 -5
  36. package/skills/rsp-shape/SKILL.md +24 -45
  37. package/skills/rsp-shape/references/complex-shaping.md +3 -1
  38. package/skills/rsp-shape/references/deep-clarification.md +4 -4
  39. package/skills/rsp-shape/references/domain-modeling.md +13 -0
  40. package/skills/rsp-shape/references/module-seams.md +13 -0
  41. package/skills/rsp-shape/references/planning.md +42 -0
  42. package/skills/{rsp-design → rsp-shape}/references/reversible-exploration.md +2 -2
  43. package/skills/rsp-verify/SKILL.md +72 -0
  44. package/dist/chunk-JOMFFQRG.mjs +0 -99
  45. package/dist/chunk-JYDEJEM4.mjs +0 -358
  46. package/dist/chunk-SEGJLWRE.mjs +0 -1158
  47. package/dist/chunk-ZORUJTVS.mjs +0 -1967
  48. package/dist/entry-I22OUIW5.mjs +0 -888
  49. package/dist/entry-RG6HREUN.mjs +0 -174
  50. package/rules/rsp-rules.md +0 -47
  51. package/skills/rsp/references/managed-routing.md +0 -44
  52. package/skills/rsp/references/release-operations.md +0 -9
  53. package/skills/rsp-design/SKILL.md +0 -53
  54. package/skills/rsp-design/references/domain-modeling.md +0 -11
  55. package/skills/rsp-design/references/module-seams.md +0 -11
  56. package/skills/rsp-diagnose/SKILL.md +0 -46
  57. package/skills/rsp-manage/SKILL.md +0 -96
  58. package/skills/rsp-manage/references/closeout.md +0 -11
  59. package/skills/rsp-manage/references/interruption-recovery.md +0 -7
  60. package/skills/rsp-manage/references/review-convergence.md +0 -7
  61. package/skills/rsp-release-docs/SKILL.md +0 -77
  62. package/skills/rsp-release-docs/references/convention-discovery.md +0 -65
  63. package/skills/rsp-release-docs/references/evidence-and-surfaces.md +0 -21
  64. package/skills/rsp-release-docs/references/output-contracts.md +0 -97
  65. package/skills/rsp-release-docs/references/publication-lifecycle.md +0 -24
  66. package/skills/rsp-resolve-findings/SKILL.md +0 -61
  67. package/skills/rsp-structural-audit/SKILL.md +0 -71
  68. package/skills/rsp-tdd/SKILL.md +0 -48
@@ -1,19 +1,84 @@
1
1
  # Durable writeback decision
2
2
 
3
- Load this reference only after required Tasks and implementation verification pass, or when auditing archive readiness.
3
+ Load for a necessary stable-knowledge update or preparation/audit of lifecycle or terminal delivery. Passing Tasks/checks or resuming work alone does not activate it. An evidence-only Tasks/Verify refresh with accurate scope, contract, design and stable knowledge stays in Core's direct path; it neither establishes closeout eligibility nor skips separately required Review.
4
4
 
5
- This operation is the durable writeback decision, not implementation verification and not fixed-scope change review. Implementation verification supplies fresh evidence after mutation. Fixed-scope change review is a report-only comparison owned by Review and is required only when explicitly requested, required by nearer authority or risk, or needed to derive managed `review-clean`; it is not automatically required for every tiny direct action. The durable writeback decision is always required before archive and independently decides current-fact and Decision Record updates. It never substitutes for fixed-scope change review.
5
+ ## Establish the evidence boundary
6
6
 
7
- Run `rsp check --focused` and `rsp show --focused --json`, or `rsp ready <name> --json` for an explicit Change. Treat `durableReview.factCandidateTargets` and `decisionRecordsPath` as routing advice, not permission. Spec delta markers are planning aids and are never promoted automatically.
7
+ For routine writeback, establish the relevant facts, update justified knowledge using the methods below, reconcile only affected Change sections when tracked, and check those edits. Preserve ongoing plans and unfinished work; this does not trigger final whole-Change convergence, readiness or closure. Before archive, current-fact and Decision Record decisions are both required. Keep these evidence owners separate:
8
8
 
9
- Choose current facts and rationale independently. Use no update when there is no stable fact or lasting rationale worth rereading.
9
+ - Implementation verification supplies applicable evidence for the final content, reusing unchanged coverage and rerunning affected checks after mutation.
10
+ - Review owns fixed-scope, report-only comparison. Use it when explicitly requested, required by nearer authority or risk, or needed by the selected acceptance; tiny direct actions do not automatically need it.
11
+ - Durable writeback decides what belongs in current facts or lasting rationale. It never substitutes for implementation checks or a required Review.
10
12
 
11
- Write a current-fact update only when implementation changed a stable behavior, boundary, default, or constraint that future maintainers need. Prefer the smallest existing domain Spec, `.rsp/specs/design.md` for project-wide boundaries/navigation, or an explicitly authorized scoped `CONTEXT.md`/`AGENTS.md`; create a new Spec only for reusable project-level truth that fits nowhere existing.
13
+ Inspect existing evidence and the selected Change when tracked. Use `rsp ready <name> --json` when current readiness or durable target advice is needed; obtain fresh readiness immediately before an authorized archive. Do not query readiness twice merely for separate writing and delivery roles. Treat `durableReview.factCandidateTargets` and `decisionRecordsPath` as routing advice, not permission. Spec delta markers are planning aids and are never promoted automatically.
12
14
 
13
- Create or update a Decision Record only for a hard-to-reverse or surprising choice with a real tradeoff. It owns rationale, alternatives, tradeoffs, and consequences—not duplicated current facts. Choose one exact file under `durableReview.decisionRecordsPath`, not the directory itself.
15
+ When a diagnostic tool fails, inspect its cause and effects. Use another permitted read/search method for the same authoritative artifacts. Do not replace named required checks, infer readiness from manual reading or mutate protected RSP files to obtain a gate. Missing decisive migration, structural or verification evidence leaves dependent closeout incomplete.
14
16
 
15
- Never use generated indexes, archives, `.rsp/rsp-rules.md`, or the managed RSP block as ordinary writeback targets. Keep narrative history, debugging notes, task chronology, and transient evidence out of Specs and Decisions.
17
+ If inspection reports only `RSP project requires an update` without update authority, do not run `rsp update`. Preserve supported implementation and verification outcomes; report affected knowledge, readiness or delivery gaps. Archive requires current readiness. Commit may assess a separately authorized checkpoint against its exact boundary and required evidence; it stops if that evidence is affected or unavailable. Other inspection failures and required checks remain unresolved.
16
18
 
17
- Before archive, compress the Change to current design, completed outcomes, decisive evidence, omissions, remaining risks, and blockers. Archive only after required writeback is complete or explicitly unnecessary and every separately required fixed-scope change review is clean. Ordinary work needs later explicit Git authority for one independently reviewable logical commit. A `manage.closeout` preset applies only when Core selected and qualified Manage for the current continuation; declined, unavailable, or unselected Manage leaves Core advisory and configuration executes neither archive nor commit. In a qualified managed continuation, lifecycle closeout is independent from Git and follows the effective ceiling: `manual` leaves archive advisory, while `lifecycle` or `local` permits `rsp archive <change-work-ref>` after the durable writeback decision unless nearer authority narrows it. For a shallow Group with lifecycle closeout, make the durable writeback decision and archive each child independently, re-derive completion, and run `rsp group close <group>` only after every child and Group gate passes. Inspect each complete lifecycle diff before deciding Git separately. `manual` and `lifecycle` grant no commit; `local` may justify recovery checkpoints and, after lifecycle closeout, requires one `rsp-commit` invocation for a terminal non-small Change or Group when owner, paths, fresh decisive verification, and a clean exact boundary are known and no nearer denial exists. Terminal small work defaults to no commit; ambiguous, mixed, stale, or denied boundaries stop without staging. A separately authorized release operation may use a dedicated release commit. Push remains separate and requires the user to mention it explicitly.
19
+ ## Close out in order
18
20
 
19
- When commit eligibility and authority exist, give `rsp-commit` one envelope containing the Change, Group/wave, or confirmed release owner, exact allowed paths, decisive evidence, lifecycle state, and current authority. If that Skill is unavailable, perform the same bounded manual action: reread nearest authority and owner; inspect staged, unstaged, and untracked paths, the cached diff, and recent non-merge messages; stop without staging on ambiguity or stale evidence; stage only allowed paths; re-inspect the complete cached boundary; derive a repository-consistent Conventional subject plus a proportionate body and truthful RSP trailers; create one local commit; then observe its complete message, paths, remaining worktree, and remote safety without amending or performing any external action.
21
+ Apply this sequence only for established final delivery or preparation/audit of closure. Routine knowledge updates use the bounded writeback above.
22
+
23
+ 1. **Verify outcome facts.** Establish the approved delivered result from current implementation, authoritative contracts and decisive evidence. Distinguish passed, failed, unverified and superseded conclusions. This establishes truth, not a preliminary full-document rewrite; plans and recovery notes alone cannot establish current facts.
24
+ 2. **Distill Focus as needed.** Integrate only verified outcomes, evidence applicability or material limits missing from Change; no useful addition means no edit. Recovery state alone supplies no required acceptance evidence.
25
+ 3. **Write back knowledge as needed.** Using the verified result and Change delta, decide current facts and lasting rationale independently using the methods below. Update existing owners only when justified. No stable change means no edit; a delivered contract that leaves its authoritative Spec stale requires correction before closeout. Do not copy the whole Change or its verification history into knowledge documents.
26
+ 4. **Converge the whole Change.** After necessary writeback, use `rsp-doc` and its artifact-lenses method when available to reconcile all six sections as one final document. Retain the delivered delta, relevant design, task outcomes, candidate-bound verification, material failures/limits and knowledge-update references; leave already-converged text unchanged. Reconcile superseded, misplaced or duplicate content. Keep process history in its report or conversation, Group integration conclusions in the Brief, and transient operation permissions distinct from product boundaries. Without Doc, perform the same bounded convergence locally without installation or replacing required Review.
27
+ 5. **Check final consistency, then archive when authorized.** Compare the final Change and knowledge owners with the verified result; an earlier review of another revision or a passing readiness command proves no text quality. Reuse applicable implementation/test evidence, check new knowledge/document edits, and fill only missing or invalidated coverage. Document-only writeback and archive preparation do not themselves invalidate code checks. Complete separately required Review before the archive gate below. Fix prose defects in scope, but return material contract or implementation contradictions to the decision, implementation or verification owner. Unresolved Required failures still block closeout.
28
+
29
+ These are dependency constraints, not persisted phases or mandatory separate tool calls. Edit only what needs writeback; required updates cannot be waived. Resolve stale statements from verified outcomes. Preserve settled planning, unrelated style and original evidence/verdict owners; add no no-op reports. Author checks establish no independent review.
30
+
31
+ Observe acceptance-critical commands separately by default. A batch must stop on failure and expose every result and exit status; trailing success proves no earlier pass. For a missing result, re-observe only that read-only or proven repeat-safe check by its declared method. Inspect effects before repeating mutations. Keep dependent lifecycle actions incomplete until required checks pass. Use existing document/link checks or known-path inspection instead of improvised general Markdown regex parsing. Ordinary reads may be batched.
32
+
33
+ ## Decide current facts and lasting rationale
34
+
35
+ Use no update when there is no stable fact or lasting rationale worth rereading.
36
+
37
+ Report actual knowledge updates, unresolved decisions and requested readiness conclusions concisely. Current-fact and Decision Record decisions remain independently required before archive, but routine no-op fields need not appear in the response. Include exact targets and decisive rationale when needed; a readiness report retains `yes | no`, gate evidence and blockers. Use the complete rendering below only for an explicit request or real technical consumer. Localize headings and labels while preserving the canonical values:
38
+
39
+ ```md
40
+ ## <localized Durable Decision heading>
41
+ - <localized Current facts label>: <No current-fact update needed | Update existing spec or scoped instruction | Create a new durable spec>
42
+ - <localized Current-fact target label>: <exact file path or N/A>
43
+ - <localized Facts to write label>: <durable facts or none>
44
+ - <localized Decision Record label>: <No Decision Record needed | Create or update a Decision Record>
45
+ - <localized Decision Record target label>: <exact file path or N/A>
46
+ - <localized Rationale to write label>: <lasting rationale or none>
47
+ - <localized Archive ready label>: <yes | no>
48
+ ```
49
+
50
+ This is a response-only decision summary, not a block to paste into Change or archive. Persist actual knowledge updates and material decisions in the appropriate existing sections; omit empty targets, transient readiness and authorization receipts unless a declared consumer requires them. In Chinese, for example, use `## 持久化决策`, `决策记录(Decision Record)`, and `可归档(Archive ready)`, not English labels alone. Compact presentation changes no decision or closeout gate.
51
+
52
+ ## Write current facts to their owner
53
+
54
+ Write only a changed stable fact that future maintainers need. Select the smallest existing owner; summarize and link rather than maintain the same rule twice:
55
+
56
+ - `README` owns introduction, usage and starting points, not duplicate specifications.
57
+ - `AGENTS.md` owns scoped operating rules, authority and checks, not product behavior.
58
+ - Authorized root or local `CONTEXT.md` owns canonical vocabulary, domain relationships and navigation, not implementation notes or session history. Define a term once in its domain and link it elsewhere.
59
+ - Specs own current capabilities, collaboration contracts, boundaries and necessary constraints, not code inventories or future plans. Domain contracts use their relevant Spec; project-wide architecture uses `.rsp/specs/design.md`. Keep design references when they define normative evidence.
60
+ - Change owns this outcome's delta, design, work and evidence, not a full baseline copy. Decision Records own significant choices, alternatives and consequences, not another current-contract definition. Archives retain historical evidence, not current authority.
61
+
62
+ Create a Spec only for reusable truth with no suitable existing owner.
63
+
64
+ For substantial authorized writeback, use `rsp-doc` when available. A partial or older installation may instead apply these local checks; neither method replaces required Review:
65
+
66
+ - State consumers/value, handoffs, observable behavior, invariants and limits that survive replaceable internals.
67
+ - New domain Specs may use Purpose, Boundaries, Contracts, Scenarios and Constraints as a scaffold. Domain headings and normative design references remain valid; neither table shape nor template conformity selects ownership.
68
+ - Include only useful discriminating scenarios; Given/When/Then is optional. Plain-prose hints may stay, but requirements and limits remain visible.
69
+ - Link rationale to its Decision Record and verification to the Change. Resolve Spec/code discrepancies before choosing the correction owner; code alone supplies no new promise.
70
+ - Check that the future reader can find and use grounded facts, understand conditions and unknowns, and follow valid references. Preserve meaning; do not rewrite existing Specs merely for matching headings.
71
+
72
+ ## Write lasting rationale when needed
73
+
74
+ Create or update a Decision Record only for a hard-to-reverse or surprising choice with a real tradeoff. It owns rationale, alternatives, tradeoffs and consequences, not duplicated current facts. Choose one exact file under `durableReview.decisionRecordsPath`, not the directory itself.
75
+
76
+ Never use generated indexes, archives, or the managed RSP block as ordinary writeback targets. Keep narrative history, debugging notes, task chronology, and transient evidence out of Specs and Decisions.
77
+
78
+ ## Prepare the Change for archive
79
+
80
+ Before archive, require the converged final Change, completed or unnecessary knowledge writeback, applicable passing verification, current readiness and every separately required Review clean. Authorized archive preserves Change and clears its Focus marker; clearing the Capsule cannot substitute for writeback. Archive grants no local commit authority.
81
+
82
+ ## Deliver with explicit boundaries
83
+
84
+ [Delivery closeout](closeout.md) owns checkpoint/final classification, the ask/auto/manual closure decision, Group-close sequence and exact Git handoff. Ordinary completion leaves work open. Apply the selected policy and current gates regardless of delegation. Git delivery separately needs explicit authority for one independently reviewable logical commit; closure grants none. Reuse applicable evidence.
@@ -0,0 +1,13 @@
1
+ # Focus and continuation recovery
2
+
3
+ Load when tracked work needs a recovery snapshot, a Capsule needs inspection or replacement, or a portable continuation handoff is required. Same-session worker continuation alone uses [coordinated interruption and recovery](coordination-recovery.md), not this format. Short direct tasks need no new WorkRef or Capsule.
4
+
5
+ Core owns the selected WorkRef's replaceable recovery snapshot. At a pause, handoff or recovery-relevant checkpoint, update it only when the Change, evidence and existing snapshot are insufficient for safe continuation. Retain the minimum current state, evidence pointers, next action and resume conditions. Ordinary same-session progress needs no update. Use `rsp focus <work-ref> --capsule-file <path|->` to replace, not append. Respect nearer mutation restrictions. For Group work use the selected child's Capsule, not a Group marker. Empty markers remain valid.
6
+
7
+ The existing v1 format is bounded to 4096 UTF-8 bytes: one leading `<!-- rsp-focus:v1 -->`, blank lines, exactly one non-empty single-line `Current`, `Evidence`, `Next`, and at most one non-empty single-line `Resume check`. No other non-empty lines are valid. Keep raw logs/diffs, runtime identifiers, host paths, credentials and execution history out. The marker path selects work; its notes grant no authority or acceptance and are never worker transport or controller state.
8
+
9
+ Before closeout, use the [durable-writeback sequence](durable-review.md): verify outcome facts, distill useful Focus facts and update stable knowledge as needed, then converge the whole Change and check final consistency before authorized archive. No useful Focus addition requires no edit; it waives neither necessary knowledge correction nor final Change convergence. Detailed evidence stays with its existing owner, never solely in the Capsule.
10
+
11
+ When accepted work remains, return a localized continuation with these semantic fields in order: `WorkOwner`, `Authority`, `Current state`, `Changed artifacts`, `Fresh verification`, `Blockers`, `Next action`. A Change WorkOwner uses its WorkRef; a Group WorkOwner uses its Group reference and direct child Changes. Preserve technical values; the continuation is not a second state store.
12
+
13
+ For same-session, cross-session or cross-device resume, follow [interruption and recovery](coordination-recovery.md#resume-from-effects-not-tool-status) before continuing from this snapshot. That method owns drift, evidence applicability, replay safety and re-establishing current authority and host facts.
@@ -1,12 +1,14 @@
1
1
  # Groups and dependencies
2
2
 
3
3
  Load this reference before creating, focusing, planning, or closing grouped or dependent work.
4
+ Use the same selected CLI throughout; `rsp` below denotes that invocation, not a request to fetch or install a package.
4
5
 
5
- - Executable WorkRefs are `<change>` or one direct `<group>/<change>` child. Deeper paths are unsupported.
6
- - Use a Change Group only for at least two independently executable Changes sharing a goal or completion contract. Create it with `npx -y @oevery/rsp group create <group> [goal]`, replace placeholders, and declare each direct child under `Slices` before creating it.
7
- - `<group>/brief`, stored as `<group>/00-brief.md`, is not executable or focusable. Read it before a selected child. Its declaration order guides navigation and its blockers are inherited as external blockers, not graph edges.
6
+ - Use the [shared work model](work-model.md) for Group and child identities when those definitions are missing from the current context.
7
+ - Use a Change Group only for at least two independently acceptable/deliverable Changes with dependencies or an integration obligation. Create it with `rsp group create <group> [goal]`, replace placeholders, and declare each direct child under `Slices` before creating it.
8
+ - The Brief is not focusable. Read it before a selected child. Its declaration order guides navigation and its blockers are inherited as external blockers, not graph edges.
9
+ - Group-level integration obligations belong in the Brief's `Completion Conditions`. Use a named `Integration:` condition for the durable boundary and record fresh integration evidence before marking it complete. A boundary supplied only by the current request is transient and cannot complete Group closeout until it is written back.
8
10
  - Declare an exact prerequisite only as `- requires \`<change-work-ref>\`: <reason>` under the dependent Change's `Blockers`. Targets must be executable Changes.
9
- - Use `rsp status --json` as the derived dependency view. `plan.nodes`, `ready`, `edges`, `blocked`, and `waves` are authoritative for the current inspection. Each edge means “change requires prerequisite”; filtered plans retain transitive prerequisite context.
11
+ - Use plain `rsp status` for the default semantic view and `rsp status --json` when exact dependency fields are needed. In the default JSON projection, `plan.nodes`, `plan.edges`, `plan.blocked`, and `plan.waves` are authoritative; the first non-empty wave is the current ready work. Each edge means “change requires prerequisite”; filtered plans retain transitive prerequisite context.
10
12
  - Do not infer nested ownership from the human dependency forest, create a parallel graph, or copy live delivery state into a Group Brief. Archived prerequisites resolve without rewriting dependents; incomplete inspection fails closed.
11
13
  - Archive children independently. Close the brief with `rsp group close <group>` only after every direct child and group completion gate passes.
12
14
  - Closed Group recovery never reuses its identity through `rsp group create` and never cascades into children or dependents. Core's direct reopen-recovery procedure owns the lifecycle sequence and exact retained-archive selection.
@@ -0,0 +1,13 @@
1
+ # Response and artifact language
2
+
3
+ Load this reference when the current action needs language selection beyond the Core routing summary.
4
+
5
+ Response prose is user/session-owned. Precedence: explicit current response-language instruction → user or host personal instructions → conversation language. Project `.rsp/config.yaml` never selects response language. Use natural-language narration for progress, phases, control results, receipts, stop reasons, and handoffs. Preserve an exact machine value unchanged only as a secondary parenthesized or code-formatted value.
6
+
7
+ Durable artifact prose is repository-owned. For a new authorized artifact: explicit artifact language → configured effective artifact language → artifact-scoped project instructions → conversation language. Existing artifacts retain their established language unless translation is explicitly authorized; configuration changes never rewrite them.
8
+
9
+ Commit-message prose: explicit current instruction → configured effective commit language → nearest repository authority → clear recent non-merge history.
10
+
11
+ When precedence needs configured RSP language, use the same selected CLI's successful `rsp config --json` summary, optionally `--compact`; the CLI resolves defaults and inheritance. Reuse it until relevant configuration changes or recovery requires refresh. Raw YAML and status do not resolve effective language. On failed or unavailable projection, diagnose without inventing values or silently dropping configured precedence. Only the dependent choice waits; existing-file preservation, explicit overrides and independently authorized work needing no unresolved setting may continue. Other configuration systems retain their own readers.
12
+
13
+ Preserve canonical headings, paths, commands, identifiers, WorkRefs, Conventional Commit types and scopes, trailers, severity labels, and machine values. Language and locale never rename or translate an existing WorkRef. Persistent prose belongs to the domain, system, user, or operator; mention AI or agents only when they are actual product actors or constraints.
@@ -1,11 +1,41 @@
1
1
  # Setup and repair
2
2
 
3
- Load this reference only before initializing, auditing, migrating, or repairing RSP-managed state.
3
+ Load before initializing, inspecting or updating RSP-managed assets.
4
4
 
5
- 1. Initialize with `npx -y @oevery/rsp init [--agents-mode managed|print] [--with-project-setup]`.
6
- 2. `--with-project-setup` creates and focuses `changes/project-setup.md`. Without it, create that Change only when explicit bootstrap tracking is still needed.
7
- 3. Put project-wide boundaries in `.rsp/specs/design.md`, use generated local `00-index.md` files only for direct-child navigation, put cohesive reusable facts in the smallest domain Spec, and keep stable operating instructions in the nearest project-owned `AGENTS.md` outside its managed block.
8
- 4. Diagnose with `npx -y @oevery/rsp doctor`. Apply only deterministic repairs with `doctor --fix` or `rsp update`; `fixed` entries are real filesystem mutations, while an empty list means nothing changed.
9
- 5. Do not use repair commands to decide stale focus, semantic durable updates, or archive readiness.
5
+ Use the runtime selected in AGENTS: an exact package pin in .rsp/version for
6
+ consumer projects, or this checkout's built CLI when .rsp/source explicitly
7
+ selects source mode. The two markers are mutually exclusive. An authorized package
8
+ upgrade deliberately selects its exact target CLI; source update keeps the local
9
+ selection. Never silently resolve @latest; package fetching requires separate authority.
10
10
 
11
- For manual audit, require `.rsp/`, managed roots, and nested Spec parents to be real directories. Require the project `AGENTS.md`, managed markers, fallback/config files, generated local `00-index.md` files, and placeholders to be regular files. Confirm the managed block, root and populated-directory Specs indexes, `specs/design.md`, configured Decision Record exclusion, valid group briefs and direct children, supported path depth, and focus markers matching executable Changes. Symlinks, special files, incomplete inspection, unrecognized reserved indexes, and file/directory identity collisions fail closed.
11
+ - **Initialize:** rsp init [--agents-mode managed|print] [--with-project-setup] creates missing scaffolding and the complete core suite. Existing user files remain unchanged. Retry an incomplete init with the same target; repeated init cannot adopt a different pinned version. Retired Rules require update instead.
12
+ - **Update:** rsp update replaces the selected package's owned assets; optional --dry-run previews without writes. No separate installation or migration switches are needed.
13
+ - **Inspect:** rsp doctor and rsp skills list are read-only. Only explicit doctor --check-updates queries stable metadata. Reports and notices grant no mutation authority.
14
+
15
+ ## Ownership and failure
16
+
17
+ Core Skill installation directories and exact retired Skill/Rules names are
18
+ package-owned: replace or delete them, including local changes. Preserve needed
19
+ customizations beforehand. Unknown Skills, config, Specs, work, archives, Decision
20
+ Records and Focus are user-owned; update does not rewrite or repair them. Missing
21
+ config values use read-time defaults. AGENTS changes are confined to its managed
22
+ block; write a consumer pin last, and never create one in source mode. Preserve
23
+ canonical maintainer links to package sources.
24
+
25
+ Only metadata-recognized generated indexes may be deleted from user knowledge
26
+ directories. Stop for owner-controlled reserved paths, invalid config, unexpected
27
+ symlinks or unsupported targets. Do not bypass validation or downgrade the pin.
28
+
29
+ Failure stops without whole-update rollback or recovery copies. Completed steps
30
+ remain applied. Inspect the reported failure, fix its cause and rerun the same exact
31
+ target command; do not infer completion or switch to the old pin's CLI midway.
32
+ Concurrent external edits and crash recovery are unsupported. No recovery entry exists.
33
+
34
+ ## Project knowledge
35
+
36
+ Keep architecture in .rsp/specs/design.md, contracts in domain Specs, navigation in
37
+ CONTEXT and scoped instructions outside the managed AGENTS block. Use rsp specs to
38
+ query knowledge. A legacy context map selects [context migration](context-migration.md);
39
+ discovery alone grants no merge or deletion. Semantic writeback and archive decisions
40
+ remain outside deterministic setup. Missing required Skills stop dependent work;
41
+ never fall back to retired Rules or install implicitly.
@@ -0,0 +1,27 @@
1
+ # Shared work model
2
+
3
+ Read when selecting, reporting or operating a tracked RSP owner and these definitions are not already available in the current context. Direct untracked work needs no RSP identity. This file defines identities, not a requirement to execute Core.
4
+
5
+ ## Work shapes
6
+
7
+ Direct work is a clear bounded request without durable continuity needs. Change retains one acceptance/delivery boundary for sustained work or recovery. Group coordinates independently acceptable/deliverable child Changes with dependencies or integration obligations. Complexity, file count and worker count alone select neither Group nor delegation. Agent topology is a separate execution choice.
8
+
9
+ Ordinary completion and checkpoint commits leave a Change open. Final delivery or an explicit close request uses the closeout policy; reopen is exceptional recovery, not the normal iteration path.
10
+
11
+ ## Identity and ownership
12
+
13
+ A WorkOwner is the selected owner of the requested work: a Change, or a Group for its coordination boundary. A direct untracked request retains its explicit scope without inventing a Change, Group or WorkRef.
14
+
15
+ A Change WorkRef is its logical name: `<change>` for an ungrouped Change, or `<group>/<change>` for a grouped child. Use that identity in commands, reports and ownership trailers. Its Markdown file is `.rsp/changes/<work-ref>.md`: a location for reading or evidence, never the WorkRef value. For example, `checkout/cache-ttl` identifies the child whose file is `.rsp/changes/checkout/cache-ttl.md`. Evidence may cite a file and line separately.
16
+
17
+ A Group reference is `<group>/brief` and resolves to `.rsp/changes/<group>/00-brief.md`; it names the Group, not an executable child Change. Identities are shallow; deeper nesting is invalid. Read its Brief for shared scope and dependencies, then select the actual child before child work. Do not substitute a Group reference, Brief path or directory for a child WorkRef. A Group-level judgment retains its Group reference and identifies the included direct child Changes.
18
+
19
+ An explicit user-selected owner wins over default focus discovery. Focus markers locate open-work candidates; multiple candidates alone are not a blocker. Resolve intent and relevant state rather than guessing ownership. Preserve existing work and its owner when changing scope.
20
+
21
+ ## Authority and evidence
22
+
23
+ Identity, focus, readiness, dependency state and capability availability grant no action authority. A Group Brief supplies context, not permission to implement every child. A completed check proves only its tested boundary; neither it nor a review report grants lifecycle completion, Git delivery, publication or approval. Each capability retains its own action and stop conditions.
24
+
25
+ In a Change's Blockers, record only unresolved dependencies or decisions preventing required work. Write standalone `None` when none remain; keep non-blocking verification limits in Verify. Exact prerequisites use ``- requires `<work-ref>`: <reason>``. Other prose, including an explanation after `None`, remains an external blocker declaration.
26
+
27
+ Use only the selected owner's relevant artifacts and authoritative project context. Installed files are shared across the suite, but separate workers do not inherit one another's loaded instructions. Reuse applicable definitions in the same context; obtain this file before depending on missing definitions. If the shared resource is unavailable, report an incomplete suite and stop identity-dependent actions rather than inventing a substitute or installing implicitly.
@@ -1,48 +1,108 @@
1
1
  ---
2
2
  name: rsp-commit
3
- description: Create one authorized, exact-scope local commit for an RSP-owned Change, Group wave, or confirmed release boundary with a repository-consistent structured message.
3
+ description: Inspect or create one authorized exact-scope local commit for direct, Change, integration, Group or release delivery. Preserve unrelated work; do not infer lifecycle, remote delivery or history-rewrite authority.
4
4
  license: MIT
5
5
  metadata:
6
6
  author: oevery
7
- version: "2026.07.28.2"
7
+ version: "2026.10.16.1"
8
8
  ---
9
9
 
10
10
  # RSP Commit
11
11
 
12
- Create one reviewable local commit after Core or qualified Manage has already derived the owner, allowed paths, decisive verification, lifecycle state, and commit authority. Skill availability grants none of those facts. Accept only one Change, one integration-coupled Group wave, one Group closeout, or one confirmed release commit boundary.
12
+ For tracked work, read the [shared work model](../rsp/references/work-model.md) when its identity and ownership definitions are missing from the current context. Use logical WorkRefs in commands and reports; cite file locations separately. Direct invocation needs no prior Core execution.
13
13
 
14
- Follow Core's response-versus-artifact language boundary for all user-visible control narration; when the response language differs, keep exact canonical values only as secondary parenthesized or code-formatted tokens.
14
+ Own exact local Git delivery, invoked directly or through Core. This default core capability grants no authority through availability. Readiness-only work stays read-only. Commit only with current local authority, one exact owned boundary and applicable passing verification.
15
15
 
16
- ## Audit the envelope
16
+ Responses follow explicit instruction, personal instructions, then conversation language; existing artifacts retain theirs. Commit prose follows explicit commit-language instruction, effective configuration, nearest repository authority, then clear recent non-merge style. Response language does not select it. Preserve commands, identifiers, Conventional types/scopes and trailers.
17
17
 
18
- Read nearest project authority, the relevant open Change, Group Brief and children, archive, or confirmed release owner, then inspect `git status`, staged, unstaged, and untracked paths, the cached diff, and recent non-merge commit messages. Recheck the supplied verification and lifecycle facts against current repository state.
18
+ Resolve needed RSP defaults/inheritance through the selected CLI's successful `rsp config --json`, refreshing on drift or recovery. Raw YAML is diagnostic only. Projection failure leaves dependent language unresolved before staging; history cannot replace it, while independent authorized inspection may continue. Resolve material conflicts with the owner.
19
19
 
20
- Stop without staging when the owner, allowed paths, commit authority, verification, lifecycle state, or logical boundary is missing, ambiguous, stale, or conflicts with unrelated work. Stop when an allowed path contains mixed owned and unrelated changes that cannot be staged without guessing. Never infer archive, Group closeout, commit, push, tag, publication, approval, amend, rebase, force-push, or history-rewrite authority.
20
+ ## Establish the delivery boundary
21
21
 
22
- ## Derive the message
22
+ Resolve the smallest request: kind, purpose, owner or summary, real included WorkRefs when relevant, exact paths, current local authority, applicable verification pointers and lifecycle evidence only when applicable. Derive these facts from direct user intent or Core's bounded handoff; do not require a transport schema or create a second source of truth.
23
23
 
24
- Choose subject and body prose language from explicit current commit-language instruction, then the configured effective commit language, nearest repository commit authority, and finally the clear style of recent non-merge commits. Response language and preferences remembered from another repository do not select it. Preserve Conventional Commit types/scopes and trailers as technical values. When recent history is materially mixed and no nearer rule resolves it, return the single language decision to its owner.
24
+ | Kind | Identity and applicable evidence | RSP trailers |
25
+ | --- | --- | --- |
26
+ | direct | One confirmed direct outcome permitted by project tracking rules | none |
27
+ | change | One real WorkRef | RSP-WorkRef |
28
+ | integration | At least two real WorkRefs and one evidenced shared delivery boundary | included RSP-WorkRef values |
29
+ | group | Group reference, included WorkRefs and one wave or closeout boundary | RSP-Group and included RSP-WorkRef values |
30
+ | release | Confirmed release identity and release-boundary evidence | only real included WorkRefs |
25
31
 
26
- Use the repository's established Conventional Commit form when present. Derive type and scope from the owned outcome and repository history, not from the conversation. Keep the subject concise and imperative or otherwise repository-consistent.
32
+ A durable owner is a Change WorkRef or Group reference; included children never replace it. Direct, integration and release may have no durable WorkOwner. Integration creates no Group, direct creates no Change, and commit count is independent from Change count.
27
33
 
28
- A tiny or mechanical boundary may be subject-only when that subject fully explains it. For a non-trivial Change, integration wave, Group closeout, or release commit, add two to four concise bullets covering:
34
+ Purpose is separate from kind:
29
35
 
30
- - the observable outcome;
31
- - material behavior or compatibility boundaries; and
32
- - an important omission or risk when one affects review.
36
+ - A checkpoint keeps the Change open and delivers a verified current slice without claiming completed acceptance, closing an issue or requiring archive.
37
+ - A terminal delivery claims completion only for its selected boundary. Tracked terminal inputs require complete Tasks, decisive Required Verify and no active blocker; legacy unclassified Verify is Required. Optional omissions remain explicit but do not block. Direct work uses its own acceptance, not an invented lifecycle gate.
33
38
 
34
- Do not copy file lists, command transcripts, routine verification output, execution chronology, or the full Change/archive. Add only truthful trailers: one `RSP-WorkRef:` per included WorkRef, `RSP-Group:` when the Group is the commit owner, authoritative external references already owned by the work, and `BREAKING CHANGE:` only for an actual breaking change. Never invent an issue, co-author, sign-off, breaking change, or AI attribution.
39
+ A generic commit request is a checkpoint unless final delivery is already established. For tracked final delivery, resolve the closure decision through [Core closeout](../rsp/references/closeout.md) before staging, including direct invocation; do not repeat an already settled decision. Commit pauses for its owning capability to perform necessary writing or authorized lifecycle work. Lifecycle authority stays upstream. If terminal delivery includes authorized archive or Group closeout, require that action and its inspected diff before staging. Do not archive, update Specs or clean up a Change inside Commit. A valid explicitly authorized local commit without lifecycle authority does not gain it or require an invented archive.
35
40
 
36
- Project every owned issue relationship as a non-closing `Issue: <canonical-url>` reference when proportionate. Only a terminal commit whose selected Change acceptance is complete may additionally use a provider-supported closing keyword for an explicit `relation: closes`. Checkpoints, `relation: relates`, ambiguous Change or Group ownership, and unresolved provider or repository identity emit no closing keyword. When safe shorthand cannot be resolved, keep only the canonical URL; never infer an issue from changed files or mutate the external tracker.
41
+ ## Audit before staging
37
42
 
38
- ## Commit the exact boundary
43
+ Read nearest authority and the selected current owner, plus the relevant Brief/children or archive when needed. Inspect status, the complete staged, unstaged and untracked boundary, cached diff and recent non-merge messages. Reread decisive verification and applicable lifecycle facts; copied handoff prose is insufficient.
39
44
 
40
- Stage only the explicit allowed paths. Re-read `git status --short`, inspect the complete cached path list and cached diff, and confirm they represent exactly one owner boundary with no sensitive material. If the cached boundary is wrong, stop and leave unrelated work untouched; do not repair it by broad staging, destructive reset, or history rewrite.
45
+ Reuse traceable passing results while relevant content, dependencies, configuration, tools, inputs and environment still apply. Run only authorized missing or invalidated checks with settled scope and method, or explicitly required executions; entering Commit alone requires no rerun. Failed or unavailable required evidence stops delivery.
41
46
 
42
- Transport a structured multiline message with actual line breaks or a safely prepared message file. Do not rely on ordinary quoted `\n` escape sequences as portable newlines; a host shell may pass those characters through literally.
47
+ Stop without changing the index on missing or ambiguous authority, stale evidence, an invalid kind/purpose, unrelated staged work, mixed ownership that cannot be separated without guessing, or active merge, cherry-pick, revert, rebase, mail-apply or sequencer state. Preserve pre-existing owned partial staging unless the exact additional content is authorized. Never broaden paths, unstage unrelated work or reset the index to make a boundary fit.
43
48
 
44
- Create one local commit with the prepared subject, optional body, and trailers. Do not push, tag, publish, amend, rebase, or force-push. Afterward observe `HEAD`, the raw complete committed message, committed paths, remaining worktree state, and remote refs when required. A successful commit is still a post-commit mismatch when the observed message differs from the prepared message, including unintended literal `\n` sequences; report and stop without inferring amend or second-commit authority.
49
+ Before reporting eligibility, confirm verification covers the exact proposed content. Matching filenames or a working-tree pass containing excluded changes is insufficient. For a staged slice, compare evidence with the current index. Check excluded code, configuration, fixtures and generated inputs for invalidation. Obtain missing evidence within authority or report the gap; preserve unrelated work.
45
50
 
46
- ## Return the receipt
51
+ Before dependent `git add` or `git commit`, run required audits and preparation as separately observed commands by default. If batching, explicitly gate each dependent write on all its prerequisites succeeding; shell newlines and the batch's final exit code do not provide that gate. A failed or unavailable prerequisite blocks its dependent write. Inspect actual index/worktree effects before permitted recovery; later success does not erase an earlier write after failure. Commit's one-attempt rule still applies.
47
52
 
48
- Return the commit SHA, owner and included WorkRefs, committed paths, parsed subject/body/trailers, remaining worktree paths, and explicit omissions. Report a stop before staging, commit failure, or post-commit mismatch truthfully; never silently amend or create a second commit to repair the first.
53
+ For readiness-only work, report eligibility, gaps and the next owner here; do not stage, prepare files or commit.
54
+
55
+ ## Review the final index and message
56
+
57
+ 1. Stage only the authorized content with exact path handling. Reread status, complete cached paths and diff, including sensitive material, and prove one reviewable logical boundary. Stop if it does not match; do not repair unrelated staging.
58
+ 2. Confirm the final index matches the content covered by the audited evidence. If staging changed that boundary, reassess applicability and fill only missing or invalidated coverage before proceeding; unchanged applicable results need no rerun. Record the reviewed HEAD (or unborn state) and index tree. These bind content, file modes and deletions, not only names; keep them transient.
59
+ 3. Derive the message from that final cached diff, not conversation chronology or a copied Change. Follow applicable project message rules and checks, using the established Conventional form when present and a concise repository-consistent subject. When the project permits and the subject is sufficient, omit the body; otherwise add only the rationale, behavior differences, compatibility or risk needed by a reader without the session.
60
+ 4. Load [message and references](references/message.md) for tracked, integration, Group, release, issue-related or non-trivial messages. Keep real removals, migration constraints and important omissions; omit session-only attempts, file inventories and routine command output. A supplied prepared message must still match the reviewed boundary; do not edit it when nearer authority forbids editing.
61
+ 5. Prepare actual multiline text, preferably outside the worktree or at an explicitly allowed path. Never use literal backslash-n as a newline transport or include a temporary message file in delivery. Legitimate escape notation in prose stays literal; do not decode it or reject it merely for containing backslash-n.
62
+
63
+ ## Execute once and observe
64
+
65
+ Use native Git inside this capability; no RSP commit wrapper or generated delivery
66
+ script is required. Missing Commit capability has no Core substitute. Respect a
67
+ nearer required method or denial; an incompatible requirement needs an owner
68
+ decision, not a trial commit or automatic fallback.
69
+
70
+ 1. Inspect operation state through `git rev-parse --git-path` for MERGE_HEAD,
71
+ CHERRY_PICK_HEAD, REVERT_HEAD, rebase-merge, rebase-apply and sequencer. Any
72
+ active operation or incomplete inspection stops ordinary delivery. Resolve
73
+ paths through Git, not a presumed .git directory, so worktrees are covered.
74
+ 2. Read HEAD with `git --no-replace-objects rev-parse --verify 'HEAD^{commit}'`.
75
+ A failed read is not automatically unborn: require `git symbolic-ref -q HEAD`
76
+ to name refs/heads/... and `git show-ref --verify --quiet <that-ref>` to confirm
77
+ absence (exit 1). Other errors stop. Immediately before execution, recheck this
78
+ HEAD/unborn state and `git write-tree` against the reviewed snapshot. A caller's
79
+ fixed snapshot cannot be replaced on its behalf. Drift stops without index repair.
80
+ 3. Attempt exactly once: `git commit --cleanup=verbatim -F <message-file>`, replacing
81
+ the placeholder with the safely prepared, quoted path. Preserve normal hooks
82
+ and signing policy; do not disable either to obtain success. Snapshot checks
83
+ are sequential observations, not a cross-process lock.
84
+ 4. Read resulting HEAD, then inspect that immutable SHA using
85
+ `git --no-replace-objects cat-file commit <sha>` for the raw message, tree and
86
+ parents, and `git --no-replace-objects diff-tree --root --no-commit-id --name-only --no-renames -r -z <sha>`
87
+ for actual paths. Use NUL-delimited path observations before and after delivery;
88
+ do not split unusual filenames on whitespace or treat display quoting as identity.
89
+ 5. Require the committed tree and paths to match the reviewed index, one parent
90
+ equal to reviewed HEAD (no parents for unborn), and the complete stored message
91
+ to match the prepared text with at most one terminal LF difference. Recheck
92
+ final HEAD still identifies that SHA and inspect remaining staged, unstaged
93
+ and untracked work against the prior boundary. Obtain committed facts from the
94
+ immutable object, not several movable HEAD reads.
95
+
96
+ Post-commit verification inspects these Git results and hook effects, not routine repetition of product tests. If hooks changed relevant inputs, report which evidence no longer applies; delivery remains stopped on mismatch or uncertain effects.
97
+
98
+ Exit zero alone is not exact delivery. After any failure, observe HEAD and actual
99
+ index/worktree effects before classifying the result. Distinguish refusal before
100
+ execution, Git failure with observed unchanged HEAD, created-commit mismatch and
101
+ incomplete observation. Even unchanged HEAD cannot rule out hook side effects.
102
+ An attempted commit or uncertain effects stops delivery without retry, amend,
103
+ reset, rollback or a repair commit. Preserve the observed state and report gaps;
104
+ never claim successful delivery when required observations fail or disagree.
105
+
106
+ ## Return the result
107
+
108
+ Concisely report kind and purpose, owner or refs when relevant, commit SHA when observed, delivered paths and message subject; include remaining work and material omissions when present. Retain the complete message and content/history observations as evidence; expand them when requested or needed to explain a mismatch, not as routine output. For a stop, name the missing condition, observed Git effects and safe next action. No stage grants push, tag, publication, deployment, approval, cross-branch integration or history rewrite.
@@ -0,0 +1,34 @@
1
+ # Message and owned references
2
+
3
+ Load for tracked, integration, Group, release, issue-related or non-trivial messages after the final cached boundary is reviewed.
4
+
5
+ ## Project contract and subject
6
+
7
+ Read applicable project instructions, message conventions and configured checks. Recent relevant commits supplement explicit rules, never override them. RSP does not require adopting Conventional Commits; where adopted, distinguish its syntax from stricter project requirements. Report conflicts with required checks instead of bypassing them. Preserve the entrypoint's commit-language precedence.
8
+
9
+ Derive type from the accepted change and scope from a stable domain or module, not session activities or path inventories. Summarize one reviewable outcome. If the message exposes unrelated outcomes, return to the delivery-boundary check; do not silently split or broaden the authorized commit.
10
+
11
+ ## Body by information need
12
+
13
+ When project rules permit, omit the body if the subject suffices and no material rationale, compatibility, migration or risk needs explanation. File count and change type alone do not determine that need. Otherwise explain only what a reader without the session needs: the problem and motivation, important old/new behavior differences, consequential tradeoffs or limitations.
14
+
15
+ For Conventional messages, separate the body from the subject with a blank line. Use prose for causes/tradeoffs, lists for independent points or both as needed. Do not require a bullet list, Why/What/Testing template or prose-plus-list sequence. Omit padding and subject repetition.
16
+
17
+ Keep real removals, migration constraints and important omissions. Do not copy the Change, execution chronology, routine checks or full path lists. Omit session-only attempts; retain a consequential reason for rejecting an alternative or accepting a tradeoff only when it explains the final design. A decisive measurement or verification limitation may matter, but command success must not imply broader acceptance.
18
+
19
+ Follow project length and wrapping checks without inventing universal 50/72-character limits. Otherwise wrap for readability without breaking URLs, identifiers, commands or natural Chinese text. If an exact required reference conflicts with a hard check, report the conflict rather than truncating it or bypassing the check.
20
+
21
+ ## Owned footers
22
+
23
+ Body freedom does not remove footer syntax. Keep footers separated by a blank line from the body, or from the subject when the body is absent. Emit ownership trailers as standalone fields, not body-list items; a necessary footer does not require a filler body. For Conventional breaking changes, use `!` or a `BREAKING CHANGE` footer as permitted, requiring both only when the project does. Explain the affected contract and migration needs proportionately; use the footer's exact token and syntax when present.
24
+
25
+ Project trailers from real ownership:
26
+
27
+ - Add one RSP-WorkRef per included Change.
28
+ - Add RSP-Group only when a Group is the durable owner; integration alone emits none.
29
+ - Direct and release without real included WorkRefs emit no RSP trailer.
30
+ - Keep authoritative external references already owned by the work. Use BREAKING CHANGE only for a real breaking contract.
31
+
32
+ Never invent a WorkRef, Group, issue, co-author, sign-off, breaking change or AI attribution.
33
+
34
+ Represent owned issue relationships with a proportionate non-closing Issue reference. A terminal delivery with complete selected Change acceptance may additionally use the provider-supported closing keyword only for an explicit closes relation. Checkpoints, relates, ambiguous ownership or unresolved provider/repository identity emit no closing keyword. If shorthand cannot be resolved safely, retain only the canonical URL; do not infer issues from files or mutate the tracker.
@@ -0,0 +1,65 @@
1
+ ---
2
+ name: rsp-doc
3
+ description: Write or revise repository documents, Skills and release communication, including final Change convergence and knowledge writeback. Own writing and author self-checks, not product planning, formal read-only review or publication.
4
+ license: MIT
5
+ metadata:
6
+ author: oevery
7
+ version: "2026.10.15.1"
8
+ ---
9
+
10
+ # RSP Doc
11
+
12
+ For tracked work, read the [shared work model](../rsp/references/work-model.md) when its identity and ownership definitions are missing from the current context. Use logical WorkRefs in commands and reports; cite file locations separately. Direct invocation needs no prior Core execution.
13
+
14
+ Write a grounded artifact usable without the author conversation. Use the artifact method for whole-record reconciliation, inspect final consistency and retain already-converged text. Local wording fixes and mechanical status/evidence updates need no full writing pass unless the whole record needs reconciliation. A no-op decision needs no new artifact or routine report field.
15
+
16
+ ## Produce the artifact
17
+
18
+ 1. **Fix the outcome.** Identify the reader, task, authorized files and expected result. For a document set, distinguish authoritative owners from summaries. Keep routine narration in conversation and retained evidence with its existing owner.
19
+ 2. **Establish the facts.** Read existing content, relevant callers and the smallest authoritative contract, code or source chain. Check commands, defaults, links and behavior with available tools. Distinguish current behavior, intended requirements and unknowns. Resolve material contradictions before rewriting a promise. Interpret tool output as evidence; it grants no permission and does not prove semantic correctness.
20
+ 3. **Draft for the task.** Apply the expression rules below and load only the relevant method:
21
+ - [Artifact lenses](references/artifact-lenses.md): README, CONTEXT, Spec, Change, guides and scoped operating documents.
22
+ - [Skill authoring](references/skill-authoring.md): Skill creation or revision, including descriptions, package resources and invocation policy.
23
+ - [Release communication](references/release-communication.md): changelogs, release notes, migration guidance or authorized release-document reconciliation; not ordinary document writing.
24
+ 4. **Verify the result.** Check the edited meaning in context. For structural edits, also follow the affected reading path and references. Use the checks below; reuse traceable unchanged mechanical results. Writing completion does not automatically trigger Review, but separately requested or required judgment remains binding.
25
+
26
+ ## Check facts and reading paths
27
+
28
+ Use the checks relevant to the change:
29
+
30
+ - Check whether readers can find information, understand conditions, act or judge compliance, and recognize unknowns.
31
+ - Check affected links, anchors, examples and metadata with existing tools. Execute examples only within safe authorized scope.
32
+ - For linked artifacts, compare shared claims, terminology, defaults and handoffs against their authoritative owner. Correct authorized summaries and links without copying full definitions or changing unassigned owners. Report out-of-scope contradictions to their owner.
33
+ - Recheck facts, quantifiers, defaults, failures, permissions and terminology after editing. Report actual checks and remaining gaps.
34
+ - API comments and embedded guidance: compare claims with their contract and implementation without assuming either side correct. Keep ordinary inline comments locally accurate and useful: retain constraints, rationale or usage that nearby code does not make clear, and remove restatement that adds no information; no full writing workflow is needed. Compiler/tool annotations retain implementation ownership.
35
+ - Examples: label illustrative pseudocode or incomplete snippets; check copyable commands against real prerequisites, outcomes and safe use without inferring execution or installation authority.
36
+
37
+ For agent-facing instructions, trace the relevant branch and its targets. Distinguish local reading-path reasoning from actual agent execution and required independent evidence; retain background human co-readers need.
38
+
39
+ For a failed command, inspect cause and actual effects before recovery. Change a permitted read/search or repeat-safe check method only within unchanged goal, scope, authority, baseline and required evidence. Named checks and protected RSP operations retain their methods/owners; unavailable Required evidence, unknown mutation or unsafe replay stops affected work.
40
+
41
+ ## Resolve language
42
+
43
+ - Response: explicit request → personal instructions → conversation language.
44
+ - Existing files: preserve language unless the user asks to change it.
45
+ - New files: explicit artifact language → effective configuration → scoped instructions → conversation language. Resolve needed RSP defaults/inheritance through the selected CLI's successful `rsp config --json`; refresh on relevant drift or recovery. Raw YAML is diagnostic only. Failed projection leaves dependent choices unresolved, not replaced by lower precedence; independent authorized work may continue. Other projects retain their configuration readers.
46
+ - Keep canonical identifiers, machine values and required headings exact.
47
+
48
+ ## Write precisely
49
+
50
+ - Organize around the reader's task: operations need actions and success signals; contracts need guarantees and exceptions; design needs reasons and tradeoffs. Explain unfamiliar concepts through their task-relevant meaning; include mechanisms needed to reason, troubleshoot or assess guarantees. Reference entries need no forced tutorial. Do not force every artifact into an action list or closing next step.
51
+ - State the actor, action and object directly. Prefer short, complete sentences when easier to follow. Separate independent actions; preserve causal and conditional links. Give each paragraph one useful purpose. Put prerequisites before use, conditions beside actions and exceptions beside their rules. Keep necessary local context; link branch-only detail with its reading condition and purpose.
52
+ - Number steps when their order matters; make each step a bounded action. Use peer bullets for independent items and connected prose for reasoning. Use tables for useful fixed mappings/comparisons, not branching Skill judgments.
53
+ - Remove empty introductions, rhetorical framing, repeated conclusions, filler and irrelevant chronology. Keep author voice, decision-relevant explanations, necessary reasoning and required audit evidence. Replace abstract aspirations with concrete actions. For prescriptive rules, use contrasts or counterexamples only to resolve likely ambiguity. Retain explanatory comparisons needed for understanding, decisions or migration; merge equivalent examples. No fixed sentence length, list size or compression ratio defines quality.
54
+ - Preserve negation, conditions, exceptions, permissions, quantities, units and certainty. Merge failure explanations with the same decision effect. Retain permission, outcome, stop and safe-recovery conditions, including rare boundaries preventing unauthorized action, serious harm or unsafe replay. Keep incident details with their evidence owner. Do not turn a proposal or unknown into a verified fact. Shorter wording proves no behavioral equivalence.
55
+ - Wording edits preserve meaning, information ownership, heading anchors and technical literals: code blocks, commands, paths, identifiers, links, versions and numeric values. Structural edits may merge, move or reorder content within scope while preserving completeness and references. Behavior changes and technical corrections need their own scope and checks; shortening prose grants neither.
56
+ - Use ordinary words for conjunctions. Preserve technical syntax; reserve | for closed alternatives, / for established pairs, → for defined transitions and : for label/value boundaries.
57
+
58
+ ## Preserve ownership
59
+
60
+ - Follow nearest project instructions and the authorized file boundary. Keep a selected WorkRef when tracked; bounded direct work needs no automatic Change.
61
+ - Doc owns writing and self-checks; formal fixed-scope Review remains read-only and independent when required. A combined request retains both responsibilities: Review grants no repair authority, but originally authorized corrections may continue.
62
+ - Product decisions stay with their design owner. Release writing grants no version decision, release verification, Git delivery or external publication authority. Missing optional methods do not require installation or block an available bounded method.
63
+ - Preserve unrelated work. Ask when a missing choice materially changes the result or authority; stop when required evidence is unavailable. Writing alone grants no installation, deployment, Git delivery or publication.
64
+
65
+ Return changed artifacts, decisive checks and material limits. Tracked work retains necessary conclusions in its existing record; stable knowledge belongs to its document and retained evidence to its existing owner. Focus maintenance remains Core's responsibility.
@@ -0,0 +1,3 @@
1
+ interface:
2
+ display_name: RSP Doc
3
+ short_description: 'Write clear, grounded documents and Skills'
@@ -0,0 +1,43 @@
1
+ # Artifact lenses
2
+
3
+ Choose what the reader must understand, do or judge, not a mandatory template. Preserve project formats and canonical headings; action-first wording is useful for procedures, not a requirement for every artifact.
4
+
5
+ For a document set, start with the reader's entry point and follow only the links needed for the task. Check that each handoff supplies its prerequisites and that summaries agree with the linked owner. An owner outside the authorized write set remains read-only; return its conflicting claim rather than expanding the edit boundary.
6
+
7
+ ## README
8
+
9
+ - Help a newcomer find the starting point, prerequisites and first useful result with a recognizable success signal.
10
+ - State important exclusions before setup. Keep a useful overview and local prerequisites; link specialized detail with its reading purpose.
11
+ - Match the audience. A maintainer README need not become an installation tutorial.
12
+
13
+ ## CONTEXT
14
+
15
+ - Help readers understand domain terms and relationships, then find the authoritative owner; do not duplicate that owner's full contract.
16
+ - Keep names, useful translations and navigation near each definition. Link one authoritative definition across root and local files.
17
+ - Explain different meanings at domain boundaries; do not silently rename them.
18
+
19
+ ## Spec
20
+
21
+ - Enable a reader to judge compliance: state what a consumer can rely on, under which conditions, with scope, handoffs, failures and exceptions.
22
+ - Keep normative design references and protocol detail needed to establish compliance.
23
+ - Add a scenario only when it resolves ambiguity. Domain headings are valid; no fixed section set is required.
24
+ - Leave future promises in the Change and verification results with their work owner.
25
+
26
+ For example, “retries are safe” is incomplete when deduplication applies only to the same key. State that condition without inventing retention or failure guarantees.
27
+
28
+ ## Guides and references
29
+
30
+ - Procedures: give prerequisites, execution context, bounded actions and success signals. Explain a likely failure when it helps the task; keep conditional branches near their triggers.
31
+ - Concepts and design explanations: preserve definitions, causal reasoning and tradeoffs needed to understand or decide; do not replace them with a terse action checklist.
32
+ - References: provide exact contracts and navigable details, not a forced tutorial.
33
+ - Label illustrative snippets; do not present invented output as observed execution. Preserve incoming links after heading changes.
34
+ - API/TSDoc comments: explain the consumer's real inputs, returns, failures and use. Compare examples and claims with their authoritative contract and implementation; report unresolved discrepancies rather than silently documenting whatever code does. Writing authority does not permit implementation changes, execution or dependency installation.
35
+
36
+ ## Operating instructions and work records
37
+
38
+ - AGENTS: state applicable rules, commands, authority and checks. Changing rules requires explicit scope.
39
+ - Change: retain the six canonical sections and selected delta. Proposal gives the outcome; Spec gives acceptance; Design gives the approach; Tasks state checkable work and completion, with completed items describing the accomplished result; Verify records methods, candidate-bound conclusions, limits and necessary evidence references; Blockers uses the [shared work-model syntax](../../rsp/references/work-model.md) for current impediments.
40
+ - Work records: retain necessary plan/contract changes, outcomes, blockers and scoped verification. Keep routine narration in conversation and needed recovery state in Focus. Before archive, establish facts and justified knowledge writeback; reconcile all six sections with current outcomes, superseded plans and knowledge owners. Retain facts affecting the delivered contract, evidence applicability, important failure disposition or remaining limit. Link knowledge and evidence owners; preserve their detailed records and original verdicts. Correct stale authoritative contracts. Return substantive contradictions to their owner; prose cleanup cannot settle them.
41
+ - Decision Record: let readers understand why a choice was made, its alternatives and consequences, without redefining the contract.
42
+ - Audit/run records: retain required observations, actions and evidence. Remove irrelevant session narration, not the record's purpose.
43
+ - Skill packages: use Doc's Skill-authoring branch. Release communication uses Doc's conditional release method.