@securityreviewai/securityreview-kit 0.1.50 → 0.1.51

package/dist/scaffold/rules.js

@@ -108,15 +108,15 @@ function additionalContext(config) {
         "",
         `Configured project: ${project.name} (${project.slug}, ${project.id})`,
         "",
-        "For any request with security impact, follow this order:",
+        "For any request with security impact, this is a hard pre-write gate. Do not create, edit, or patch code until steps 1-3 are complete:",
         "",
         `1. Resolve the tenant/project with ${TOOL_PROJECT} using project_id="${project.id}" or project_slug="${project.slug}".`,
         `2. Fetch VibeReview guardrails with ${TOOL_GUARDRAILS}, shortlist relevant guardrails, and preserve that shortlist.`,
         "3. Run PWNISMS threat modelling before implementation.",
         "4. Implement secure code using the threat model and shortlisted guardrails.",
-        `5. Write one markdown artifact under .vibreview/scans/ and call ${TOOL_SYNC} immediately after writing it.`,
+        `5. Write one markdown artifact under .vibreview/scans/ and call ${TOOL_SYNC} with the raw markdown string immediately after writing it.`,
         "",
-        "No deferral. No local profiling. The main agent owns the final markdown sync.",
+        "No deferral. No code before guardrails. No JSON summaries for sync. No local profiling. The main agent owns the final markdown sync.",
     ].join("\\n");
 }
 function codexPayload(config, hookEventName) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@securityreviewai/securityreview-kit",
