@juicesharp/rpiv-pi 0.8.1 → 0.8.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@juicesharp/rpiv-pi",
-  "version": "0.8.1",
+  "version": "0.8.3",
   "description": "Skill-based development workflow for Pi Agent — discover, research, design, plan, implement, validate",
   "keywords": [
     "pi-package",

package/skills/annotate-guidance/SKILL.md

@@ -30,7 +30,7 @@ Use the current working directory as the target project by default. If the user
 
    **Agent B — Architecture and conventions:**
    - subagent_type: `codebase-locator`
-   - Prompt: "Identify the architectural layers, folder roles, and framework conventions in [target directory]. Determine: What architecture pattern is used (clean architecture, MVC, monorepo, microservices, hexagonal, etc.)? What are the main layers/modules? What frameworks and languages are present? What build system is used? For each main layer/module, check if it contains internal sub-layers with distinct architectural roles. If it does, explicitly flag each sub-layer as a guidance target candidate with: (a) path, (b) role/responsibility, (c) approximate file count, (d) how its patterns differ from siblings. Frontend frameworks (Angular, React, Vue, etc.) almost always have distinct sub-layers — components, services, shared/base classes, state management — report each separately."
+   - Prompt: "Identify the architectural layout of [target directory] from path shape and manifest files — NO content analysis. Detect: (1) Architecture pattern inferred from folder shape — clean-arch via Domain/Application/Infrastructure dirs; MVC via Controllers/Models/Views; monorepo via packages/* + workspaces; microservices via services/* with individual manifests; hexagonal via ports/adapters. (2) Main layers/modules — top-level source directories + their names. (3) Frameworks and languages from manifest files (package.json dependencies, *.csproj TargetFramework, pyproject.toml, go.mod, Cargo.toml) and file extensions. (4) Build system from build-config filenames (vite/webpack/tsup/esbuild configs, Makefile, nx.json, turbo.json, dotnet .sln). For each main layer/module, check sub-directory composition. If sub-directories with distinct names/roles exist, flag each as a guidance target candidate with: (a) path, (b) role inferred from folder name (controllers/, services/, entities/, components/, stores/, etc.), (c) file count via ls, (d) how its sub-directory composition differs from sibling layers. Use grep/find/ls only. Do not read file contents. Pass 2 runs codebase-analyzer + codebase-pattern-finder per target folder for deep analysis."
 
    - While agents run, read .gitignore yourself to understand exclusion rules
 

package/skills/annotate-inline/SKILL.md

@@ -30,7 +30,7 @@ Use the current working directory as the target project by default. If the user
 
    **Agent B — Architecture and conventions:**
    - subagent_type: `codebase-locator`
-   - Prompt: "Identify the architectural layers, folder roles, and framework conventions in [target directory]. Determine: What architecture pattern is used (clean architecture, MVC, monorepo, microservices, hexagonal, etc.)? What are the main layers/modules? What frameworks and languages are present? What build system is used? For each main layer/module, check if it contains internal sub-layers with distinct architectural roles. If it does, explicitly flag each sub-layer as a CLAUDE.md target candidate with: (a) path, (b) role/responsibility, (c) approximate file count, (d) how its patterns differ from siblings. Frontend frameworks (Angular, React, Vue, etc.) almost always have distinct sub-layers — components, services, shared/base classes, state management — report each separately."
+   - Prompt: "Identify the architectural layout of [target directory] from path shape and manifest files — NO content analysis. Detect: (1) Architecture pattern inferred from folder shape — clean-arch via Domain/Application/Infrastructure dirs; MVC via Controllers/Models/Views; monorepo via packages/* + workspaces; microservices via services/* with individual manifests; hexagonal via ports/adapters. (2) Main layers/modules — top-level source directories + their names. (3) Frameworks and languages from manifest files (package.json dependencies, *.csproj TargetFramework, pyproject.toml, go.mod, Cargo.toml) and file extensions. (4) Build system from build-config filenames (vite/webpack/tsup/esbuild configs, Makefile, nx.json, turbo.json, dotnet .sln). For each main layer/module, check sub-directory composition. If sub-directories with distinct names/roles exist, flag each as a CLAUDE.md target candidate with: (a) path, (b) role inferred from folder name (controllers/, services/, entities/, components/, stores/, etc.), (c) file count via ls, (d) how its sub-directory composition differs from sibling layers. Use grep/find/ls only. Do not read file contents. Pass 2 runs codebase-analyzer + codebase-pattern-finder per target folder for deep analysis."
 
    - While agents run, read .gitignore yourself to understand exclusion rules
 

package/skills/code-review/SKILL.md

@@ -137,7 +137,7 @@ Spawn these agents in parallel using the Agent tool. Each receives the `## Disco
 
 **Dependencies lens:**
 - subagent_type: `codebase-analyzer`
-- Prompt (only when `ManifestChanged` is true; otherwise SKIP and set `dependency_issues: 0`, `passes: [quality, security]`):
+- Prompt (only when `ManifestChanged` is true; otherwise SKIP this lens and omit the `### Dependencies` H3 block from the artifact):
   ```
   Known Context:
   [paste Discovery Map verbatim]
@@ -200,11 +200,8 @@ Spawn these agents in parallel using the Agent tool. Each receives the `## Disco
 2. **Probe advisor availability** — attempt a probe by checking whether `advisor` is in the active tool set (main-thread visibility). If yes, proceed to advisor path; otherwise take the inline path.
 
 3. **Advisor path** (when advisor is active):
-   - Print a main-thread `## Pre-Adjudication Findings` block containing the compiled evidence and tentative severity map. This ensures the findings are persisted into `getBranch()` before the advisor call.
-   - Call `advisor()` (zero-param). Wait for the response.
-   - On success: paste the advisor's prose verbatim into the artifact's `## Advisor Adjudication` section (Step 6) and note `advisor_used: true` + `advisor_model: [model-id]` in frontmatter.
-   - On `"aborted"` or empty text: set `advisor_used: false`, skip the adjudication section, fall through to the inline path.
-   - On `"error"`: note the error inline in the adjudication section as `advisor error: <message>`; continue with inline reconciliation alongside.
+   - Print a main-thread `## Pre-Adjudication Findings` block first — the advisor reads `getBranch()`, so evidence must be flushed before the call.
+   - Call `advisor()` (zero-param). If it returns usable prose, paste it verbatim into `## Advisor Adjudication` and skip the inline path. Otherwise fall through.
 
 4. **Inline path** (advisor unavailable or errored):
    - Run a dimension-sweep modeled on `skills/design/SKILL.md:83-116`: Data model / API surface / Integration / Scope / Verification / Performance.
@@ -226,7 +223,7 @@ Quality: [C🔴/I🟡/S🔵/D💭]
 Security: [C/I/S/D]
 Dependencies: [C/I/S/D | not-applicable]
 Precedents: [N composite lessons, top: "[one-line]"]
-Advisor: [used (model) | unavailable]
+Advisor: [adjudicated | inline]
 ```
 
 Wait for the developer's response. Then ask **one question at a time**, waiting for each answer.
@@ -261,16 +258,9 @@ branch: [Branch]
 commit: [Short hash]
 review_type: [commit|pr|staged|working]
 scope: "[What was reviewed]"
-files_changed: [N]
 critical_issues: [Count across all lenses]
 important_issues: [Count]
 suggestions: [Count]
-quality_issues: [Count]
-security_issues: [Count]
-dependency_issues: [Count | 0 when not-applicable]
-passes: [quality, security, dependencies]   # omit dependencies when not-applicable
-advisor_used: [true|false]
-advisor_model: [provider:id]                 # only when advisor_used is true
 status: [approved|needs_changes|requesting_changes]
 tags: [code-review, relevant-components]
 last_updated: [YYYY-MM-DD]
@@ -311,7 +301,7 @@ last_updated_by: [User]
 - `file:line` — [architectural question]
 
 ### Dependencies
-(Omit this H3 block entirely when `passes` excludes `dependencies`.)
+(Omit this H3 block entirely when the Dependencies lens was skipped — i.e., `ManifestChanged` was false.)
 #### 🔴 Critical
 - `dep@ver` (`package.json:line`) — [CVE id + link + affected-range + fix version]
 #### 🟡 Important
@@ -337,8 +327,8 @@ last_updated_by: [User]
 [Links to thoughts/ docs referenced by precedent-locator; one line each, no summaries.]
 
 ## Advisor Adjudication
-(Omit when `advisor_used: false`.)
-[Advisor model prose pasted VERBATIM. Do not edit or paraphrase. If `advisor error:` prefix is present, leave it as-is.]
+(Omit this H2 entirely when the advisor did not run — its presence IS the signal that adjudication occurred.)
+[Advisor model prose pasted VERBATIM. Do not edit or paraphrase.]
 
 ## Reconciliation Notes
 (Include only when the inline path ran, OR when developer dispute in Step 5 moved a severity.)
@@ -355,7 +345,7 @@ Review written to:
 `thoughts/shared/reviews/[filename].md`
 
 [C] critical, [I] important, [S] suggestions across [Q] quality, [Se] security, [D] dependency issues.
-Advisor: [used (model) | unavailable]
+Advisor: [adjudicated | inline]
 Status: [verdict]
 
 Top items:

package/skills/design/SKILL.md

@@ -57,16 +57,16 @@ This is NOT a discovery sweep. Focus on DEPTH (how things work, what patterns to
    - Use **codebase-pattern-finder** to find existing implementations to model after — the primary template for code shape
    - Use **codebase-analyzer** to understand HOW integration points work in detail
    - Use **integration-scanner** to map the wiring surface — inbound refs, outbound deps, config/DI/event registration
-   - Use **precedent-locator** to find similar past changes in git history — what commits introduced comparable features, what broke, and what lessons apply to this design
+   - Use **precedent-locator** to find similar past changes in git history — what commits introduced comparable features, what broke, and what lessons apply to this design. Only when `git_commit` is available (not `no-commit`); otherwise skip and note "git history unavailable" in Verification Notes.
 
    **Novel work** (new libraries, first-time patterns, no existing codebase precedent):
    - Add **web-search-researcher** for external documentation, API references, and community patterns
    - Instruct it to return LINKS with findings — include those links in the final design artifact
 
-   Agent prompts should focus on:
-   - "Find the implementation pattern I should model after for [feature type]"
-   - "How does [integration point] work in detail — show me the wiring"
-   - "What connects to [component] — inbound refs, outbound deps, config"
+   Agent prompts should focus on (labeled by target agent):
+   - **codebase-pattern-finder**: "Find the implementation pattern I should model after for [feature type]"
+   - **codebase-analyzer**: "How does [integration point] work in detail"
+   - **integration-scanner**: "What connects to [component] — inbound refs, outbound deps, config"
 
    NOT: "Find all files related to X" — that's discovery's job, upstream of this skill.
 

package/skills/discover/SKILL.md

@@ -71,7 +71,7 @@ Before Step 1, create a todo list tracking every step below (Step 1 through Step
    - Do NOT ask a locator to also cover packaging, docs, runtime wiring, and permissions unless they are the same seam
 
    Example prompts:
-   - codebase-locator: "Find ALL files that [implement/call/emit/subscribe to/import] [specific component]. For each file, report the key function signatures, exported types, and import chains. Search exhaustively — grep for method names, class names, event strings."
+   - codebase-locator: "Find ALL files that [implement/call/emit/subscribe to/import] [specific component]. For each file, report the key function names, class/type names, and import chains. Search exhaustively — grep for method names, class names, event strings. Report only declaration lines via grep match anchors (e.g., `file.ts:42`); full multi-line signatures and type bodies are captured by the orchestrator in Step 3 when it reads key files for depth."
    - integration-scanner: "What connects to [area] — inbound refs, outbound deps, config/DI/event wiring. For each connection, report the function/method that creates it."
    - thoughts-locator: "What existing docs/decisions exist about [topic]"
 

package/skills/outline-test-cases/SKILL.md

@@ -53,7 +53,7 @@ First, detect the project's technology stack by checking for framework indicator
 
 Spawn parallel discovery agents using the Agent tool:
 - Use the **codebase-locator** agent to find all registered routes, navigation menus, and page entry points
-- Use the **codebase-locator** agent to find all frontend HTTP API call sites and which backend URLs they hit
+- Use the **codebase-locator** agent to find all frontend HTTP API call sites — report each call-site `file:line` and the literal URL template string found at the call site (e.g., ``${base}/users/${id}``). Frontend-to-backend URL correlation happens orchestrator-side in Step 3's Cross-Reference synthesis (`skills/outline-test-cases/SKILL.md:71-79`) using the backend-controller findings from the next agent.
 - Use the **codebase-locator** agent to find all backend API controllers and route handlers
 - Use the **test-case-locator** agent to find existing test cases in `.rpiv/test-cases/` to avoid duplicates
 

package/skills/research/SKILL.md

@@ -81,11 +81,11 @@ Question 2: [Full dense question paragraph]
 For each question, provide your analysis with exact file:line references. Note connections between the questions where the same code serves multiple roles. Focus on DEPTH — trace the actual code, don't just locate it.
 ```
 
-**Precedent sweep (always spawn):**
-Spawn one `precedent-locator` agent alongside the question agents:
-"Find similar past changes involving [list key files from Discovery Summary]. Search git log for commits that touched these files, similar commit messages, and follow-up fixes. Research topic: [original query]."
+**Precedent sweep (git-gated):**
 
-This agent runs with full knowledge of discovered files — its findings go into Precedents & Lessons, not tied to a specific question.
+When `git_commit` is available (not `no-commit`), spawn one `precedent-locator` agent alongside the question agents with prompt: "Find similar past changes involving [list key files from Discovery Summary]. Search git log for commits that touched these files, similar commit messages, and follow-up fixes. Research topic: [original query]."
+
+Findings go into Precedents & Lessons. Otherwise skip and note "git history unavailable" there.
 
 **Wait for ALL agents to complete** before proceeding.
 

package/skills/write-test-cases/SKILL.md

@@ -95,7 +95,7 @@ Using the entry points discovered in Step 2 (validated against _meta.md when ava
 
 **Agent D — Postcondition Discovery:**
 - subagent_type: `integration-scanner`
-- Prompt: "Find all side effects triggered by {feature name} actions{endpoint_scope}. Look for: domain events published, message handlers invoked, email/notification triggers, external API calls, database cascades, cache invalidations, audit log entries, webhook dispatches. For each side effect, report: what triggers it (which action/endpoint), what it does, and where the handler code lives. These become postconditions in test cases.{scope_context}"
+- Prompt: "Find all side effects triggered by {feature name} actions{endpoint_scope}. Look for: domain events published, message handlers invoked, email/notification triggers, external API calls, database cascades, cache invalidations, audit log entries, webhook dispatches. For each side effect, report: what triggers it (which action/endpoint) and where the handler code lives (file:line). Do NOT describe what the handler does — only locate it. These locations become postconditions in test cases.{scope_context}"
 
 Wait for ALL agents to complete before proceeding.