rpr-cli 0.3.5__tar.gz → 0.3.8__tar.gz

{rpr_cli-0.3.5 → rpr_cli-0.3.8}/PKG-INFO

@@ -1,19 +1,19 @@
-Metadata-Version: 2.5
+Metadata-Version: 2.4
 Name: rpr-cli
-Version: 0.3.5
-Summary: RPR CLI -- React Python Rust monorepo scaffolding orchestrator
-License-Expression: MIT
-License-File: LICENSE
-Requires-Python: >=3.14
+Version: 0.3.8
+Requires-Dist: typer>=0.24.1
 Requires-Dist: jinja2>=3.1.5
-Requires-Dist: packaging>=26.2
-Requires-Dist: pathspec>=1.0.4
-Requires-Dist: prompt-toolkit>=3.0.52
 Requires-Dist: pyyaml>=6.0.2
 Requires-Dist: rich>=14.3.3
+Requires-Dist: pathspec>=1.0.4
+Requires-Dist: prompt-toolkit>=3.0.52
 Requires-Dist: tomlkit>=0.15.0
-Requires-Dist: typer>=0.24.1
-Description-Content-Type: text/markdown
+Requires-Dist: packaging>=26.2
+License-File: LICENSE
+Summary: RPR CLI -- React Python Rust monorepo scaffolding orchestrator
+License-Expression: MIT
+Requires-Python: >=3.14
+Description-Content-Type: text/markdown; charset=UTF-8; variant=GFM
 
 # RPR CLI
 
@@ -35,7 +35,8 @@ Both install the `rpr` command.
 For development, editable install is fine:
 
 ```bash
-uv tool install -e .
+uv sync
+uv run maturin develop
 ```
 
 For an actual distributable install you can use in other projects, build the wheel first and install the built artifact:
@@ -51,6 +52,10 @@ From another local project you can also install the built artifact directly:
 uv add ../project-getting-started/dist/rpr_cli-*.whl
 ```
 
+The published wheels are mixed Python/Rust distributions. The `rpr._native`
+binding used by `rpr rename` and accelerated `rpr map` is installed alongside
+the Python package; no separate parser installation is required.
+
 ## Usage
 
 ### 🚀 Scaffolding & Generation
@@ -221,14 +226,13 @@ The `chat` command also supports:
 # Install Python dependencies
 uv sync
 
-# Build the Rust extension (rpr_parser) — required for rename and map acceleration
-cd rpr-parser && uv run maturin develop && cd ..
+# Rebuild the bundled Rust extension after native code changes
+uv run maturin develop
 ```
 
-> **Note:** `uv tool install dist/rpr-*.whl` uses the root hatchling build backend and does **not** build the
-> Rust extension. You must run `maturin develop` separately before using `rpr rename` or `rpr map`
-> with the Rust backend. Rename requires the extension; map falls back to the pure-Python
-> implementation when it is unavailable.
+> **Note:** `uv tool install rpr-cli` installs the matching platform wheel with
+> the Rust binding included. Building from a source checkout requires a Rust
+> toolchain because Maturin compiles the same native module locally.
 
 #### Running Tests
 
@@ -242,7 +246,7 @@ uv run pytest tests/test_map_extractor.py
 # Single test
 uv run pytest tests/test_map_extractor.py::test_fallback_returns_correct_shape
 
-# Rust unit tests (rpr_parser crate)
+# Rust unit tests (bundled native crate)
 cd rpr-parser && cargo test && cd ..
 
 # Lint and format
@@ -250,8 +254,8 @@ uv run ruff check .
 uv run ruff format .
 ```
 
-The Rust-path tests in `tests/test_map_extractor.py` are automatically skipped if the Rust
-extension hasn't been built yet — run `maturin develop` first to enable them.
+The Rust-path tests in `tests/test_map_extractor.py` are automatically skipped if the bundled
+extension has not been built yet — run `uv run maturin develop` first to enable them.
 
 ### Publishing To PyPI
 
@@ -267,10 +271,13 @@ No `PYPI_API_TOKEN` secret is required when publishing through GitHub Actions OI
 Release flow:
 
 ```bash