-  "version": "0.1.50",
+  "version": "0.1.51",
   "type": "module",
   "publishConfig": {
     "access": "public"

package/templates/shared/content.md

@@ -6,12 +6,14 @@ These instructions are always active for security-relevant coding work. Keep thi
 
 ## Core Workflow
 
-For any task that touches auth, authorization, input handling, secrets, network, data storage, dependencies, new APIs/endpoints, infrastructure, or code handling untrusted data:
+For any task that touches auth, authorization, input handling, secrets, network, data storage, dependencies, new APIs/endpoints, infrastructure, or code handling untrusted data, this workflow is a hard pre-write gate.
+
+Do not write, edit, patch, or generate implementation code until guardrails have been fetched and shortlisted and PWNISMS threat modelling has been completed. If the user asks for code immediately, still run the pre-write gate first.
 
 1. **Fetch Vibe Guardrails first.**
    - Read and follow `{{GUARDRAILS_SELECTION_SKILL_DIR}}/SKILL.md`.
    - Resolve the SRAI project with `find_project_by_name` using `name="<SRAI_PROJECT_NAME>"`.
-   - Call `get_guardrails`, shortlist only the relevant project guardrails, then hydrate the exact shortlist with `get_guardrail_by_id`.
+   - Call `get_guardrails`, shortlist only the relevant project guardrails, then preserve the exact returned guardrail entries.
    - Preserve that exact shortlist in context for implementation and the final VibeReview sync step.
 
 2. **Run PWNISMS threat modelling before implementation.**
@@ -21,6 +23,7 @@ For any task that touches auth, authorization, input handling, secrets, network,
    - Cross-reference each meaningful threat with the shortlisted guardrails.
 
 3. **Implement secure code using both inputs.**
+   - This step may start only after steps 1 and 2 are complete.
    - Treat applicable `must` guardrails as mandatory.
    - Treat applicable `must_not` guardrails as hard prohibitions.
    - Use the PWNISMS findings to guide design, validation, authorization, logging, secrets handling, dependency choices, and abuse controls.
@@ -28,12 +31,12 @@ For any task that touches auth, authorization, input handling, secrets, network,
 
 4. **Write and sync the VibeReview markdown last.**
    - Read and follow `{{VIBEREVIEW_SYNC_SKILL_DIR}}/SKILL.md`.
-   - After threat modelling is created or updated, or after guardrails are enforced during implementation, the main agent must write or update a structured `.md` artifact under `vibereview/`.
+   - After threat modelling is created or updated, or after guardrails are enforced during implementation, the main agent must write or update a structured `.md` artifact under `.vibreview/scans/`.
    - Do not delegate markdown authoring to a subagent. The same agent that performed the work should author the artifact so the context stays intact.
    - Use the skill's structure and validation checklist rather than improvising the markdown format.
    - Reuse the exact existing guardrails shortlisted earlier, include any `ide_generated` guardrails, and only include grounded code snippets from actual code.
-   - Call `sync_ai_ide_markdown` directly with the finished markdown artifact before finalizing the task.
-   - If sync fails, keep the file in `vibereview/`, report the failure, and do not pretend synchronization succeeded.
+   - Call `sync_ai_ide_markdown` directly with the finished raw markdown content before finalizing the task. Do not sync JSON summaries, JSON objects, or extracted event JSON.
+   - If sync fails, keep the file in `.vibreview/scans/`, report the failure, and do not pretend synchronization succeeded.
 
 ## When To Skip
 
@@ -52,6 +55,6 @@ The normal coding workflow is guardrails selection, PWNISMS threat modelling, se
 | Purpose | Tools |
 |---|---|
 | Project resolution | `find_project_by_name`, `list_projects`, `create_project`, `get_project` |
-| Guardrails | `get_guardrails`, `get_guardrail_by_id` |
+| Guardrails | `get_guardrails` |
 | VibeReview sync | `sync_ai_ide_markdown` |
 | Profiler only | `update_vibe_profile`, `write_default_pack` are used by init-time profiling, not normal coding tasks |

package/templates/shared/guardrails-selection.md

@@ -1,6 +1,6 @@
 ---
 name: guardrails-selection
-description: Analyze the developer request, infer the security categories and likely threats involved, shortlist the most relevant project guardrails, then hydrate the exact guardrails with get_guardrail_by_id before implementation. Use for every security-relevant code task before code is written and preserve the shortlist for the final VibeReview sync.
+description: Analyze the developer request, infer the security categories and likely threats involved, shortlist the most relevant project guardrails, then preserve the exact returned guardrail records before implementation. Use for every security-relevant code task before code is written and preserve the shortlist for the final VibeReview sync.
 ---
 
 # Guardrails Selection
@@ -9,13 +9,15 @@ Configured SRAI project name: `<SRAI_PROJECT_NAME>`
 
 Use this skill whenever code will be created or modified and the task has any security surface.
 
+This skill is a hard pre-write gate. Do not write, edit, patch, or generate implementation code until this skill has produced the active guardrail shortlist and the PWNISMS skill has used that shortlist for threat modelling.
+
 This skill exists to stop the IDE from treating the full `get_guardrails` result as an unstructured blob. The workflow is:
 
 1. Understand the request deeply.
 2. Infer which security categories are in play.
 3. Predict the threats that might occur for this exact task.
 4. Shortlist only the guardrails that mitigate those threats.
-5. Fetch the exact shortlisted guardrails with `get_guardrail_by_id`.
+5. Preserve the exact shortlisted guardrails returned by the project guardrail bundle.
 6. Carry that same shortlist forward into implementation and the final VibeReview markdown sync.
 
 Do not skip the analysis step. Do not rely on title-matching alone. Do not dump every guardrail into the final answer.
@@ -94,7 +96,7 @@ The shortlist should be threat-led, not catalog-led.
 1. Call `find_project_by_name` with `name="<SRAI_PROJECT_NAME>"` to obtain `project_id`.
 2. Call `get_guardrails` with `project_id`.
 
-Treat `get_guardrails` as the broad catalog. Do not treat it as the final set of instructions.
+Treat `get_guardrails` as the broad project catalog. Do not treat the whole catalog as the final set of instructions. The returned entries are already the authoritative guardrail records for this project; shortlist from those exact records and preserve their ids, titles, rule types, categories, and instructions.
 
 Assume each returned guardrail includes the fields needed for selection, including a stable identifier for follow-up retrieval, plus:
 
@@ -124,15 +126,11 @@ Examples:
 - If the task introduces parsing, uploads, template expansion, or object hydration, prioritize input validation, file handling, deserialization, and denial-of-service guardrails.
 - If the task moves security decisions into the browser or mobile client, prioritize client-side trust, token storage, server-side revalidation, and privilege-boundary guardrails.
 
-### Step 3: Hydrate exact shortlisted guardrails
-
-For every shortlisted existing guardrail, call `get_guardrail_by_id` to retrieve the exact guardrail that will govern implementation.
+### Step 3: Preserve exact shortlisted guardrails
 
-- Use `get_guardrail_by_id` for the shortlisted ids only.
-- If the tool supports batching, batch the shortlisted ids.
-- If the tool only supports one id at a time, call it once per shortlisted id.
+For every shortlisted existing guardrail, preserve the exact guardrail record returned by `get_guardrails`.
 
-Implementation must be driven by the hydrated shortlist from `get_guardrail_by_id`, not by vague memory from the broad catalog listing.
+Implementation must be driven by that exact shortlist, not by vague memory from the broad catalog listing. Do not re-query guardrails after implementation starts unless the shortlist is missing or the task scope materially changes.
 
 ### Step 4: Track the active shortlist in context
 
@@ -151,7 +149,7 @@ This shortlist is the source of truth for the rest of the session.
 
 ## Implementation Rules
 
-Once the shortlist is hydrated:
+Once the exact shortlist is preserved:
 
 - Every applicable `must` guardrail is mandatory.
 - Every applicable `must_not` guardrail is a hard prohibition.
@@ -162,7 +160,7 @@ When deciding whether a guardrail applies, prefer security-preserving inclusion
 
 ## VibeReview Sync Contract
 
-The final sync step must reuse the shortlist from this skill. It must not call `get_guardrails` or `get_guardrail_by_id` again.
+The final sync step must reuse the shortlist from this skill. It must not call `get_guardrails` again unless the task scope materially changed.
 
 Before `sync_ai_ide_markdown` is called, ensure the main agent context clearly contains:
 

package/templates/shared/threat-modelling.md

@@ -1,12 +1,13 @@
 ---
 name: PWNISMS Threat Modelling
-description: Security-first threat modelling workflow for code and architecture tasks. Walks all 7 PWNISMS categories, enforces vibe guardrails (secure by code), and synchronizes findings via a direct VibeReview markdown sync. Use before, during, and after implementation.
+description: Security-first threat modelling workflow for code and architecture tasks. Walks all 7 PWNISMS categories, enforces vibe guardrails (secure by code), and synchronizes findings via a direct VibeReview markdown sync. Use after guardrail selection and before implementation.
 ---
 
 # PWNISMS — Security-First Threat Modelling
 
 For EVERY security-relevant task (feature, bug fix, refactor, infra change, architecture design), run a threat model with PWNISMS.
 
+- This is a pre-implementation gate. Do not write, edit, patch, or generate implementation code until guardrail selection has completed and this PWNISMS pass has been completed.
 - Walk through all 7 categories explicitly.
 - If a category is not applicable, state it briefly and move on.
 - Anchor analysis to linked files, diffs, PRs, API specs, and diagrams whenever available.
@@ -20,7 +21,7 @@ Before deep analysis, ensure the project-specific guardrail shortlist exists:
 
 1. Use `{{GUARDRAILS_SELECTION_SKILL_DIR}}/SKILL.md`.
 2. Resolve the project with `find_project_by_name` using `name="<SRAI_PROJECT_NAME>"`.
-3. Call `get_guardrails`, shortlist intentionally for this task, then hydrate the exact shortlist with `get_guardrail_by_id`.
+3. Call `get_guardrails`, shortlist intentionally for this task, then preserve the exact returned guardrail records in context.
 4. Keep the shortlisted existing guardrails in context for implementation and the final VibeReview markdown sync.
 
 Do not perform project-profile exploration as part of PWNISMS. The old profile tools are not part of this workflow. Ground the threat model in the user request, repository code, diffs, architecture docs the user provides, and the shortlisted guardrails.
@@ -154,7 +155,7 @@ Dependency and delivery threats:
 
 After completing the PWNISMS analysis and before writing code:
 
-1. **Review the shortlisted hydrated guardrails** produced by `{{GUARDRAILS_SELECTION_SKILL_DIR}}/SKILL.md`.
+1. **Review the exact shortlisted guardrails** produced by `{{GUARDRAILS_SELECTION_SKILL_DIR}}/SKILL.md`.
 2. **Classify applicability** — For each shortlisted guardrail, determine if it applies to the current task.
 3. **Apply during code generation:**
    - `must` rules → mandatory implementation requirements. Every applicable `must` guardrail must be satisfied.
@@ -199,7 +200,7 @@ When discussing designs before code exists:
 
 ## Phase 5 — VibeReview Sync (Post Threat Modelling)
 
-**MANDATORY:** After every threat modeling step that produces or modifies threat content, the main agent must update the `vibereview/*.md` artifact and call `sync_ai_ide_markdown` directly.
+**MANDATORY:** After every threat modeling step that produces or modifies threat content, the main agent must update the `.vibreview/scans/*.md` artifact and call `sync_ai_ide_markdown` directly with raw markdown content.
 
 ### What triggers the VibeReview sync
 
@@ -207,20 +208,22 @@ When discussing designs before code exists:
 - Existing threat model updated or extended (new threats, refined mitigations, additional components)
 - Guardrails applied during a code-generation task (existing or IDE-generated)
 
+Do not call sync before implementation is complete unless the user explicitly asked only for threat modelling/design output. For coding tasks, the order is guardrail selection, PWNISMS, implementation, markdown sync.
+
 ### What the VibeReview markdown must contain
 
-The main agent writes a structured `.md` artifact under `vibereview/` and uploads it through `sync_ai_ide_markdown`. That markdown should contain:
+The main agent writes a structured `.md` artifact under `.vibreview/scans/` and uploads the raw markdown string through `sync_ai_ide_markdown`. That markdown should contain:
 
 - **Threat model findings**: threats mitigated, PWNISMS categories, severities, mitigations applied
 - **Best practices achieved**: structured practice entries with `practice_name`, `description`, and `category`
 - **Secure code snippets**: security-relevant code with explanations
-- **Guardrails applied**: all guardrails enforced during this session — both existing ones shortlisted earlier via `get_guardrails` + `get_guardrail_by_id` (`source: "existing"`) and new ones the IDE agent created on the fly (`source: "ide_generated"`), each with satisfaction status
+- **Guardrails applied**: all guardrails enforced during this session — both existing ones shortlisted earlier via `get_guardrails` (`source: "existing"`) and new ones the IDE agent created on the fly (`source: "ide_generated"`), each with satisfaction status
 - **Workflow metadata**: `chat_session_id`, `event_name` or `title`, required `summary`, and optional `workflow_name` / `workflow_description`
 
 ### How to sync
 
 1. Read and follow `{{VIBEREVIEW_SYNC_SKILL_DIR}}/SKILL.md`.
-2. Write or update a file under `vibereview/`, ideally `vibereview/<chat_session_id>-<slugified-title-or-event-name>.md`.
+2. Write or update a file under `.vibreview/scans/`, ideally `.vibreview/scans/<chat_session_id>-<slugified-title-or-event-name>.md`.
 3. Put `chat_session_id`, `summary`, and either `title` or `event_name` in frontmatter.
 4. Include the required sections:
    - `Best Practices Achieved`
@@ -234,9 +237,9 @@ The main agent writes a structured `.md` artifact under `vibereview/` and upload
    - every guardrail includes `title`, `rule_type`, `source`, and `satisfied`
    - OWASP mappings use exact IDs and names
    - snippets are grounded in actual code, not invented text
-   - no sibling `.md` files in `vibereview/` were read just to infer format or content
-6. Call `sync_ai_ide_markdown` directly with the finished markdown artifact.
-7. If sync fails, leave the artifact in `vibereview/` and report the failure clearly.
+   - no sibling `.md` files in `.vibreview/scans/` were read just to infer format or content
+6. Call `sync_ai_ide_markdown` directly with the finished raw markdown content. Do not pass JSON, extracted event objects, or summaries as the markdown.
+7. If sync fails, leave the artifact in `.vibreview/scans/` and report the failure clearly.
 
 ---
 
@@ -251,6 +254,6 @@ Before finalizing output, confirm:
 - [ ] Residual risk and follow-up actions are stated.
 - [ ] Vibe guardrails were fetched and enforced (all applicable `must`/`must_not` rules satisfied).
 - [ ] Guardrail compliance summary is included in the response (existing + IDE-generated).
-- [ ] The VibeReview markdown was written under `vibereview/` and `sync_ai_ide_markdown` was called successfully.
+- [ ] The VibeReview markdown was written under `.vibreview/scans/` and `sync_ai_ide_markdown` was called successfully with raw markdown content.
 
 If ANY box cannot be checked, you MUST flag the gap to the user with a specific remediation recommendation before finalizing the code.

package/templates/shared/vibereview-sync/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: vibereview-sync
-description: Write and synchronize a structured VibeReview markdown artifact under vibereview/ for the current security-relevant session. Use after threat modelling or guardrail-enforced implementation.
+description: Write and synchronize a structured VibeReview markdown artifact under .vibreview/scans/ for the current security-relevant session. Use only after guardrail selection, PWNISMS threat modelling, and guardrail-enforced implementation are complete.
 ---
 
 # VibeReview Markdown Sync
@@ -9,18 +9,20 @@ Configured SRAI project name: `<SRAI_PROJECT_NAME>`
 
 Use this skill whenever threat modelling output exists or security guardrail compliance must be synchronized to SRAI.
 
-This skill exists to make the markdown deterministic, grounded, and parseable without depending on a separate subagent. The same agent that performed the work should author the markdown and call `sync_ai_ide_markdown` directly.
+This skill exists to make the markdown deterministic, grounded, and parseable without depending on a separate subagent. The same agent that performed the work should author the markdown and call `sync_ai_ide_markdown` directly with raw markdown content.
+
+For coding tasks, do not use this skill until the required sequence is complete: guardrail selection, PWNISMS threat modelling, implementation, then markdown sync.
 
 ## Core Rules
 
-1. Write the artifact under `vibereview/`.
+1. Write the artifact under `.vibreview/scans/`.
 2. Author the markdown from the current task context only.
-3. Do not read other `.md` files in `vibereview/` to infer structure, copy content, or merge state.
+3. Do not read other `.md` files in `.vibreview/scans/` to infer structure, copy content, or merge state.
 4. If the current session file path is already known, update that one file directly.
 5. If the current session file does not exist yet, create a new file using a stable name such as:
 
 ```text
-vibereview/<chat_session_id>-<slugified-title-or-event-name>.md
+.vibreview/scans/<chat_session_id>-<slugified-title-or-event-name>.md
 ```
 
 6. Validate the markdown before calling `sync_ai_ide_markdown`.
@@ -28,7 +30,7 @@ vibereview/<chat_session_id>-<slugified-title-or-event-name>.md
 
 ## Why You Must Not Read Sibling Files
 
-Other markdown files in `vibereview/` may belong to different sessions, different workflows, or partially complete work. Reading them introduces drift and causes downstream extraction failures.
+Other markdown files in `.vibreview/scans/` may belong to different sessions, different workflows, or partially complete work. Reading them introduces drift and causes downstream extraction failures.
 
 Treat each VibeReview artifact as self-contained. The current artifact must be fully authorable from:
 
@@ -350,8 +352,8 @@ Allowed values:
 
 Before calling `sync_ai_ide_markdown`, verify all of the following:
 
-- The file is under `vibereview/`.
-- You did not read sibling markdown files in `vibereview/`.
+- The file is under `.vibreview/scans/`.
+- You did not read sibling markdown files in `.vibreview/scans/`.
 - `chat_session_id` exists in frontmatter.
 - `summary` exists in frontmatter.
 - `event_name` or `title` exists in frontmatter.
@@ -372,7 +374,8 @@ Before calling `sync_ai_ide_markdown`, verify all of the following:
 
 After validation:
 
-1. Save the markdown artifact under `vibereview/`.
-2. Call `sync_ai_ide_markdown` directly with that file's contents or path, depending on the tool interface exposed by the host.
-3. If sync succeeds, report success briefly.
-4. If sync fails, report failure clearly and leave the markdown artifact intact for retry.
+1. Save the markdown artifact under `.vibreview/scans/`.
+2. Call `sync_ai_ide_markdown` directly with the raw markdown string in the `markdown` argument.
+3. Do not pass JSON, a JSON string, a summary object, extracted event data, or metadata-only content as `markdown`.
+4. If sync succeeds, report success briefly.
+5. If sync fails, report failure clearly and leave the markdown artifact intact for retry.