@sjawhar/pi-legion 10.16.0 → 10.16.1

package/dist/legion.js

@@ -16913,7 +16913,7 @@ async function bootLegionClaim(host2) {
 // package.json
 var package_default = {
   name: "@sjawhar/pi-legion",
-  version: "10.16.0",
+  version: "10.16.1",
   license: "Apache-2.0",
   type: "module",
   omp: {

package/dist/skills/thermonuclear-code-quality/SKILL.md

@@ -1,192 +1,103 @@
 ---
 name: thermonuclear-code-quality
-description: Run a strict maintainability review for abstraction quality, oversized files, and ad-hoc branching growth. Use for a thermonuclear code-quality review or a deep maintainability audit.
+description: Use when asked for a thermonuclear code-quality review or a deep maintainability audit of a branch or PR diff. Also use when asked to review abstraction quality, oversized files or ad-hoc branching growth.
 disable-model-invocation: true
 ---
 
 # Thermonuclear Code Quality
 
-Use this skill for an unusually strict review focused on implementation quality, maintainability, abstraction quality, and codebase health.
-
-Look for structural simplifications that preserve behavior while making the implementation smaller, more direct, and easier to maintain. Do not stop at local cleanup when a coherent simplification is available.
-
-## Core Prompt
-
-Start from this baseline:
-
-> Perform a deep code quality audit of the current branch's changes.
-> Rethink how to structure / implement the changes to meaningfully improve code quality without impacting behavior.
-> Work to improve abstractions, modularity, reduce Spaghetti code, improve succinctness and legibility.
-> Restructure when there is a clear path to a simpler implementation.
-> Be thorough and rigorous. Verify claims before reporting them.
-
-## Non-Negotiable Additional Standards
-
-Apply the baseline prompt above, plus these explicit review rules:
-
-0. **Be ambitious about structural simplification.**
-   - Do not stop at "this could be a bit cleaner."
-   - Look for opportunities to reframe the change so that whole branches, helpers, modes, conditionals, or layers disappear entirely.
-   - Prefer the solution that makes the code feel inevitable in hindsight.
-   - Assume there is often a "code judo" move available: a re-organization that uses the existing architecture more effectively and makes the change dramatically simpler and more elegant.
-   - If you see a path to delete complexity rather than rearrange it, push hard for that path.
-
-1. **Do not let a PR push a file from under 1k lines to over 1k lines without a very strong reason.**
-   - Treat this as a strong code-quality smell by default.
-   - Prefer extracting helpers, subcomponents, modules, or local abstractions instead of letting a file sprawl past 1000 lines.
-   - If the diff crosses that threshold, explicitly ask whether the code should be decomposed first.
-   - Depart from this only if there is a compelling structural reason and the resulting file remains well organized.
-
-2. **Do not allow random spaghetti growth in existing code.**
-   - Be highly suspicious of new ad-hoc conditionals, scattered special cases, or one-off branches inserted into unrelated flows.
-   - If a change adds "weird if statements in random places", treat that as a design problem, not a stylistic nit.
-   - Prefer pushing the logic into a dedicated abstraction, helper, state machine, policy object, or separate module instead of tangling an existing path.
-   - Call out changes that make the surrounding code harder to reason about, even if they technically work.
-
-3. **Bias toward cleaning the design, not just accepting working code.**
-   - If behavior can stay the same while the structure becomes meaningfully cleaner, push for the cleaner version.
-   - Do not rubber-stamp "it works" implementations that leave the codebase messier.
-   - Strongly prefer simplifications that remove moving pieces altogether over refactors that merely spread the same complexity around.
-
-4. **Prefer direct, boring, maintainable code over hacky or magical code.**
-   - Treat brittle, ad-hoc, or "magic" behavior as a code-quality problem.
-   - Be skeptical of generic mechanisms that hide simple data-shape assumptions.
-   - Flag thin abstractions, identity wrappers, or pass-through helpers that add indirection without buying clarity.
-
-5. **Push hard on type and boundary cleanliness when they affect maintainability.**
-   - Question unnecessary optionality, `unknown`, `any`, or cast-heavy code when a clearer type boundary could exist.
-   - Prefer explicit typed models or shared contracts over loosely-shaped ad-hoc objects.
-   - If a branch relies on silent fallback to paper over an unclear invariant, ask whether the boundary should be made explicit instead.
-
-6. **Keep logic in the canonical layer and reuse existing helpers.**
-   - Call out feature logic leaking into shared paths or implementation details leaking through APIs.
-   - Prefer existing canonical utilities/helpers over bespoke one-offs.
-   - Push code toward the right package, service, or module instead of normalizing architectural drift.
-
-7. **Treat unnecessary sequential orchestration and non-atomic updates as design smells when the cleaner structure is obvious.**
-   - If independent work is serialized for no good reason, ask whether the flow should run in parallel instead.
-   - If related updates can leave state half-applied, push for a more atomic structure.
-   - Do not over-index on micro-optimizations, but do flag avoidable orchestration complexity that makes the implementation more brittle.
-
-## Primary Review Questions
-
-For every meaningful change, ask:
-
-- Is there a "code judo" move that would make this dramatically simpler?
-- Can this change be reframed so fewer concepts, branches, or helper layers are needed?
-- Does this improve or worsen the local architecture?
-- Did the diff add branching complexity where a better abstraction should exist?
-- Did a previously cohesive module become more coupled, more stateful, or harder to scan?
-- Is this logic living in the right file and layer?
-- Did this change enlarge a file or component past a healthy size boundary?
-- Are there repeated conditionals that signal a missing model or missing helper?
-- Is the implementation direct and legible, or does it rely on special cases and incidental control flow?
-- Is this abstraction actually earning its keep, or is it just a wrapper?
-- Did the diff introduce casts, optionality, or ad-hoc object shapes that obscure the real invariant?
-- Is this logic living in the canonical layer, or did the diff leak details across a boundary?
-- Is this orchestration more sequential or less atomic than it needs to be?
-
-## What to Flag Aggressively
-
-Escalate findings when you see:
-
-- A complicated implementation where a cleaner reframing could delete whole categories of complexity.
-- Refactors that move code around but fail to reduce the number of concepts a reader must hold in their head.
-- A file crossing 1000 lines due to the PR, especially if the new code could be split out.
-- New conditionals bolted onto unrelated code paths.
-- One-off booleans, nullable modes, or flags that complicate existing control flow.
-- Feature-specific logic leaking into general-purpose modules.
-- Generic "magic" handling that hides simple structure and makes the code harder to reason about.
-- Thin wrappers or identity abstractions that add indirection without simplifying anything.
-- Unnecessary casts, `any`, `unknown`, or optional params that muddy the real contract.
-- Copy-pasted logic instead of extracted helpers.
-- Narrow edge-case handling implemented in the middle of an already busy function.
-- Refactors that technically pass tests but make the code less modular or less readable.
-- "Temporary" branching that is likely to become permanent debt.
-- Bespoke helpers where the codebase already has a canonical utility for the job.
-- Logic added in the wrong layer/package when it should live somewhere more central.
-   - Sequential async flow where independent work could use simpler parallel execution.
-- Partial-update logic that leaves state less atomic than necessary.
-
-## Preferred Remedies
-
-When you identify a code-quality problem, prefer suggestions like:
-
-- Delete a whole layer of indirection rather than polishing it.
-- Reframe the state model so conditionals disappear instead of getting centralized.
-- Change the ownership boundary so the feature becomes a natural extension of an existing abstraction.
-- Turn special-case logic into a simpler default flow with fewer exceptions.
-- Extract a helper or pure function.
-- Split a large file into smaller focused modules.
-- Move feature-specific logic behind a dedicated abstraction.
-- Replace condition chains with a typed model or explicit dispatcher.
-- Separate orchestration from business logic.
-- Collapse duplicate branches into a single clearer flow.
-- Delete wrappers that do not meaningfully clarify the API.
-- Reuse the existing canonical helper instead of introducing a near-duplicate.
-- Make type boundaries more explicit so the control flow gets simpler.
-- Move the logic to the package/module/layer that already owns the concept.
-- Parallelize independent work when that also simplifies the orchestration.
-- Restructure related updates into a more atomic flow when partial state would be harder to reason about.
-
-Do not be satisfied with "maybe rename this" feedback when the real issue is structural.
-Do not be satisfied with a merely cleaner version of the same messy idea if there is a plausible path to a much simpler idea.
-
-## Review Tone
-
-Be direct, serious, and demanding about quality.
-Do not be rude, but do not soften major maintainability issues into mild suggestions.
-If the code makes the codebase messier, say so.
-If the implementation missed a substantial simplification, state it.
-
-Good phrases:
-
-- `this pushes the file past 1k lines. can we decompose this first?`
-- `this adds another special-case branch into an already busy flow. can we move this behind its own abstraction?`
-- `this works, but it makes the surrounding code more spaghetti. let's keep the behavior and restructure the implementation.`
-- `this feels like feature logic leaking into a shared path. can we isolate it?`
-- `this abstraction seems unnecessary. can we just keep the direct flow?`
-- `why does this need a cast / optional here? can we make the boundary more explicit instead?`
-- `this looks like a bespoke helper for something we already have elsewhere. can we reuse the canonical one?`
-- `i think there's a code-judo move here that makes this much simpler. can we reframe this so these branches disappear?`
-- `this refactor moves complexity around, but doesn't really delete it. is there a way to make the model itself simpler?`
-
-## Output Expectations
-
-Prioritize findings in this order:
-
-1. Structural code-quality regressions
-2. Missed opportunities for dramatic simplification / code-judo restructuring
-3. Spaghetti / branching complexity increases
-4. Boundary / abstraction / type-contract problems that make the code harder to reason about
-5. File-size and decomposition concerns
-6. Modularity and abstraction issues
-7. Legibility and maintainability concerns
-
-Do not flood the review with low-value nits if there are larger structural issues.
-Prefer a smaller number of high-conviction comments over a long list of cosmetic notes.
-
-## Approval Bar
-
-Do not approve merely because behavior seems correct.
-The bar for approval is:
-
-- no clear structural regression
-- no obvious missed opportunity to make the implementation dramatically simpler when such a path is visible
-- no unjustified file-size explosion
-- no obvious spaghetti-growth from special-case branching
-- no hacky or magical abstraction that makes the code harder to reason about
-- no unnecessary wrapper/cast/optionality churn obscuring the real design
-- no clear architecture-boundary leak or avoidable canonical-helper duplication
-- no missed opportunity for an obvious decomposition that would materially improve maintainability
-
-Treat these as presumptive blockers unless the author can justify them with evidence:
-
-- the PR preserves a lot of incidental complexity when there is a plausible code-judo move that would delete it
-- the PR pushes a file from below 1000 lines to above 1000 lines
-- the PR adds ad-hoc branching that makes an existing flow more tangled
-- the PR solves a local problem by scattering feature checks across shared code
-- the PR adds an unnecessary abstraction, wrapper, or cast-heavy contract that makes the design more indirect
-- the PR duplicates an existing helper or puts logic in the wrong layer when there is a clear canonical home
-
-If those conditions are not met, leave explicit, actionable feedback and push for a cleaner decomposition.
+A strict maintainability audit of the current branch's changes.
+
+## Baseline
+
+- Rethink how to structure and implement the changes so code quality improves and behavior does not change. The aim is code that is smaller, more direct and easier to maintain.
+- Improve abstractions and modularity. Reduce spaghetti code. Make the code succinct and legible.
+- Restructure when there is a clear path to a simpler implementation. Do not stop at local cleanup when a coherent simplification is available.
+- Be thorough and rigorous. Verify each claim before you report it.
+
+## Look for the code-judo move first
+
+- For each meaningful change, ask: can a reorganization that uses the existing architecture better make whole branches, helpers, modes, conditionals or layers disappear?
+- Push hard to delete complexity, not to rearrange it. Prefer the solution that looks inevitable in hindsight.
+- A refactor that moves code but leaves the reader the same number of concepts to hold is not a simplification. Ask whether the model itself can be simpler.
+- Do not accept a cleaner version of the same messy idea when a much simpler idea is plausible. Do not give "maybe rename this" feedback when the real issue is structural.
+- "It works" and "tests pass" are not the bar. If the structure can become meaningfully cleaner with the same behavior, push for the cleaner version.
+
+## What to flag, and the remedy to propose
+
+Flag these aggressively, and any change that makes the surrounding code harder to reason about, even when the code works:
+
+| Smell | Remedy |
+|---|---|
+| The PR pushes a file from under 1000 lines to over 1000 | Ask whether to decompose first into helpers, subcomponents, modules or local abstractions. Accept only for a compelling structural reason, with the file still well organized. |
+| Ad-hoc conditionals, special cases, one-off booleans, nullable modes or flags in unrelated or busy flows. Narrow edge cases in the middle of a busy function. "Temporary" branches. | A design problem, not a nit. Reframe the state model so the conditionals disappear, not only move to one place. Make the special case part of a simpler default flow. Else move it behind its own abstraction, helper, state machine, policy object or module. |
+| Repeated conditionals or condition chains | A typed model or an explicit dispatcher. |
+| Copy-pasted logic or duplicate branches | Extract a helper or pure function. Collapse into one flow. |
+| Hacky, brittle or "magic" behavior. Generic mechanisms that hide simple data-shape assumptions. | Direct, boring code. |
+| Thin wrappers, identity abstractions, pass-through helpers | Delete the layer. |
+| Unnecessary optionality, `unknown`, `any`, casts, loose ad-hoc objects. A silent fallback over an unclear invariant. | Explicit typed models or shared contracts, so the control flow gets simpler. |
+| Feature logic in shared paths. Implementation details leaking through APIs. Logic in the wrong file, layer or package. | Move it to the layer that owns the concept, so the feature extends an existing abstraction. |
+| A bespoke helper where a canonical utility exists | Reuse the canonical helper. |
+| A module that became more coupled, stateful or hard to scan. Orchestration mixed with business logic. | Split into focused modules. Separate orchestration from business logic. |
+| Independent work run in sequence for no good reason | Run it in parallel when that also simplifies the orchestration. |
+| Related updates that can leave state half-applied | A more atomic flow. |
+
+Flag orchestration only when the cleaner structure is obvious. Do not over-index on micro-optimizations.
+
+## Tone
+
+- Be direct, serious and demanding. Do not be rude.
+- Do not soften a major maintainability issue into a mild suggestion. If the code makes the codebase messier, or missed a substantial simplification, say so.
+- Examples:
+  - `this pushes the file past 1k lines. can we decompose this first?`
+  - `this adds another special-case branch into an already busy flow. can we move this behind its own abstraction?`
+  - `this works, but it makes the surrounding code more spaghetti. let's keep the behavior and restructure the implementation.`
+  - `why does this need a cast / optional here? can we make the boundary more explicit instead?`
+  - `i think there's a code-judo move here that makes this much simpler. can we reframe this so these branches disappear?`
+
+## Output
+
+Order findings:
+
+1. Structural regressions
+2. Missed dramatic simplifications (code judo)
+3. Spaghetti and branching growth
+4. Boundary, abstraction and type-contract problems
+5. File size and decomposition
+6. Modularity and abstraction
+7. Legibility and maintainability
+
+Give a small number of high-conviction comments. When larger structural issues exist, leave out low-value nits.
+
+## Approval bar
+
+Correct behavior alone does not earn approval. Approve only when the diff has none of these:
+
+- a clear structural regression
+- a missed, visible path to a dramatically simpler implementation
+- unjustified file-size growth
+- spaghetti growth from special-case branching
+- a hacky or magic abstraction
+- wrapper, cast or optionality churn that hides the design
+- a clear boundary leak, or avoidable duplication of a canonical helper
+- a missed obvious decomposition that would materially help maintainability
+
+These block unless the author justifies them with evidence:
+
+- incidental complexity kept when a plausible code-judo move would delete it
+- a file pushed from under 1000 lines to over 1000
+- ad-hoc branching that tangles an existing flow
+- a local problem solved by scattering feature conditionals across shared code
+- an unnecessary abstraction, wrapper or cast-heavy contract
+- a duplicated helper, or logic in the wrong layer, when a clear canonical home exists
+
+When the bar is not met, leave explicit, actionable feedback and push for a cleaner decomposition.
+
+## Verdict
+
+Make the first line of the report the verdict, in exactly this form, with the short sha of the head commit you reviewed (`git rev-parse --short=8 HEAD`):
+
+- `Verdict: APPROVE at <sha>` when the diff meets the approval bar.
+- `Verdict: CHANGES at <sha>` when it does not.
+
+A PR gate can read the verdict from the first line of a posted report, and it reads only that line. Put nothing before the verdict.

package/dist/skills/thermonuclear-deep-review/SKILL.md

@@ -1,98 +1,74 @@
 ---
 name: thermonuclear-deep-review
-description: Comprehensive security and correctness audit of a branch's changes. Use for thermonuclear or deep-review requests, or branch and PR diff audits focused on bugs, breaking changes, security issues, developer-experience regressions, and feature-gate leaks.
+description: Use when asked for a thermonuclear or deep review, or for a security and correctness audit of a branch or PR diff. Covers bugs, breaking changes, security issues, developer-experience regressions and feature-gate leaks.
 disable-model-invocation: true
 ---
 
 # Thermonuclear Deep Review
 
-Use this skill for a comprehensive security and correctness audit of a checked-out branch.
+As a security reviewer, audit the changes of the checked-out branch for bugs, regressions and security vulnerabilities. Be rigorous. Report only what the evidence supports.
 
-## Prompt
+## Scope
 
-You are a security reviewer performing a comprehensive review of a checked-out branch. Audit its changes for bugs, regressions, and security vulnerabilities. Be rigorous, careful, and evidence-led.
+Report only issues in code that the PR adds or modifies. Exception: unchanged code that consumes behavior the diff changes (check 2). A broken consumer is a defect of this diff, but the diff never shows it.
 
-# Scope
-ONLY report issues related to code that is being ADDED or MODIFIED in this PR.
-Focus on changes in the diff.
-DO NOT report vulnerabilities in existing code that is not being changed.
-EXCEPT where that unchanged code CONSUMES behavior the diff alters — see Downstream Consumer
-Guidelines. An unchanged consumer that silently breaks IS a defect in this diff, and it will
-never appear in the diff itself.
+## Checks
 
-# Guidelines
+1. **Breakage.** Trace each change through its callers and contracts, across packages and modules.
+2. **Consumers.** For each behavior the diff changes, name its consumers and show that each one still works. Behaviors: log level, status code, exception type, metric or field name, payload shape, identity or uniqueness key, timing, retry, default. Tracing callers does not find consumers, and many are outside the diff, the package or the repository:
+   - alert and monitor predicates (a monitor on `status:error` stops when a line goes down to WARNING)
+   - log-level contracts, structured-log field names, log-derived metric filters
+   - status codes and error-type strings in request logs, webhooks and audit records
+   - identity or uniqueness keys that a persistence layer arbitrates on (a new id for an existing row collides with a constraint)
+   - dashboards, SLOs, saved queries, downstream parsers
 
-## Breaking Functionality Guidelines
-This is a complex codebase with many cross-package and module dependencies. Trace possible side effects of the changes through their callers and contracts.
-
-## Downstream Consumer Guidelines
-A diff cannot show you what depends on the behavior it changes, and "trace the callers" does not
-cover it: nothing *calls* a log line, but a monitor predicate consumes it. For EVERY behavior the
-diff alters — a log level, a status code, an exception type, a metric or field name, a payload
-shape, an identity or uniqueness key, a timing/retry characteristic, a default — name its
-downstream consumers and show each one still works. Consumers routinely live outside the diff,
-outside the package, and outside the repository:
-- alert/monitor predicates (a monitor keyed on `status:error` silently stops firing when a line is
-  downgraded to WARNING; the monitor appears nowhere in the diff that disables it)
-- log-level contracts, structured-log field names, log-derived metric filters
-- status codes and error-type strings written to request logs, webhooks, or audit records
-- identity/uniqueness keys that a persistence layer arbitrates on (a fresh id for an existing
-  logical row collides against a constraint the diff never mentions)
-- dashboards, SLOs, saved queries, downstream parsers
-If you cannot locate a consumer, say so explicitly rather than assuming none exists.
-A change that removes its own alarm is the highest-severity finding of this class, because it also
-removes the signal that would have caught it.
-
-## Breaking Devex Guidelines
-It can be easy to break developers' ability to run / build the code locally. You MUST catch changes that will impact users' developer experience. Some examples (not exhaustive):
-- Modifying how secrets are read / where they are read from
-- Updating environment variable names / adding environment variables
-- Remapping ports / networking
-- Adding scripts that must be run for certain functionality to continue working. Broadly speaking these are changes that will modify the way developers currently run / build the code. This does not include changes that introduce new alternative ways to run/build things. Adding dependencies with package managers does not count as a devex breaking change, unless it requires the user to do some very new thing that is not part of their normal development workflow, like manually installing software off of a website / App Store.
-
-## Feature Leak Guidelines
-The codebase might gate features behind feature flags or internal-only checks. Do not allow a gated feature to leak. These leaks can be subtle, so trace the relevant gate and its callers.
-
-## Intended Breakage Guidelines
-If a high-risk effect is an intentional, well-constrained change, do not report it as a defect. Report it when the scope or consequences appear unclear, including when a safeguard or feature gate is removed.
-
-## Claims in the PR body
-
-A safety or correctness claim written in a PR body is a claim like any other, and the only reader who catches a wrong one is the reader told to ATTACK it. Verifying reviewers read the code against the claim and pass; that is what they are for. Attack the body's claims, not only its diff.
-
-Two shapes to attack first:
-
-- **Neutralization ORDER, not coverage.** Any pipeline that sanitizes and then edits can create what it sanitized. The test is not "did it neutralize everything" but "can any later pass CREATE what was being neutralized".
-- **A severity resting on a third party's formatting is a dependency, not a mitigation.** Rate it as the bet it is, and fix rather than disclose.
+   If you cannot find a consumer, say so. Never assume that none exists. A change that removes its own alarm is the highest severity here, because it also removes the signal that would catch it.
+3. **Developer experience.** Find changes to how developers run or build the code locally. Examples: where or how the code reads secrets, new or renamed environment variables, remapped ports or networking. A new script that must run for a feature to keep working is also a change. Not a break: a new alternative way to run or build, or a new package-manager dependency. Exception: a dependency that needs a step outside the usual workflow, such as a manual install from a website or app store, is a break.
+4. **Feature leaks.** Trace each feature flag or internal-only check and its callers. Do not let a gated feature leak.
+5. **Intended breakage.** An intended, well-constrained high-risk effect is not a defect. Report it when its scope or consequences are unclear, or when it removes a safeguard or feature gate.
+6. **PR body claims.** Attack each safety or correctness claim in the PR body, not only the diff. Only a reviewer told to attack a claim finds a wrong one. Attack these first:
+   - Order, not coverage: after a pipeline sanitizes, can any later pass create or recreate what the sanitizer neutralized?
+   - A severity that relies on a third party's formatting is a dependency, not a mitigation. Rate it as that bet, and fix it, do not only disclose it.
 
 ## Security Guidelines
 
-For each row whose surface the diff touches, answer with a file:line citation. End your report with one `Security:` line: each touched row's tag and its answer with file:line, or `Security: no sensitive surface in this diff.` when the diff touches none.
+For each row whose surface the diff touches, answer with a file:line citation.
 
 | Tag | If the diff touches… | Answer, with file:line |
 | --- | --- | --- |
 | `authz` | an authorization or refusal check, or a new route, command, or tool | who may call it, who may not, where the diff enforces that, and what the unauthorized caller gets |
 | `secret` | a token, grant, secret file, credential helper, or its lifetime | what widened: who can read it, for how long, in which process |
-| `untrusted-input` | a subprocess, argv, path, template, or query built from text an outside party controls (an issue body, a PR comment, a webhook payload, model output) | the boundary that neutralizes it, and whether any later pass can re-create what was neutralized (order, not coverage) |
+| `untrusted-input` | a subprocess, argv, path, template, or query built from text an outside party controls (an issue body, a PR comment, a webhook payload, model output) | the boundary that neutralizes it, and whether any later pass can re-create what it neutralized (order, not coverage) |
 | `prompt` | a prompt that embeds untrusted text into an agent's instructions | what delimits the untrusted region, and what the agent may do if it obeys that text (OWASP LLM01 prompt injection, LLM06 excessive agency) |
 | `supply-chain` | a dependency, lockfile, base image, or GitHub Action | the version, the pin (a digest or a SHA checked against its tag), and the permissions the workflow runs with |
 | `sandbox` | a sandbox or pod manifest, a capability, or a network policy | which isolation property changed, and against whom |
 | `agent-def` | an agent definition, skill, role prompt, `.omp/` config, or `AGENTS.md` | whether this diff can steer its own reviewers, and why this edit is trustworthy anyway |
-| `transport` | TLS/certificate verification, a signature, HMAC, or randomness source, or an unbounded read/write sized by untrusted input | what changed, the check or bound it relies on, and the ASVS V11/V12 identifier it maps to |
+| `transport` | TLS or certificate verification, a signature, an HMAC, a randomness source, or a read or write that untrusted input sizes with no bound | what changed, the check or bound it relies on, and the ASVS V11 or V12 identifier it maps to |
+
+- Cite an OWASP ASVS v5.0.0 identifier where one applies (`v5.0.0-1.2.5` style).
+- A security finding with no stated exploit path is not a finding. Call it hardening and rank it Minor. A security finding that states an exploit path is always its own finding at its real priority. Never put it in the hardening items.
+- Report at most two hardening items, ranked. Put the rest in one hardening paragraph.
+- Start each security finding with its row's tag, `Security[<tag>]:`, so readers can count findings by row.
+- End the report with one `Security:` line: each touched row's tag and its answer with file:line, or `Security: no sensitive surface in this diff.` when the diff touches none.
+
+## Findings
+
+- Never misreport priority. Developers who get false High findings stop listening. Trace each issue end to end.
+- Never report a finding with research still open. If you can read the code that settles it, read it. Not: "the client has issue X, but if the backend handles it, this is ok."
+
+## Verdict
+
+Make the first line of the report the verdict, in exactly this form, with the short sha of the head commit you reviewed (`git rev-parse --short=8 HEAD`):
 
-Cite an OWASP ASVS v5.0.0 identifier where one applies (`v5.0.0-1.2.5` style). A security finding with no stated exploit path is not a finding: call it hardening and rank it Minor. A security finding that states an exploit path is always its own finding at its real priority, never folded into hardening. Report at most two hardening items, ranked, and fold the rest into one hardening paragraph. Start each security finding with its row's tag, `Security[<tag>]:`, so it can be told from the others and counted by row.
+- `Verdict: CHANGES at <sha>` when the report has a finding that the author must fix before merge.
+- `Verdict: APPROVE at <sha>` when it has none. Hardening items alone do not block.
 
-## Over-reporting Guidelines
-If you report issues as High priority when they are not in fact high priority / meaningful issues, devs will lose trust in you and stop listening to you over time.
-Never misreport priority or importance. Trace issues end to end and report only what the evidence supports.
+A PR gate can read the verdict from the first line of a posted report, and it reads only that line. Put nothing before the verdict.
 
-# Final Response
-IF you have medium-to-high priority / risk findings, and there is a PR for this branch, then check the PR/MR discussion using gh/glab cli to see if there are comments from BugBot or others present.
-If so, take their findings into account. If they found issues you missed, evaluate them to determine if they are valid and include them in your report. If they found some of the same issues you did, see if there is anything from their findings that are worth incorporating into your response.
-Flag issues found by BugBot or others in the PR/MR discussion that you include in your report.
+## PR discussion
 
+Only after your independent audit, and only when you have Medium-to-High findings and the branch has a PR:
 
-# Critical Rules
-- NEVER present issues with unfinished research. E.g. Never say something like, "The client has issue X, but if handled in the backend then this is ok." if you have access to the backend code and can check for yourself.
-- Wait to check PR discussion until after the independent audit so fresh evidence drives the review.
-- Be rigorous, careful, and specific about what the evidence supports.
+1. Read the PR/MR discussion with `gh` or `glab` for comments from BugBot or others.
+2. Check their findings. Include the valid ones you missed, and add what is useful from the ones you share.
+3. Mark each finding that came from that discussion.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sjawhar/pi-legion",
-  "version": "10.16.0",
+  "version": "10.16.1",
   "license": "Apache-2.0",
   "type": "module",
   "omp": {