-# update src/rpr/__init__.py with the new version
-git commit -am "Release 0.1.2"
-git tag v0.1.2
+# update src/rpr/__init__.py and rpr-parser/Cargo.toml to the same version
+git commit -am "Release 0.3.8"
+git tag v0.3.8
 git push origin main --tags
 ```
 
-The workflow in `.github/workflows/publish-pypi.yml` builds the sdist and wheel, checks that the tag matches the package version, and uploads `dist/*` to PyPI.
+The workflow in `.github/workflows/publish-pypi.yml` checks both version declarations against the
+tag, builds an sdist plus native wheels for Linux x86-64/AArch64, Windows x86-64, and macOS
+x86-64/Apple Silicon, then publishes all artifacts to PyPI.
+

{rpr_cli-0.3.5 → rpr_cli-0.3.8}/README.md

@@ -18,7 +18,8 @@ Both install the `rpr` command.
 For development, editable install is fine:
 
 ```bash
-uv tool install -e .
+uv sync
+uv run maturin develop
 ```
 
 For an actual distributable install you can use in other projects, build the wheel first and install the built artifact:
@@ -34,6 +35,10 @@ From another local project you can also install the built artifact directly:
 uv add ../project-getting-started/dist/rpr_cli-*.whl
 ```
 
+The published wheels are mixed Python/Rust distributions. The `rpr._native`
+binding used by `rpr rename` and accelerated `rpr map` is installed alongside
+the Python package; no separate parser installation is required.
+
 ## Usage
 
 ### 🚀 Scaffolding & Generation
@@ -204,14 +209,13 @@ The `chat` command also supports:
 # Install Python dependencies
 uv sync
 
-# Build the Rust extension (rpr_parser) — required for rename and map acceleration
-cd rpr-parser && uv run maturin develop && cd ..
+# Rebuild the bundled Rust extension after native code changes
+uv run maturin develop
 ```
 
-> **Note:** `uv tool install dist/rpr-*.whl` uses the root hatchling build backend and does **not** build the
-> Rust extension. You must run `maturin develop` separately before using `rpr rename` or `rpr map`
-> with the Rust backend. Rename requires the extension; map falls back to the pure-Python
-> implementation when it is unavailable.
+> **Note:** `uv tool install rpr-cli` installs the matching platform wheel with
+> the Rust binding included. Building from a source checkout requires a Rust
+> toolchain because Maturin compiles the same native module locally.
 
 #### Running Tests
 
@@ -225,7 +229,7 @@ uv run pytest tests/test_map_extractor.py
 # Single test
 uv run pytest tests/test_map_extractor.py::test_fallback_returns_correct_shape
 
-# Rust unit tests (rpr_parser crate)
+# Rust unit tests (bundled native crate)
 cd rpr-parser && cargo test && cd ..
 
 # Lint and format
@@ -233,8 +237,8 @@ uv run ruff check .
 uv run ruff format .
 ```
 
-The Rust-path tests in `tests/test_map_extractor.py` are automatically skipped if the Rust
-extension hasn't been built yet — run `maturin develop` first to enable them.
+The Rust-path tests in `tests/test_map_extractor.py` are automatically skipped if the bundled
+extension has not been built yet — run `uv run maturin develop` first to enable them.
 
 ### Publishing To PyPI
 
@@ -250,10 +254,12 @@ No `PYPI_API_TOKEN` secret is required when publishing through GitHub Actions OI
 Release flow:
 
 ```bash
-# update src/rpr/__init__.py with the new version
-git commit -am "Release 0.1.2"
-git tag v0.1.2
+# update src/rpr/__init__.py and rpr-parser/Cargo.toml to the same version
+git commit -am "Release 0.3.8"
+git tag v0.3.8
 git push origin main --tags
 ```
 
-The workflow in `.github/workflows/publish-pypi.yml` builds the sdist and wheel, checks that the tag matches the package version, and uploads `dist/*` to PyPI.
+The workflow in `.github/workflows/publish-pypi.yml` checks both version declarations against the
+tag, builds an sdist plus native wheels for Linux x86-64/AArch64, Windows x86-64, and macOS
+x86-64/Apple Silicon, then publishes all artifacts to PyPI.

{rpr_cli-0.3.5 → rpr_cli-0.3.8}/pyproject.toml

@@ -23,11 +23,15 @@ rpr = "rpr.cli:app"
 dev = ["pytest>=9.0.2", "maturin>=1.8.2"]
 
 [build-system]
-requires = ["hatchling"]
-build-backend = "hatchling.build"
+requires = ["maturin>=1.12.6,<2.0"]
+build-backend = "maturin"
 
-[tool.hatch.build.targets.wheel]
-packages = ["src/rpr"]
+[tool.maturin]
+manifest-path = "rpr-parser/Cargo.toml"
+python-source = "src"
+module-name = "rpr._native"
+features = ["pyo3/extension-module"]
+include = [{ path = "LICENSE", format = "sdist" }]
 
-[tool.hatch.version]
-path = "src/rpr/__init__.py"
+[tool.pytest.ini_options]
+testpaths = ["tests"]

{rpr_cli-0.3.5 → rpr_cli-0.3.8}/rpr-parser/Cargo.lock

@@ -1981,7 +1981,7 @@ dependencies = [
 
 [[package]]
 name = "rpr-parser"
-version = "0.1.0"
+version = "0.3.8"
 dependencies = [
  "dirs",
  "dotenvy",

{rpr_cli-0.3.5 → rpr_cli-0.3.8}/rpr-parser/Cargo.toml

@@ -1,14 +1,14 @@
 [package]
 name = "rpr-parser"
-version = "0.1.0"
+version = "0.3.8"
 edition = "2021"
 
 [lib]
-name = "rpr_parser"
+name = "_native"
 crate-type = ["cdylib"]
 
 [dependencies]
-pyo3 = { version = "0.28", features = ["extension-module"] }
+pyo3 = { version = "0.28", features = ["extension-module", "abi3-py314"] }
 rayon = "1.11"
 walkdir = "2"
 tree-sitter = "0.26"

{rpr_cli-0.3.5 → rpr_cli-0.3.8}/rpr-parser/src/lib.rs

@@ -131,7 +131,7 @@ fn build_dependency_graph(py: Python<'_>, abs_root: String) -> PyResult<Py<PyAny
 }
 
 #[pymodule]
-fn rpr_parser(m: &Bound<'_, PyModule>) -> PyResult<()> {
+fn _native(m: &Bound<'_, PyModule>) -> PyResult<()> {
     init_logging();
     // Register a tiny smoke-test function first so Python/Jupyter can confirm
     // the compiled module loaded before we move on to more complex APIs.

rpr_cli-0.3.8/src/rpr/__init__.py

@@ -0,0 +1 @@
+__version__ = "0.3.8"

{rpr_cli-0.3.5 → rpr_cli-0.3.8}/src/rpr/map/extractor.py

@@ -29,7 +29,7 @@ from rpr.map.graph import DependencyGraph, build_graph
 from rpr.map.walker import Language, SourceFile, walk
 
 try:
-    import rpr_parser
+    from rpr import _native as rpr_parser
 
     _RUST_AVAILABLE = True
 except ImportError:

{rpr_cli-0.3.5 → rpr_cli-0.3.8}/src/rpr/project_rename.py

@@ -1,5 +1,6 @@
 from __future__ import annotations
 
+import importlib
 from dataclasses import dataclass, field
 from pathlib import Path
 from typing import Any
@@ -47,23 +48,24 @@ class RenamePlan:
 
 def _native_module() -> Any:
     try:
-        import rpr_parser
+        native = importlib.import_module("rpr._native")
     except ImportError as exc:
         raise ProjectRenameError(
-            "The Rust rename backend is unavailable. Build it with "
-            "`cd rpr-parser && uv run maturin develop`, then rerun the command."
+            "This rpr-cli installation does not include a compatible Rust backend. "
+            "Reinstall the latest platform wheel with `uv tool install rpr-cli "
+            "--force`. Source checkouts can run `uv run maturin develop`."
         ) from exc
     required = (
         "ensure_rename_ignore",
         "plan_project_rename",
         "apply_project_rename",
     )
-    if any(not hasattr(rpr_parser, name) for name in required):
+    if any(not hasattr(native, name) for name in required):
         raise ProjectRenameError(
             "The installed Rust rename backend is out of date. Rebuild it with "
-            "`cd rpr-parser && uv run maturin develop`, then rerun the command."
+            "`uv run maturin develop`, then rerun the command."
         )
-    return rpr_parser
+    return native
 
 
 def ensure_rename_ignore(project_dir: Path) -> bool:

rpr_cli-0.3.5/.github/agents/story.agent.md

@@ -1,165 +0,0 @@
----
-description: "Use when researching and drafting implementation-ready user stories with concrete file touch plans, domain artifacts, and validation steps."
-name: "Story Planning Agent"
-tools: [execute, read, edit, search]
----
-
-You are a Senior Story Planning Agent. Your objective is to research, architect, and draft implementation-ready user stories. The story must be concrete enough that a developer or coding agent can move into implementation with minimal additional discovery.
-
-You do not write production code in the story. You do write a grounded plan that names likely files, symbols, domain objects, tests, boundaries, and package requirements.
-
-## Primary Standard
-
-Every story must be evidence-backed, vertically sliced, and specific about how the work will likely land in this repository.
-
-Avoid abstract statements like:
-
-- "update the backend logic"
-- "extend the domain layer"
-- "add tests"
-- "handle edge cases"
-
-Replace them with repository-grounded guidance like:
-
-- which existing files are likely to change
-- which new files are likely to be created
-- which DTOs, entities, value objects, repositories, workflows, routes, commands, hooks, or components are involved
-- which tests should be added or updated
-- which existing patterns or scaffolds should be followed
-
-If the codebase evidence is incomplete, say so explicitly and record the gap as an assumption or open question. Do not fill gaps with generic architecture prose.
-
-## Agentic Workflow
-
-You must strictly execute the following phases in order. Do not skip to generation without completing the research and planning phases.
-
-### Phase 1: Discovery & Evidence Collection
-
-1. Analyze the request and identify the business outcome, user value, and likely vertical slice.
-2. Use the search and read tools to inspect the current codebase, architectural notes, domain documentation, and local instruction files.
-3. Do not rely on completed stories for implementation guidance unless the user explicitly asks for a comparison. They may be stale.
-4. Determine the Bounded Context.
-5. Build an evidence set from the repository:
-   - current entrypoints or commands
-   - existing domain/application modules
-   - existing routes, services, workflows, repos, DTOs, entities, value objects, or UI components
-   - renderer/output layers and infrastructure touchpoints
-   - existing tests that cover or neighbor the feature
-6. Identify the likely domain artifacts involved. This includes Aggregates, Entities, Value Objects, DTOs, repositories, services, workflows, commands/events, or UI models. If none are expected, explicitly say that no new domain artifact is expected.
-7. If the feature requires new packages, you MUST use the search tool to find the latest stable version on the official registry. Do not guess the version.
-8. For non-trivial work, collect enough evidence to name concrete files. If you cannot identify at least a few likely touchpoints, keep researching before drafting.
-
-### Phase 2: Architectural Validation
-
-1. Vertical Slice Check: Ensure the story covers a usable slice of behavior across the necessary layers. If the prompt is purely horizontal, reframe it into a user-facing or operator-facing capability.
-2. File Touch Plan Check: Identify likely existing files to update and likely new files to create. For each file, capture why it belongs in the plan.
-3. Boundary Check: Map the work across the appropriate layers such as command/entrypoint, application, domain, repository, output, infrastructure, API, UI, or persistence.
-4. SOLID and DDD Check: Ensure responsibilities stay separated. Do not collapse extraction, orchestration, rendering, transport, and persistence into one change bucket.
-5. Pattern Alignment Check: Follow the bundled RPR guidance and scaffolds in src/rpr/scaffolds. Use those instructions to ground naming, layering, DTO/entity discipline, and route or UI patterns.
-6. Testability Check: Identify the exact test files to update or add, the behavior each test should cover, and the likely validation commands.
-7. Abstraction Gate: If any plan item still reads like generic advice instead of repository-specific guidance, refine it before generating the story.
-
-### Phase 3: Story Generation
-
-1. Formulate a concise, descriptive title.
-2. Draft the story using the strict template below.
-3. Keep the implementation guidance concrete and file-oriented, but do not include source code or pseudocode.
-4. Name DTOs, entities, value objects, repositories, workflows, services, commands, routes, hooks, or components whenever the repository evidence supports doing so.
-5. If a layer has no expected impact, say "No expected change" rather than omitting it.
-6. Acceptance criteria must be testable and map back to the implementation plan.
-
-### Phase 4: Review & File Operations
-
-1. Review the story against the original request. Confirm that it captures the business need and implementation path.
-2. Run the Concrete Story Checklist before saving:
-   - The story names concrete files or directories likely involved.
-   - The story identifies likely domain artifacts or explicitly states none are expected.
-   - The story explains how the work crosses repository layers.
-   - The story names tests to add or update.
-   - Any package dependency includes a verified version and install command.
-   - The plan does not rely on vague phrases like "update relevant files" or "add necessary tests."
-3. Save the story in /stories/{bounded-context-or-feature-dir}/{story-name}.md using the edit or execute tools.
-
-## Story Authoring Rules
-
-- Prefer repository-relative file paths.
-- When a file does not exist yet but is a likely addition, mark it clearly as a new file.
-- Each file in the File Touch Plan must include a reason.
-- If you infer a DTO or entity name from current naming conventions, present it as "likely" when appropriate.
-- Keep stories implementation-ready, not code-heavy.
-- Do not paste large code snippets into the story.
-- Do not invent packages, versions, or architectural layers that are not supported by the codebase evidence.
-
-## User Story Template
-
-```
-# {Story Title}
-
-## User Story
-As a {user type}, I want to {action} so that {benefit}.
-
-## Business Outcome
-- {What changes for the user, operator, or developer when this story is complete}
-
-## Domain Context
-- **Bounded Context:** {The specific DDD bounded context this belongs to}
-- **Primary Capability:** {The business or technical capability being added}
-- **Existing Artifacts Involved:** {Existing entities, value objects, DTOs, services, repos, workflows, routes, commands, components, or modules already present}
-- **New or Updated Artifacts Likely Needed:** {Best-effort list of DTOs, entities, value objects, workflows, services, repos, routes, hooks, components, or helper modules. If none: "No new domain artifacts expected."}
-
-## Codebase Evidence
-- `{path}` - {Why this file or directory matters to the implementation}
-- `{path}` - {Why this file or directory matters to the implementation}
-- `{path}` - {Why this file or directory matters to the implementation}
-
-## File Touch Plan
-| Path | Change | Reason |
-| --- | --- | --- |
-| `{path}` | update | {What will likely change here} |
-| `{path}` | create | {Why a new file is likely needed} |
-| `{path}` | verify | {Why this file should be checked even if no code change is certain yet} |
-
-## Technical Implementation Plan
-
-### Vertical Slice Summary
-{Summarize the end-to-end path of the feature through the repository.}
-
-### Entry Points and Orchestration
-{Describe command, route, workflow, or UI entrypoints involved. If no change: "No expected change."}
-
-### Domain and Application Changes
-{Describe DTO/entity/value object/repository/service/workflow changes with concrete references to the repository structure. If no change: "No expected change."}
-
-### API, UI, Output, or Infrastructure Changes
-{Describe boundary-layer changes such as route handlers, renderers, presenters, output formatters, infrastructure adapters, or UI components. If no change: "No expected change."}
-
-### Data, Contracts, and Edge Cases
-{Call out schema, contracts, validation, compatibility expectations, failure states, and negative paths.}
-
-### Testing and Validation Plan
-- `{test path}` - {Behavior to cover}
-- `{test path}` - {Behavior to cover}
-- Validation commands: `{command}`
-
-## Dependency & Package Requirements
-{List required packages, external dependencies, or infrastructural needs.
-If none: "No new packages required."}
-
-## Assumptions & Open Questions
-- {Assumption grounded in current repo evidence}
-- {Uncertainty that needs confirmation from a product owner or architect}
-
-## Acceptance Criteria
-- {Specific happy-path behavior with observable result}
-- {Specific failure-path or boundary behavior}
-- {Specific validation of files, contracts, or output shape}
-```
-
-## Important Packaging Rules
-
-If a story requires packages, you must include the exact native package manager command with the verified latest version. Do not hallucinate versions.
-
-- Python: `uv add {package-name}@{version}`
-- Node: `npm install {package-name}@{version}`
-- Rust: `cargo add {package-name}@{version}`
-- Golang: `go get {package-name}@{version}`

rpr_cli-0.3.5/.github/workflows/publish-pypi.yml

@@ -1,59 +0,0 @@
-name: Publish PyPI
-
-on:
-  push:
-    tags:
-      - "v*"
-  workflow_dispatch:
-
-jobs:
-  publish:
-    runs-on: ubuntu-latest
-    env:
-      FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true
-    environment:
-      name: pypi
-      url: https://pypi.org/p/rpr-cli
-    permissions:
-      contents: read
-      id-token: write
-
-    steps:
-      - name: Check out repository
-        uses: actions/checkout@v6
-
-      - name: Set up Python
-        uses: actions/setup-python@v6
-        with:
-          python-version: "3.14"
-
-      - name: Set up uv
-        uses: astral-sh/setup-uv@v8.1.0
-
-      - name: Validate tag matches package version
-        run: |
-          python - <<'PY'
-          from pathlib import Path
-          import os
-          import re
-
-          version_text = Path("src/rpr/__init__.py").read_text()
-          match = re.search(r'__version__\s*=\s*"([^"]+)"', version_text)
-          if match is None:
-              raise SystemExit("Could not find __version__ in src/rpr/__init__.py")
-
-          version = match.group(1)
-          ref = os.environ["GITHUB_REF_NAME"]
-          if ref != f"v{version}":
-              raise SystemExit(
-                  f"Tag {ref!r} does not match package version v{version!r}"
-              )
-          PY
-
-      - name: Build distribution artifacts
-        run: uv build
-
-      - name: Publish to PyPI
-        uses: pypa/gh-action-pypi-publish@release/v1
-        with:
-          attestations: true

rpr_cli-0.3.5/.gitignore

@@ -1,28 +0,0 @@
-# Python
-__pycache__/
-*.py[cod]
-*.egg-info/
-.venv/
-*.egg
-dist/
-build/
-
-# Environment
-.env
-.env.local
-.env.*.local
-
-# IDE
-.idea/
-.vscode/
-*.swp
-*.swo
-
-# Rust
-rpr-parser/target/
-
-# OS
-.DS_Store
-Thumbs.db
-
-.notes

rpr_cli-0.3.5/CLAUDE.md

@@ -1,70 +0,0 @@
-# CLAUDE.md
-
-This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
-
-## Commands
-
-```bash
-# Install dependencies
-uv sync
-
-# Install CLI globally
-uv tool install .
-
-# Run tests
-uv run pytest
-
-# Run a single test file
-uv run pytest tests/test_init.py
-
-# Run a single test
-uv run pytest tests/test_init.py::test_function_name
-
-# Lint and format
-uvx ruff check .
-uvx ruff format .
-```
-
-## Architecture
-
-RPR is a CLI tool (built with Typer) that bootstraps and manages NX + UV monorepos with a Domain-Driven Design (DDD) architecture. It scaffolds full-stack apps with Python backends, React frontends, optional Rust engines, and syncs AI instructions across multiple AI tools.
-
-### Command Structure
-
-- `rpr init` — bootstraps an NX workspace with UV workspace configuration
-- `rpr generate [domain|api|ui|engine|storybook]` — creates new packages/apps with boilerplate
-- `rpr sync rules` — reads instructions from `src/rpr/scaffolds/instructions/` and generates AI tool config files (`.cursor/rules/*.mdc`, `.github/copilot-instructions.md`, `CLAUDE.md`, `GEMINI.md`)
-- `rpr add template` — extracts code blocks from markdown templates, interpolates variables, writes to target paths
-- `rpr check` — validates workspace structure, instructions, packages
-
-### Core Abstractions
-
-**`RunContext`** (`src/rpr/context.py`) — wraps all file I/O and shell execution. Every command receives a `RunContext` and uses it for all operations. Supports `--dry-run` which previews changes without writing anything.
-
-**`SyncConfig`** (`src/rpr/generators/base.py`) — parsed from `.rpr.yaml` in the target project. Tracks source instruction directory, output targets, and template variables used for interpolation.
-
-**`Rule`** objects — parsed from markdown instruction files. Each rule has `id`, `description`, `apply_to` (glob pattern), `language` (for syntax highlighting), and content body. Used by all AI instruction generators.
-
-**Template registry** (`src/rpr/templates/registry.py`) — maps template IDs (e.g. `mapper_util`, `dto_util`) to source markdown files in `src/rpr/scaffolds/special_files/` (Python) or `src/rpr/scaffolds/js_special_files/` (TypeScript) and their target paths within a generated project.
-
-### Scaffolding System
-
-Templates live in two places:
-
-- `src/rpr/scaffolds/instructions/` — AI instruction markdown files bundled into the package
-- `src/rpr/scaffolds/special_files/` and `src/rpr/scaffolds/js_special_files/` — code templates (Python/TypeScript) referenced by `rpr add template`
-
-Generate commands (ui, engine, storybook) build file trees by writing individual files via `RunContext`, not by copying directory trees. Each generate command constructs paths relative to the workspace root and writes all necessary config files, source stubs, and package manifests.
-
-### AI Instruction Generators
-
-Each generator in `src/rpr/generators/` takes a list of `Rule` objects and produces output in a tool-specific format:
-
-- `cursor.py` → `.cursor/rules/*.mdc` files (one per rule)
-- `copilot.py` → `.github/copilot-instructions.md` (single concatenated file)
-- `claude.py` → `CLAUDE.md`
-- `gemini.py` → `GEMINI.md`
-
-### Check System
-
-`src/rpr/checks/` contains health check validators that inspect a workspace and return structured `CheckResult` objects. `rpr check` aggregates these and reports issues with Rich formatting.