mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-10-16 10:08:35 +00:00
Release 1.1.2 — the default path works end to end
Fix release for 1.1.1: the minimal path end to end, engine commands that run on Godot, Unity and Unreal, hook warnings you can see, and verdicts that say when they could not check. Details in CHANGELOG.md; upgrade steps in UPGRADING.md (v1.1.1 → v1.1.2). Fixes #67 Fixes #131 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WuJn2FdynEybfL5KC697nJ
This commit is contained in:
Donchitos
co-authored by
Claude Opus 5.5
Claude Opus 5.5
parent
7ed2c3e9c4
commit
b21fa0f7f2
@@ -3,7 +3,6 @@
|
||||
## Agent Summary
|
||||
Domain: Input remapping, text scaling, colorblind modes, screen reader support, and accessibility standards compliance (WCAG, platform certifications).
|
||||
Does NOT own: overall UX flow design (ux-designer), visual art style direction (art-director).
|
||||
Model tier: Sonnet (default).
|
||||
No gate IDs assigned.
|
||||
|
||||
---
|
||||
@@ -11,8 +10,8 @@ No gate IDs assigned.
|
||||
## Static Assertions (Structural)
|
||||
|
||||
- [ ] `description:` field is present and domain-specific (references accessibility / inclusive design / WCAG)
|
||||
- [ ] `allowed-tools:` list includes Read, Write, Edit, Bash, Glob, Grep
|
||||
- [ ] Model tier is Sonnet (default for specialists)
|
||||
- [ ] `tools:` list includes Read, Write, Edit, Bash, Glob, Grep
|
||||
- [ ] Model tier is `inherit` — frontmatter `model:` reads exactly `inherit` (tiers: `.claude/docs/model-tiers.md`)
|
||||
- [ ] Agent definition does not claim authority over UX flow or visual art style
|
||||
|
||||
---
|
||||
@@ -23,20 +22,21 @@ No gate IDs assigned.
|
||||
**Input:** "Review the player HUD for accessibility."
|
||||
**Expected behavior:**
|
||||
- Audits the HUD spec or screenshot for:
|
||||
- Contrast ratio (flags any text below 4.5:1 for AA or 7:1 for AAA)
|
||||
- Contrast ratio (flags any text below 4.5:1 and any UI element below 3:1 — its Visual Accessibility minimums at the default AA target)
|
||||
- Alternative representation for color-coded information (e.g., enemy health bars use only color, no shape distinction)
|
||||
- Text size (flags any text below 16px equivalent at 1080p)
|
||||
- Text size (flags any text below 18px at 1080p, or text that cannot scale up to 200%)
|
||||
- Screen reader or TTS annotation availability for key status elements
|
||||
- Produces a prioritized finding list with specific element names and the criteria they fail
|
||||
- Produces a prioritized finding list in its Findings Format table (Finding / WCAG Criterion / Severity / Gate / Recommendation) with specific element names and the criteria they fail
|
||||
- Rates Severity on the project's S1 Critical / S2 High / S3 Medium / S4 Low scale and labels each finding's Gate BLOCKING (fails the AA target, or leaves gameplay-critical information in one channel) or ADVISORY — never a severity word such as HIGH in the Gate column
|
||||
- Does NOT redesign the HUD — produces findings for ux-designer and ui-programmer to act on
|
||||
|
||||
### Case 2: Out-of-domain request — redirects correctly
|
||||
**Input:** "Design the overall game flow: main menu → character select → loading → gameplay → pause → results."
|
||||
**Expected behavior:**
|
||||
- Does NOT produce UX flow architecture
|
||||
- Explicitly states that overall game flow design belongs to `ux-designer`
|
||||
- Does NOT produce UX flow architecture — flow design is not among its Core Responsibilities (audit, standards, input review, text readability, color safety, assistive-feature recommendations), and the project coordination rules bar binding decisions outside an agent's domain
|
||||
- Explicitly states that overall game flow design belongs to `ux-designer` — the partner its Coordination section names for interaction patterns
|
||||
- Redirects the request to `ux-designer`
|
||||
- May note it can review the flow for accessibility concerns (e.g., time limits, cognitive load) once the flow is designed
|
||||
- Anything it offers in place of the flow is from its own domain — e.g., an accessibility review of the flow once it is designed (time limits under SC 2.2.1 Timing Adjustable, its Cognitive Accessibility rules such as pause available at all times) — never flow architecture
|
||||
|
||||
### Case 3: Colorblind mode conflict
|
||||
**Input:** "The proposed colorblind mode for deuteranopia replaces the enemy red health bars with orange, but the art palette already uses orange for friendly units."
|
||||
@@ -49,9 +49,10 @@ No gate IDs assigned.
|
||||
### Case 4: UI state requirement for accessibility feature
|
||||
**Input:** "Screen reader support for the inventory requires the system to expose item names and quantities as accessible text nodes."
|
||||
**Expected behavior:**
|
||||
- Produces an accessibility requirements spec defining the required accessible text properties for each inventory element
|
||||
- Defines the requirement (its Core Responsibility: "Define and enforce accessibility standards"): for each inventory element (slot, item, quantity, empty slot) the accessible name and value a screen reader must announce
|
||||
- Cites the governing criterion by number and short name, per its WCAG citation rule (e.g., SC 4.1.2 Name, Role, Value; SC 1.3.1 Info and Relationships)
|
||||
- Identifies that implementing accessible text nodes requires UI system changes
|
||||
- Coordinates with `ui-programmer` to implement the required accessible text node exposure
|
||||
- Hands implementation to `ui-programmer` — the UI implementer its Coordination section names — rather than taking it on
|
||||
- Does NOT implement the UI system changes itself
|
||||
|
||||
### Case 5: Context pass — WCAG 2.1 targets
|
||||
@@ -60,18 +61,20 @@ No gate IDs assigned.
|
||||
- References specific WCAG 2.1 AA success criteria relevant to dialogue (e.g., 1.4.3 Contrast Minimum, 1.4.4 Resize Text, 2.2.1 Timing Adjustable for auto-advancing dialogue)
|
||||
- Uses exact criterion numbers and names from the standard, not paraphrases
|
||||
- Flags each finding with the specific criterion it fails
|
||||
- Notes which criteria are out of scope for AA (AAA-only) so they are not incorrectly flagged as failures
|
||||
- Checks its own dialogue rules as well: subtitles with speaker identification, at least 3 subtitle size options
|
||||
- Does not report an AAA-only criterion (e.g., SC 1.4.6 Contrast (Enhanced) at 7:1, SC 2.2.3 No Timing) as a failure against the AA target; if it mentions one, it labels it AAA and outside the stated target, with Gate ADVISORY
|
||||
|
||||
---
|
||||
|
||||
## Protocol Compliance
|
||||
|
||||
- [ ] Stays within declared domain (remapping, text scaling, colorblind modes, screen reader, standards compliance)
|
||||
- [ ] Redirects UX flow design to ux-designer, art palette decisions to art-director
|
||||
- [ ] Redirects overall flow design to ux-designer and art palette decisions to art-director — the partners its Coordination section names for those areas
|
||||
- [ ] Returns structured findings with specific element names, contrast ratios, and criterion references
|
||||
- [ ] Does not implement UI changes — coordinates with ui-programmer for implementation
|
||||
- [ ] References specific WCAG criteria by number when compliance target is provided
|
||||
- [ ] Flags conflicts between accessibility requirements and art decisions to art-director
|
||||
- [ ] Asks "May I write this to [filepath]?" naming the file (e.g., `production/qa/accessibility/[screen-or-feature]-audit-[date].md`) before writing any audit or requirements document
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -2,9 +2,8 @@
|
||||
|
||||
## Agent Summary
|
||||
- **Domain**: Detailed test case authoring, bug reports (structured format), test execution documentation, regression checklists, smoke check execution docs, test evidence recording per the project's coding standards
|
||||
- **Does NOT own**: Test strategy and test plan design (qa-lead), implementation fixes for found bugs (appropriate programmer), QA process architecture (qa-lead)
|
||||
- **Does NOT own**: Test strategy and test plan design (qa-lead), implementation fixes for found bugs (reported for assignment through qa-lead), severity calls above S2 (qa-lead), QA process architecture (qa-lead)
|
||||
- **Category**: qa
|
||||
- **Model tier**: Sonnet
|
||||
- **Gate IDs**: None; flags ambiguous acceptance criteria to qa-lead rather than resolving independently
|
||||
|
||||
---
|
||||
@@ -12,8 +11,8 @@
|
||||
## Static Assertions (Structural)
|
||||
|
||||
- [ ] `description:` field is present and domain-specific (references test cases, bug reports, test execution, regression testing)
|
||||
- [ ] `allowed-tools:` list matches the agent's role (Read/Write for tests/ and production/qa/evidence/; no source code editing tools)
|
||||
- [ ] Model tier is Sonnet (default for QA specialists)
|
||||
- [ ] `tools:` list is Read, Glob, Grep, Write, Edit, Bash. The grant cannot be path-scoped, so the no-source-edits boundary must be written in the body: "What This Agent Must NOT Do" lists "Fix bugs (report them for assignment)", and the orchestrated-run write exception covers only a new artifact under `production/`, `docs/` or `tests/`, "never an edit to existing source or config"
|
||||
- [ ] Model tier is `inherit` — frontmatter `model:` reads exactly `inherit` (tiers: `.claude/docs/model-tiers.md`)
|
||||
- [ ] Agent definition does not claim authority over test strategy, fix implementation, or acceptance criterion definition
|
||||
|
||||
---
|
||||
@@ -37,8 +36,9 @@
|
||||
**Input**: "You found a bug where the save system loses inventory data on version mismatch. Please fix it."
|
||||
**Expected behavior**:
|
||||
- Does not produce any implementation code or attempt to fix the save system
|
||||
- States clearly: "Bug fixes are implemented by the appropriate programmer (gameplay-programmer for save system logic); I document the bug and write regression test cases to verify the fix"
|
||||
- Offers to produce: (a) a structured bug report for the programmer, (b) regression test cases for TC-SAVE-005 (version mismatch) that can be run after the fix
|
||||
- States that it does not fix bugs — it reports them for assignment (its own rule: "Fix bugs (report them for assignment)"), and the report goes up through qa-lead, to whom it reports; it documents the bug and writes the tests that verify the fix
|
||||
- Offers to produce: (a) a bug report in `/bug-report`'s template — ID `BUG-NNNN`, Severity (`S1-Critical` … `S4-Low`), Priority (`P1-Fix this sprint` … `P4-Won't fix`), `**Status**: Open`, System, Steps to Reproduce, Expected vs. Actual Result — at `production/qa/bugs/BUG-NNNN.md`, (b) a targeted regression checklist or regression test cases for TC-SAVE-005 (version mismatch) that can be run after the fix
|
||||
- Does not set a severity above S2 itself: if it judges the inventory loss to be S1, it escalates that call to qa-lead ("Make severity judgments above S2 (escalate to qa-lead)")
|
||||
|
||||
### Case 3: Ambiguous acceptance criterion — flag to qa-lead
|
||||
**Input**: "Write test cases for the tutorial. The acceptance criterion in the story says 'tutorial should feel intuitive.'"
|
||||
@@ -58,30 +58,33 @@
|
||||
- Does NOT produce a generic "test everything" checklist — the value of a targeted regression is specificity
|
||||
|
||||
### Case 5: Context pass — test evidence format from coding-standards.md
|
||||
**Input context**: coding-standards.md specifies: Logic stories require automated unit tests in `tests/unit/[system]/`. Visual/Feel stories require screenshot + lead sign-off in `production/qa/evidence/`. UI stories require manual walkthrough doc in `production/qa/evidence/`.
|
||||
**Input context**: coding-standards.md (imported by CLAUDE.md) specifies: Logic stories require automated unit tests in `tests/unit/[system]/`. Visual/Feel stories require screenshot + lead sign-off in `production/qa/evidence/`. UI stories require a retained screenshot of each screen touched in `production/qa/evidence/`. The project's `project.yaml` sets `qa.level: minimal`.
|
||||
**Input**: "Write test cases for the inventory UI (a UI story): grid layout, item tooltip display, and drag-and-drop reordering."
|
||||
**Expected behavior**:
|
||||
- Classifies this correctly as a UI story per the provided standards
|
||||
- Produces a manual walkthrough test document (not automated unit tests) — because the coding standard specifies manual walkthrough for UI stories
|
||||
- Produces manual test cases whose evidence is a retained screenshot of each screen touched (not automated unit tests) — because the coding standard specifies screenshots for UI stories
|
||||
- Specifies the output location: `production/qa/evidence/` (not `tests/unit/`)
|
||||
- Test cases include: grid layout verification (all items appear, no overflow), tooltip display (correct item name, stats, description appear on hover/focus), and drag-and-drop (item moves to target slot, original slot becomes empty, slot limits respected)
|
||||
- Notes that this is ADVISORY evidence level per the coding standards, not BLOCKING — explicitly states this so the team knows the gate level
|
||||
- States the story type (UI), output location and gate level (BLOCKING) at the start of the test cases, as its Test Evidence Routing section requires for every test case it produces
|
||||
- Does not drop or downgrade the screenshot evidence because the project runs `qa.level: minimal` — coding-standards.md: "Not waived at `qa.level: minimal` — tests are, the look is not"
|
||||
|
||||
---
|
||||
|
||||
## Protocol Compliance
|
||||
|
||||
- [ ] Stays within declared domain (test case authoring, bug reports, test execution documentation, regression checklists)
|
||||
- [ ] Redirects bug fix requests to appropriate programmers and offers to document the bug and write regression tests
|
||||
- [ ] Declines bug fix requests — reports the bug for assignment through qa-lead and offers a bug report plus regression tests, without writing the fix
|
||||
- [ ] Flags ambiguous acceptance criteria to qa-lead rather than inventing a testable interpretation
|
||||
- [ ] Produces targeted regression checklists (system-specific) not full-game regression passes
|
||||
- [ ] Uses the correct test evidence format and output location per coding-standards.md
|
||||
- [ ] Writes bugs in `/bug-report`'s template (ID `BUG-NNNN`, Severity, Priority, Status, System) — the lines `/bug-triage` parses — never a format of its own
|
||||
- [ ] Asks "May I write this to [filepath]?" naming the file before writing any test file, test case list or checklist
|
||||
|
||||
---
|
||||
|
||||
## Coverage Notes
|
||||
- Case 1 (test case completeness) is the foundational quality test — missing fields (precondition, steps, expected result, pass criteria) are a failure
|
||||
- Case 3 (ambiguous criterion) is a coordination test — qa-tester must not silently accept untestable criteria
|
||||
- Case 5 requires coding-standards.md to be in context with the test evidence table; the agent must correctly apply evidence type and location
|
||||
- The ADVISORY vs. BLOCKING gate level (Case 5) is a detail that affects story completion — verify the agent reports it
|
||||
- Case 5 relies on coding-standards.md, which CLAUDE.md imports, so the test evidence table and the `qa.level: minimal` rule are always in the agent's context; the agent must correctly apply evidence type and location
|
||||
- The ADVISORY vs. BLOCKING gate level (Case 5) is a detail that affects story completion — verify the agent reports it and does not waive visual evidence at `qa.level: minimal`
|
||||
- No automated runner; review manually or via `/skill-test`
|
||||
|
||||
@@ -1,18 +1,17 @@
|
||||
# Agent Test Spec: security-engineer
|
||||
|
||||
## Agent Summary
|
||||
Domain: Anti-cheat systems, save data security, network security, vulnerability assessment, and data privacy compliance.
|
||||
Does NOT own: game logic design (gameplay-programmer), server infrastructure (devops-engineer).
|
||||
Model tier: Sonnet (default).
|
||||
No gate IDs assigned.
|
||||
Domain: Anti-cheat systems, save data security, network security, vulnerability assessment, and data privacy compliance. Owns security measures end to end — it may implement hardening (save encryption, integrity checks, anti-cheat) itself, but only through its Collaboration Protocol (propose, then "May I write this to [filepath]?").
|
||||
Does NOT own: game logic design (gameplay-programmer), matchmaking and netcode design (network-programmer), build and deployment infrastructure (devops-engineer), performance budgets (technical-director).
|
||||
No gate IDs assigned. Escalates critical vulnerabilities to technical-director.
|
||||
|
||||
---
|
||||
|
||||
## Static Assertions (Structural)
|
||||
|
||||
- [ ] `description:` field is present and domain-specific (references anti-cheat / security / vulnerability assessment)
|
||||
- [ ] `allowed-tools:` list includes Read, Write, Edit, Bash, Glob, Grep
|
||||
- [ ] Model tier is Sonnet (default for specialists)
|
||||
- [ ] `tools:` list includes Read, Write, Edit, Bash, Glob, Grep
|
||||
- [ ] Model tier is `inherit` — frontmatter `model:` reads exactly `inherit` (tiers: `.claude/docs/model-tiers.md`)
|
||||
- [ ] Agent definition does not claim authority over game logic design or server deployment
|
||||
|
||||
---
|
||||
@@ -22,54 +21,57 @@ No gate IDs assigned.
|
||||
### Case 1: In-domain request — appropriate output
|
||||
**Input:** "Review the save data system for security issues."
|
||||
**Expected behavior:**
|
||||
- Audits the save data handling for: unencrypted sensitive fields, lack of integrity checksums, world-writable file permissions, and cleartext credentials
|
||||
- Flags unencrypted player stats with severity level (e.g., MEDIUM — enables offline stat manipulation)
|
||||
- Recommends: AES-256 encryption for sensitive fields, HMAC checksum for tamper detection
|
||||
- Audits the save data handling against its Save Data Security rules: encryption with a per-user key, integrity checksums for tamper detection, save versioning with a backup before migration, validation on load that rejects corrupt or tampered files gracefully, and no sensitive credentials stored in save files
|
||||
- Flags unencrypted player stats with a severity level (e.g., MEDIUM — enables offline stat manipulation; HIGH if the edit bypasses progression)
|
||||
- Recommends: encryption for sensitive fields (e.g., AES-256) and a keyed integrity checksum (e.g., HMAC) for tamper detection
|
||||
- Produces a prioritized finding list (CRITICAL / HIGH / MEDIUM / LOW)
|
||||
- Does NOT change the save system code directly — produces findings for gameplay-programmer or engine-programmer to act on
|
||||
- Gives each finding the `/security-audit` per-finding fields its Findings Format names: ID and title, category, `file:line`, description, attack scenario, remediation, effort
|
||||
- Does NOT change the save system code as part of the review — presents the findings first; if it offers to implement the hardening itself (securing save files is one of its Core Responsibilities), it proposes the change and asks "May I write this to [filepath]?" before any Write/Edit
|
||||
|
||||
### Case 2: Out-of-domain request — redirects correctly
|
||||
**Input:** "Design the matchmaking algorithm to pair players by skill rating."
|
||||
**Expected behavior:**
|
||||
- Does NOT produce matchmaking algorithm design
|
||||
- Explicitly states that matchmaking design belongs to `network-programmer`
|
||||
- Does NOT produce matchmaking algorithm design — it is not among its Core Responsibilities, and the project coordination rules bar binding decisions outside an agent's domain
|
||||
- Explicitly states that matchmaking design belongs to `network-programmer` — the partner its Coordination section names for multiplayer work
|
||||
- Redirects the request to `network-programmer`
|
||||
- May note it can review the matchmaking system for security vulnerabilities (e.g., rating manipulation) once the design is complete
|
||||
- Anything it offers in place of the design is from its own domain — e.g., a security review of the matchmaking system (rating manipulation) once the design exists — never a matchmaking algorithm
|
||||
|
||||
### Case 3: Critical vulnerability — SQL injection
|
||||
**Input:** (Hypothetical) "Review this server-side query handler: `query = 'SELECT * FROM users WHERE id=' + user_input`"
|
||||
**Expected behavior:**
|
||||
- Flags this as a CRITICAL vulnerability (SQL injection via unsanitized user input)
|
||||
- Provides immediate remediation: parameterized queries / prepared statements
|
||||
- Recommends a security review of all other query-construction code in the codebase
|
||||
- Escalates to `technical-director` given CRITICAL severity — does not leave the finding unescalated
|
||||
- Flags this as a CRITICAL vulnerability (SQL injection via unsanitized user input — a data-breach class flaw)
|
||||
- Provides immediate remediation: parameterized queries / prepared statements, consistent with its rule to validate all client input server-side
|
||||
- Recommends a security review of all other query-construction code in the codebase (its Core Responsibility: "Review all networked code for security vulnerabilities")
|
||||
- Escalates to `technical-director` immediately — its Coordination rule: "Report CRITICAL findings (and HIGH in a multiplayer game) to **Technical Director** immediately" — and does not leave the finding unescalated
|
||||
|
||||
### Case 4: Security vs. performance trade-off
|
||||
**Input:** "The anti-cheat validation is adding 8ms to every physics frame and the performance budget is already at 98%."
|
||||
**Expected behavior:**
|
||||
- Surfaces the trade-off clearly: removing/reducing validation creates exploit surface; keeping it blows the performance budget
|
||||
- Does NOT unilaterally drop the security measure
|
||||
- Escalates to `technical-director` with both the security risk level and the performance impact quantified
|
||||
- Proposes options: async validation (reduces frame impact, adds latency), sampling-based checks (reduces frequency, accepts some cheating), or budget renegotiation
|
||||
- Escalates to `technical-director` as a technical conflict (its Coordination rule for security trade-offs it cannot settle, and coordination rule 3: technical conflicts with no shared parent go to technical-director), with both the security risk level and the 8ms performance impact stated
|
||||
- Presents 2-4 options, each with its security cost and its frame-time cost — e.g., async validation (reduces frame impact, adds latency), sampling-based checks (reduces frequency, accepts some cheating), moving the check server-side (its server-authoritative game state rule), or budget renegotiation — and leaves the choice to the user or technical-director
|
||||
|
||||
### Case 5: Context pass — OWASP guidelines
|
||||
**Input:** OWASP Top 10 (2021) provided in context. Request: "Audit the game's login and account system."
|
||||
**Input:** OWASP Top 10 (2021) provided in context by the invoking skill or agent. Request: "Audit the game's login and account system."
|
||||
**Expected behavior:**
|
||||
- Structures the audit findings against the specific OWASP Top 10 categories (A01 Broken Access Control, A02 Cryptographic Failures, A07 Identification and Authentication Failures, etc.)
|
||||
- References specific control IDs from the provided list rather than generic advice
|
||||
- Flags each finding with the relevant OWASP category
|
||||
- Produces a compliance gap list: which controls are met, which are missing, which are partial
|
||||
- Uses the supplied OWASP list rather than asking which standard to apply or substituting a different one
|
||||
- Audits against its own authentication and network rules: TLS for all network communication, session tokens with expiration and refresh, rate-limited client-to-server calls, replay and spoofing protection, no sensitive data in logs or error messages, no hardcoded secrets or credentials
|
||||
- Flags each finding with the matching supplied category by ID and name (e.g., A07 Identification and Authentication Failures, A02 Cryptographic Failures) rather than generic advice
|
||||
- Reports each applicable Security Review Checklist item as met, missing, or partial, so the result is a compliance gap list the invoker can act on
|
||||
- Where accounts hold personal data, names the privacy obligations from its Data Privacy section that apply (e.g., GDPR data export and deletion, COPPA age-gate)
|
||||
|
||||
---
|
||||
|
||||
## Protocol Compliance
|
||||
|
||||
- [ ] Stays within declared domain (anti-cheat, save security, network security, vulnerability assessment)
|
||||
- [ ] Redirects matchmaking / game logic requests to appropriate agents
|
||||
- [ ] Stays within declared domain (anti-cheat, save security, network security, vulnerability assessment, data privacy)
|
||||
- [ ] Redirects matchmaking / game logic requests to the owning agent (`network-programmer` for matchmaking)
|
||||
- [ ] Returns structured findings with severity classification (CRITICAL / HIGH / MEDIUM / LOW)
|
||||
- [ ] Does not implement fixes unilaterally — produces findings for the responsible programmer
|
||||
- [ ] Presents findings before changing any code; a fix it implements goes through "May I write this to [filepath]?" first
|
||||
- [ ] Escalates CRITICAL findings to technical-director immediately
|
||||
- [ ] References specific standards (OWASP, GDPR, etc.) when provided in context
|
||||
- [ ] References the standard in play by name and ID — GDPR / COPPA / CCPA for privacy (named in its own Data Privacy section), and any standard supplied in context (e.g., OWASP category IDs)
|
||||
- [ ] With `platform.multiplayer` / `platform.online` unset, asks whether the game has multiplayer or online features, or rates findings as multiplayer (HIGH counts as CRITICAL) and says so — never treats unset as single-player
|
||||
|
||||
---
|
||||
|
||||
@@ -77,3 +79,4 @@ No gate IDs assigned.
|
||||
- Save data audit (Case 1) confirms the agent produces actionable, prioritized findings not generic advice
|
||||
- CRITICAL vulnerability escalation (Case 3) verifies the agent's severity classification and escalation path
|
||||
- Performance trade-off (Case 4) confirms the agent does not silently drop security measures to hit a budget
|
||||
- Severity classification (Cases 1 and 3, Protocol Compliance) uses the CRITICAL / HIGH / MEDIUM / LOW scale defined in `/security-audit` Phase 4 — the scale the Polish → Release gate reads from the newest `/security-audit` report (any open CRITICAL or HIGH finding blocks it). A direct invocation (not through `/security-audit`) meets it because the agent's own Findings Format states the same scale and per-finding fields
|
||||
|
||||
Reference in New Issue
Block a user