@oevery/rsp 2.0.3 → 3.1.0-beta.0

package/dist/locale-HT44UIUP.mjs

@@ -0,0 +1,21 @@
+#!/usr/bin/env node
+
+// src/tui/i18n/locale.ts
+function normalizeLocale(value) {
+  if (!value)
+    return null;
+  const normalized = value.replaceAll("_", "-").split(".")[0].toLowerCase();
+  if (normalized === "en")
+    return "en";
+  if (normalized === "zh" || normalized === "zh-cn" || normalized.startsWith("zh-cn-") || normalized === "zh-hans" || normalized.startsWith("zh-hans-"))
+    return "zh-CN";
+  return null;
+}
+function resolveUiLocale(explicit, environmentLocale, hostLocale) {
+  if (explicit !== "auto")
+    return explicit;
+  return normalizeLocale(environmentLocale) ?? normalizeLocale(hostLocale) ?? "en";
+}
+export {
+  resolveUiLocale
+};

package/package.json

@@ -1,8 +1,8 @@
 {
   "name": "@oevery/rsp",
   "type": "module",
-  "version": "2.0.3",
-  "description": "RSP (Rules, Specs, Plans) workflow for lightweight AI-assisted change management",
+  "version": "3.1.0-beta.0",
+  "description": "RSP (Reliable Software Practice), a repository-native engineering workflow for humans and AI agents",
   "author": "oevery",
   "license": "MIT",
   "homepage": "https://github.com/oevery/rsp#readme",
@@ -13,6 +13,9 @@
   "bugs": "https://github.com/oevery/rsp/issues",
   "keywords": [
     "rsp",
+    "reliable-software-practice",
+    "repository-native",
+    "engineering-workflow",
     "rules",
     "specs",
     "plans",
@@ -30,28 +33,34 @@
     "skills/"
   ],
   "engines": {
-    "node": ">=18"
+    "node": ">=22"
   },
   "scripts": {
     "prepare": "pnpm run build",
-    "release:check": "pnpm run build && pnpm run lint && pnpm run test && npm pack --dry-run --ignore-scripts",
+    "release:check": "pnpm run build && pnpm run typecheck && pnpm run lint && pnpm run test && pnpm run release:package-check",
+    "release:package-check": "node scripts/clean-install-check.mjs",
     "prepublishOnly": "pnpm run release:check",
     "build": "tsup",
     "dev": "tsup --watch",
     "lint": "eslint .",
     "lint:fix": "eslint --fix .",
+    "typecheck": "tsc --noEmit",
     "test": "vitest run",
     "test:watch": "vitest"
   },
   "dependencies": {
     "citty": "^0.2.2",
+    "ink": "~7.1.1",
     "picocolors": "^1.1.1",
+    "react": "~19.2.3",
     "yaml": "^2.9.0"
   },
   "devDependencies": {
     "@antfu/eslint-config": "^9.0.0",
     "@types/node": "^22.19.19",
+    "@types/react": "19.2.14",
     "eslint": "^10.4.0",
+    "ink-testing-library": "4.0.0",
     "tsup": "^8.4.0",
     "typescript": "^5.8.0",
     "vitest": "^4.1.7"

package/rules/rsp-rules.md

@@ -1,103 +1,71 @@
 ---
 name: rsp-rules
-description: Core RSP rules for Rules, Specs, and Plans driven development.
+description: Minimal fallback protocol for Rules, Specs, and Plans driven development.
 ---
 
-# RSP
+# RSP fallback protocol
 
-This file is the canonical RSP rules source.
+This file is the minimal fallback protocol for agents that cannot load the `rsp` skill. It is not the project instruction or design store.
 
-## Scope
+## Entry
 
-- Paths in this file are relative to the project root unless stated otherwise.
-- These rules are tool-agnostic and apply even when the agent does not support skills.
-- If the agent supports Agent Skills, load the `rsp` skill for initialization, audit or repair, and durable-decision tasks.
-
-## Read order
-
-1. Read `AGENTS.md`.
-2. Read `.rsp/rules/rsp-rules.md` in full.
-3. Read `focus.d/`.
-4. If `focus.d/` is empty, ask the user what to work on or suggest `npx -y @oevery/rsp create <name>`.
-5. Read each `changes/<name>.md` file marked in `focus.d/`.
-6. Read `specs/design.md` and `specs/INDEX.md`.
-   `specs/INDEX.md` lists only additional spec files beyond `specs/design.md`.
-7. Read only the relevant additional `rules/` and `specs/` files.
-
-## Core rules
-
-- Treat `rules/` as the canonical rules source.
+- Read nearest `AGENTS.md` and relevant `CONTEXT.md` before RSP work. Use root `CONTEXT-MAP.md` when present.
+- Prefer the `rsp` skill for setup, focused work, readiness, repair, and durable review.
+- If the `rsp` skill is unavailable, read this file before operating `.rsp/`.
 - Treat `focus.d/` as the only current-focus source.
-- Treat `changes/` as open work.
-- Treat `archives/` as completed history.
-- Treat each change as a single `.md` file under `changes/`. Do not create multi-file change bundles or supplementary files alongside a change.
-- RSP uses only two lifecycle states: `open` (in `changes/`) and `archived` (in `archives/`). Do not introduce intermediate states such as "in review" or "verified".
-- Keep every change file in the fixed six-section structure.
-- Use an RSP command first when an RSP command already covers the action.
-- Do not infer current work from `changes/` alone.
-- Do not treat `AGENTS.md` as the long-term rules or design store.
-- Do not redefine the core change structure through project config.
-
-## File ownership
-
-- Manage only the `<!-- rsp:begin --> ... <!-- rsp:end -->` block in `AGENTS.md`.
-- Do not modify content outside the managed AGENTS block unless the user explicitly asks for it.
-- Do not edit `specs/INDEX.md` or `archives/INDEX.md` manually; use `npx -y @oevery/rsp update`.
-- Treat `specs/design.md` as the durable design file. Prefer sections: `Purpose`, `Stable Facts`, `Boundaries`, `Constraints`.
-- Treat all `specs/<name>.md` as durable-truth documents. Use the same section structure as `specs/design.md`.
-- Treat `rules/project-rules.md` as the durable local-rules file.
-- Create `rules/project-rules.md` only when the project has stable local rules worth keeping.
-- Create or update `specs/` only for durable project-level facts that are stable, reusable, and worth rereading in later sessions.
-- Prefer updating `specs/design.md` or an existing durable file before creating a new spec file.
-- Create a new `specs/<name>.md` only when the knowledge forms a distinct durable project topic that does not fit `specs/design.md` or an existing durable file.
-- Write stable facts to the smallest correct durable file. Do not duplicate the same fact across multiple durable files without a clear long-term reason.
-
-## Command rules
-
-- Use `npx -y @oevery/rsp init` to scaffold the base RSP structure.
-- Use `npx -y @oevery/rsp add rules <name>` to create a durable rules file.
-- Use `npx -y @oevery/rsp add spec <name>` to create a durable spec file.
-- Use `npx -y @oevery/rsp create <name>` to create an open change.
-- Use `npx -y @oevery/rsp focus <name>` to foreground an existing open change.
-- Use `npx -y @oevery/rsp unfocus <name>` to remove an open change from the current focus set.
-- Use `npx -y @oevery/rsp archive <name>` to archive a completed change.
-- Use `npx -y @oevery/rsp update` to refresh bundled rules, repair the managed `AGENTS.md` block, and rebuild generated indices.
-- Use `npx -y @oevery/rsp doctor` for diagnostics only.
-- If RTK is available, you may prefix RSP commands with `rtk`.
-- Do not use `npx -y @oevery/rsp create <name>` to re-focus an existing change.
-- Do not create RSP-managed files directly when an RSP command already exists for that file type.
-
-## Change rules
-
-Every change file must contain:
-
-- an explicit `kind` field in frontmatter
-- `## Proposal`
-- `## Spec`
-- `## Design`
-- `## Tasks`
-- `## Verify`
-- `## Blockers`
-
-Do not leave `kind` unresolved.
-
-If a section does not apply, keep it and write `- none` or `- not needed: <reason>`.
-
-## Archive gate
-
-- `rsp archive <name>` never blocks. It warns but always completes the move.
-- Make a durable-update decision before `npx -y @oevery/rsp archive <name>`.
-- If `Blockers` still contains a real blocker, set `Archive ready: no`.
-- If the change produced durable knowledge that has not been written to `specs/` or `rules/`, set `Archive ready: no`.
-- If `Verify` is incomplete but there is no active blocker and no missing durable update, treat archive readiness as a judgment call.
-- A durable update should contain stable facts only, not task history, debugging notes, or one-off implementation context.
-- Default to no spec writeback unless the change produced project-level durable knowledge that future work must reread.
-
-## Prohibitions
-
-- Do not create placeholder or empty-shell files merely for completeness.
-- Do not create archive entries directly under `.rsp/archives/`; use `npx -y @oevery/rsp archive <name>`.
-- Do not create spec files that duplicate `specs/design.md` or another durable file.
-- Do not create a catch-all summary file like `specs/changes.md`.
-- Do not create supplementary files alongside a single change file.
-- Do not promote archive history, temporary troubleshooting notes, or task-by-task execution logs into `specs/` or `rules/`.
+- If `focus.d/` is empty and the user has not provided a concrete task, ask what to work on or suggest `npx -y @oevery/rsp create <name>`.
+- For grouped work, read the sibling Group Brief before the focused child Change. Then read only the relevant Specs and Decision Records under the configured authoritative path.
+
+## Core
+
+- Choose response language and artifact language independently. Localize human-facing response headings, labels, explanations, and conclusions according to the requested response language, response-specific project instructions, then conversation language. Write artifact prose according to the requested artifact language, artifact-specific project instructions, existing artifact language, then conversation language. Preserve canonical RSP artifact headings, WorkRef values, paths, commands, identifiers, and machine-consumed values. Response-only Continuation and Durable Decision labels are not artifact headings; a technical token may appear in parentheses but cannot replace the localized label.
+- Write persistent artifact prose in domain, system, user, or operator language. Mention AI or agents only when they are real product actors, consumers, interface participants, or constraints; agent authorship, execution narration, or convenience for a hypothetical future agent is not durable content.
+- `changes/` stores open work; `archives/` stores completed history; `specs/` stores stable current facts; the configured Decision Record path stores lasting rationale.
+- Every Change is one Markdown file with explicit `kind` and the fixed `Proposal`, `Spec`, `Design`, `Tasks`, `Verify`, and `Blockers` sections.
+- A Change is a convergent current-plan and final-evidence snapshot, not an append-only execution log. Keep Tasks aligned with current delivery and Verify limited to final decisive commands or scenarios, results, proven scope, omitted or unavailable coverage, and remaining risk. Replace superseded plans and evidence; retain an earlier failure only when it still explains a current blocker, coverage gap, or risk.
+- In a Change `Blockers` section, `- requires \`<change-work-ref>\`: <reason>` declares an exact dependency on another executable Change. Other meaningful blocker prose remains external and is never inferred as a dependency.
+- Executable Change identities are either `<change>` or `<group>/<change>`. Recursive work paths are unsupported.
+- A Change Group is the only composite work shape. Use it only when at least two independently executable direct child Changes share one goal or completion contract.
+- `<group>/brief`, physically stored as `<group>/00-brief.md`, owns Goal, Scope, Shared Constraints, Slices, Completion Conditions, Durable Outcomes, and Blockers. Every direct child must be declared by `Slices`, and every declared slice must be open or archived.
+- A Group Brief is not executable or focusable. Read it before a grouped child, archive children independently, and use `rsp group close <group>` only after derived completion passes. Archived Group identities cannot be reopened.
+- A file and directory cannot claim the same work identity.
+- `changes/` must exist as a real directory. Existing `focus.d/`, `archives/`, and direct group prefixes must also be real directories; symlinks, missing open-work roots, and incomplete inspection fail closed.
+- Initialization, repair, status inspection, Spec creation, and index generation use the same no-follow managed-path rules; recursive Specs may use only real directories and regular files.
+- Final managed files, including the project `AGENTS.md`, focus markers, fallback/config files, indexes, and placeholders, must be regular files rather than symlinks or special entries.
+- `status`, `check`, and `doctor` share work-tree, Change Group, and dependency inspection. They fail visibly on unsupported structure, membership mismatches, malformed or missing dependency targets, self-dependencies, and cycles. With no focus, status uses Group Brief declaration order and derived blockers to recommend the first executable slice.
+- `status` derives minimal graph nodes, dependency edges with their reasons, ready Changes, blockers, and stable execution waves from exact blocker references. Filtered plans retain transitive prerequisite context and distinguish selected nodes from prerequisite nodes; human output renders the same flat graph as a dependency forest whose parent requires its children. Archived prerequisites resolve automatically; incomplete dependency or archive inspection fails closed and marks open Changes blocked for readiness; no graph file or delivery state is persisted; and Group Briefs are not dependency targets.
+- Parallel Changes in one Group follow the Brief `Slices` declaration order in plan output; unrelated work uses stable lexical ordering.
+- A Group Brief blocker is inherited by its direct child Changes as an external blocker; it does not create inferred dependency edges.
+- Persist only `open` and `archived`; readiness, blockers, verification, and next actions are derived.
+- Ordinary implementation is the default after unexplained failures have been ruled out. Use test-first work only when user, Change, or project authority requires it or a concrete changed risk makes a focused pre-mutation failure materially safer. Retain a new test only when it protects observable behavior or a real boundary, adds distinct future confidence, avoids duplicate or implementation-detail coverage, and has proportionate maintenance cost; otherwise remove the temporary probe and use the smallest decisive final verification.
+- Route one isolated domain, module/seam, or evidence-seeking design question to `rsp-design` when available, or use a compact manual design pass. Return evidence, alternatives, owner decisions, and any authorized planned-design update to the same selected Change; do not implement or write durable current truth from that pass.
+- Route release documentation only when the selected Change explicitly owns a confirmed release identity or range and still has unfinished changelog, release-note, or migration work. Select `rsp-release-docs` when available, or use the same evidence-led manual fallback; lifecycle stage, completed implementation, and archive readiness alone are insufficient. This route never grants commit, tag, push, release creation, publication, deployment, or approval authority.
+- Do not infer current work from open Changes or filenames.
+- Prefer RSP commands for deterministic setup, status, validation, repair, focus, index, and archive operations.
+
+## Durable review
+
+- Route artifacts by semantic owner: planned future design stays in the selected Change; implemented stable current facts go to the smallest authoritative Spec or, with explicit authority, project-owned context/instructions; lasting rationale is judged independently for the configured Decision Record path; temporary continuation stays in the response unless a path is explicitly authorized.
+- Project-owned `CONTEXT.md` owns stable navigation or scoped current context, while project-owned `AGENTS.md` owns stable operating instructions. Preserve their conventions and never treat RSP as their owner.
+- Before archive, decide independently whether current facts need a Spec or scoped-instruction update and whether lasting rationale needs a Decision Record.
+- Before archive, compress the Change to its final outcome, current design, completed delivery tasks, final decisive verification, and unresolved risks. Keep RED/GREEN/REFACTOR cycles, temporary probes, command transcripts, and step-by-step review corrections in the response instead of the Change or Archive.
+- After required durable updates, Core recommends explicit archive before final Git delivery. Core does not execute archive or grant authority to stage, commit, push, or publish.
+- Decision Records are for hard-to-reverse choices with real tradeoffs; they do not duplicate current facts.
+- Change Spec deltas are planning aids and are never promoted automatically into Specs or Decision Records.
+- Keep task history, debugging notes, and transient execution state out of Specs and Decision Records.
+- Generated indexes and archives are not current-truth owners.
+
+## Continuation and conflicts
+
+- When execution stops with accepted work remaining, return one compact continuation with the semantic fields `WorkRef`, `Authority`, `Current state`, `Changed artifacts`, `Fresh verification`, `Blockers`, and `Next action`. Keep this field order, but localize the human-facing title and labels to the response language without changing referenced artifact prose or canonical technical values. Reopen its authority pointers, inspect drift, and refresh verification before resuming; it is not durable truth or a second state store.
+- Write a continuation file only when explicitly authorized. Never persist hidden handoff or controller state.
+- If an active merge, rebase, or cherry-pick conflict intersects authorized implementation, inspect the exact operation and conflicted paths, then compare base/ours/theirs semantics in that operation. Resolve only evidenced in-scope content while preserving unrelated work.
+- Stop on unrelated user work, an unresolved product decision, incomplete side/base evidence, or scope beyond the WorkRef. Name the exact conflict and required owner input; do not choose a side, stage a resolution, continue or abort the Git operation, commit, or infer any Git authority.
+- After an authorized working-tree resolution, rerun affected checks and return the continuation. Conflict-resolution authority alone does not grant Git continuation or delivery.
+
+## Safety
+
+- Do not create RSP-managed files directly when a command owns the operation.
+- Do not create archive entries directly; use `npx -y @oevery/rsp archive <name>`.
+- Do not modify content outside the managed RSP block in `AGENTS.md` unless explicitly requested.
+- Archive reports warnings but does not grant commit, push, publication, deletion, or external approval authority.