[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M754TY9JFYYFBR8D5AADWHQ1":3,"skill-same:01M754TY9JFYYFBR8D5AADWHQ1":59},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":30,"commitSha":31,"skillDirectory":32,"forksCount":33,"repositoryHtmlUrl":34,"repositoryHomepageUrl":6,"ownerHtmlUrl":35,"ownerBlogUrl":36,"ownerDescription":37,"updatedAt":38,"install":39,"resources":52},"01M754TY9JFYYFBR8D5AADWHQ1","x-internal-verify-story",null,"Executes the story-level verification gate (Phase 3 carve-out of x-implement-story): identifies files touched by the story via the task breakdown, runs the test suite scoped to those files, parses filtered coverage against the story-specific thresholds (default line >=95, branch >=90), performs cross-file consistency checks (constructor patterns, return-type uniformity per role), optionally runs the smoke suite, and validates every Section 7 Gherkin scenario has a matching acceptance test. Emits a single-line JSON envelope {passed, coverageDelta, failures, acCheckResults}. Sixth skill in the x-internal-* convention and the third under internal\u002Fplan\u002F (after x-internal-load-story-context and x-internal-build-story-plan).","review-bench\u002Federcnj_ia-dev-environment","review-bench","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F286778065?v=4","01M7517F9NTEPDZDAXJBR30FWT","ReviewBench","01M7517FAC9F4P7TGWCNJ8VYVW",0,"MIT","https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring-fintech-pci\u002F.claude\u002Fskills\u002Fx-internal-verify-story\u002FSKILL.md",[],[],"2026-11-12 13:55:43",false,"---\nname: x-internal-verify-story\ndescription: \"Executes the story-level verification gate (Phase 3 carve-out of x-implement-story): identifies files touched by the story via the task breakdown, runs the test suite scoped to those files, parses filtered coverage against the story-specific thresholds (default line >=95, branch >=90), performs cross-file consistency checks (constructor patterns, return-type uniformity per role), optionally runs the smoke suite, and validates every Section 7 Gherkin scenario has a matching acceptance test. Emits a single-line JSON envelope {passed, coverageDelta, failures, acCheckResults}. Sixth skill in the x-internal-* convention and the third under internal\u002Fplan\u002F (after x-internal-load-story-context and x-internal-build-story-plan).\"\nvisibility: internal\nuser-invocable: false\nallowed-tools: Bash\nargument-hint: \"--story-id \u003Cstory-XXXX-YYYY> --epic-id \u003CXXXX> [--coverage-threshold-line \u003CN>] [--coverage-threshold-branch \u003CN>]\"\ncategory: internal-plan\ncontext-budget: medium\nrequires-capabilities: []\n---\n\n## Global Output Policy\n\n- **Language**: English ONLY.\n- **Tone**: Technical, Direct, and Concise.\n- **Efficiency**: Remove all conversational fillers and greetings to save tokens.\n\n> 🔒 **INTERNAL SKILL**\n> Esta skill é invocada apenas por outras skills (orquestradores).\n> NÃO é destinada a invocação direta pelo usuário.\n> Caller principal: x-implement-story (Phase 3 carve-out).\n> Sexta skill da convenção `x-internal-*` (após x-internal-update-status\n> pilot 0049-0005, x-internal-write-report 0049-0006,\n> x-internal-normalize-args 0049-0007, x-internal-load-story-context\n> 0049-0011, e x-internal-build-story-plan 0049-0012). Terceira skill\n> na subdir `internal\u002Fplan\u002F` — o subdir `plan\u002F` agrupa orquestração de\n> planejamento e verificação da story (load → build → verify). Difere\n> de `internal\u002Fops\u002F`, cujas sibling skills mutam estado (execution-state,\n> reports).\n\n# Skill: x-internal-verify-story\n\n## Purpose\n\nCarve out Phase 3 (Story-Level Verification) of `x-implement-story`\ninto a single, single-responsibility skill. The ~160 inline lines\ncurrently inside `x-implement-story` Phase 3 (Step 3.1 coverage, Step\n3.2 cross-file consistency, Step 3.8 smoke gate, implicit AC → test\nmapping) become a single\n`Skill(skill: \"x-internal-verify-story\", …)` invocation; the\norchestrator shrinks to a read-the-envelope consumer that drives its\nremediation \u002F tech-lead-review branching off the four response fields.\n\nResponsibilities (single):\n\n1. Identify the files \"owned\" by the story via the task breakdown at\n   `ai\u002Fepics\u002Fepic-XXXX\u002Fplans\u002Ftasks-story-XXXX-YYYY.md` (Section 8\n   fallback of the story file when the breakdown is absent).\n2. Run `{{TEST_COMMAND}}` (Maven default: `mvn test`) filtered to the\n   identified file set via the build-tool-native filter (Maven:\n   `-Dtest=\u003Cclasses>`; other stacks in the full protocol).\n3. Parse the build-tool coverage XML (Maven default: JaCoCo at\n   `target\u002Fsite\u002Fjacoco\u002Fjacoco.xml`), re-scope the totals to the story's\n   file list, and compare against the line \u002F branch thresholds.\n4. Perform cross-file consistency checks on the story's files\n   (constructor arity uniformity, return-type uniformity per role)\n   using the heuristic catalogue described in the full protocol.\n5. When `testing.smoke_tests == true` in the project config, run the\n   smoke suite; the smoke result contributes to `passed` only when its\n   Health Check or Critical Path layer fails (Response-Time and\n   Error-Rate layers are advisory per EPIC-0042).\n6. Validate every Section 7 Gherkin scenario (`Cenario:` \u002F `Scenario:`)\n   maps to at least one test class \u002F method; a missing mapping emits\n   an `acCheckResults` entry with `hasTest=false` and appends to\n   `failures`.\n7. Emit a single-line JSON envelope on stdout:\n   `{passed, coverageDelta, failures, acCheckResults}`.\n\nNon-responsibilities (explicit):\n\n- The skill does NOT create branches, run PR operations, or mutate\n  git state — the caller (`x-implement-story` Phase 3) and\n  `x-internal-update-status` handle those.\n- The skill does NOT write reports; `x-internal-write-report` renders\n  the consolidated dashboard off the envelope this skill emits.\n- The skill does NOT update `execution-state.json`; the caller owns\n  the transition to `COMPLETE` \u002F `FAILED` after consuming `passed`.\n- The skill does NOT dispatch specialist reviews or the Tech Lead\n  review — Phase 3.4 \u002F 3.6 stay in the orchestrator.\n\n## Convention Anchors (x-internal-*)\n\n| Aspect | Value | Rationale |\n| :--- | :--- | :--- |\n| Path | `internal\u002Fplan\u002Fx-internal-verify-story\u002F` | `internal\u002F` prefix scopes visibility; `plan\u002F` co-locates with the other carve-outs of the story-level planning\u002Fverification pipeline (`x-internal-load-story-context`, `x-internal-build-story-plan`) |\n| Frontmatter `visibility` | `internal` | Generator filters these from `\u002Fhelp` menu |\n| Frontmatter `user-invocable` | `false` | Declarative complement to `visibility: internal` |\n| Body marker | `> 🔒 **INTERNAL SKILL**` block as first non-frontmatter content | Visible to humans browsing the repo; no parsing required |\n| Allowed tools | `Bash` only | The skill shells out to the build tool, parses XML with `xmllint` \u002F `jq`, and emits JSON with `jq -n`; no `Skill` \u002F `Agent` needed — verification is a leaf operation |\n| Naming | `x-internal-{subject}-{action}` | Mirrors Rule 04 skill taxonomy; `story-verify` = subject+action |\n\nAudit rule: Rule 22 (Lifecycle Integrity) validates every skill under\n`internal\u002F**` satisfies all 6 anchors above. Violations fail\n`LifecycleIntegrityAuditTest`.\n\n## Triggers\n\nBare-slash form is intentionally omitted — this skill is never\ninvoked by a human typing `\u002Fx-internal-verify-story` in chat. All\ninvocations follow Rule 13 INLINE-SKILL pattern from a calling\norchestrator:\n\n```markdown\nSkill(skill: \"x-internal-verify-story\",\n      args: \"--story-id story-0049-0014 --epic-id 0049\")\n```\n\n```markdown\nSkill(skill: \"x-internal-verify-story\",\n      args: \"--story-id story-0049-0014 --epic-id 0049 --coverage-threshold-line 90 --coverage-threshold-branch 85\")\n```\n\n## Parameters\n\n| Parameter | Required | Default | Description |\n| :--- | :--- | :--- | :--- |\n| `--story-id \u003Cid>` | M | — | Story identifier (`story-XXXX-YYYY` canonical form) |\n| `--epic-id \u003Cid>` | M | — | 4-digit epic identifier (`XXXX`) — used to resolve `ai\u002Fepics\u002Fepic-XXXX\u002F` |\n| `--coverage-threshold-line \u003CN>` | O | `95` | Minimum line coverage percentage (integer, 0-100) |\n| `--coverage-threshold-branch \u003CN>` | O | `90` | Minimum branch coverage percentage (integer, 0-100) |\n\nAll four argument forms (`--key value`, `--key=value`, empty, and\nunknown-flag rejection) are supported; unknown flags and missing\nrequired flags exit with `64` (sysexits `EX_USAGE`). The `--story-id`\nvalue is normalised to lowercase and validated against\n`^story-[0-9]{4}-[0-9]{4}$`; `--epic-id` is zero-padded to 4 digits.\nThresholds outside `[0, 100]` exit `64`.\n\n## Response Contract\n\nOn success (any exit code ≤ 3) the skill writes a single-line JSON\nobject to stdout. The envelope is always well-formed JSON; consumers\nMUST read `passed` as the authoritative gate.\n\n| Field | Type | Always Present | Description |\n| :--- | :--- | :--- | :--- |\n| `passed` | `Boolean` | yes | Global gate: `true` iff all four sub-gates pass (tests green, coverage ≥ thresholds, cross-file consistency clean, every AC scenario has a test, smoke Health Check + Critical Path green when smoke is enabled) |\n| `coverageDelta` | `Object` | yes | `{line: Number, branch: Number, lineThreshold: Number, branchThreshold: Number, lineDelta: Number, branchDelta: Number}` — the four `*Threshold` fields echo the inputs; `*Delta` is `actual − threshold` (negative when below) |\n| `failures` | `Array\u003CString>` | yes | One human-readable line per failure (empty array on happy path). Categories: `test:`, `coverage:`, `consistency:`, `ac:`, `smoke:` |\n| `acCheckResults` | `Array\u003C{scenario:String, hasTest:Boolean}>` | yes | One entry per Section 7 scenario; `hasTest=false` always corresponds to an `ac:` failure in `failures` |\n\n### Example envelope (happy path)\n\n```json\n{\"passed\":true,\"coverageDelta\":{\"line\":96.4,\"branch\":92.1,\"lineThreshold\":95,\"branchThreshold\":90,\"lineDelta\":1.4,\"branchDelta\":2.1},\"failures\":[],\"acCheckResults\":[{\"scenario\":\"Verify passa em story limpa\",\"hasTest\":true},{\"scenario\":\"Falha — AC sem teste\",\"hasTest\":true}]}\n```\n\n### Example envelope (coverage below + AC gap)\n\n```json\n{\"passed\":false,\"coverageDelta\":{\"line\":88.2,\"branch\":91.0,\"lineThreshold\":95,\"branchThreshold\":90,\"lineDelta\":-6.8,\"branchDelta\":1.0},\"failures\":[\"coverage: line 88.2 \u003C 95\",\"ac: 'Boundary — coverage exatamente no threshold' has no test\"],\"acCheckResults\":[{\"scenario\":\"Verify passa em story limpa\",\"hasTest\":true},{\"scenario\":\"Boundary — coverage exatamente no threshold\",\"hasTest\":false}]}\n```\n\n## Exit Codes\n\n| Code | Name | Condition | Message Format |\n| :--- | :--- | :--- | :--- |\n| 0 | SUCCESS | Envelope emitted with `passed=true` | — |\n| 1 | STORY_FILES_NOT_FOUND | Task breakdown empty AND no file-owning tasks in Section 8 | `Could not identify story files` |\n| 2 | MVN_TEST_FAILED | Build tool returned non-zero before coverage could be parsed | `Test suite failed` |\n| 3 | COVERAGE_BELOW_THRESHOLD | Envelope emitted with `passed=false` due to coverage | `Coverage below threshold` |\n| 64 | EX_USAGE | Unknown or malformed flag | `usage: --story-id \u003Cid> --epic-id \u003Cid> [--coverage-threshold-line N] [--coverage-threshold-branch N]` |\n\nWhen `passed=false` is driven by AC gap, consistency, or smoke (not\ncoverage), the exit code is `0` and the caller MUST branch off\n`passed` — the non-zero exit is reserved for infrastructure-level\nfailures (build errors, missing files). This keeps the envelope the\nsingle source of truth for the orchestrator.\n\n## Workflow\n\n### Step 1 — Argument parsing and path resolution\n\nParse the four flags; reject unknown and missing required flags with\nexit `64`. Resolve canonical paths:\n\n```bash\nepic_dir=\"ai\u002Fepics\u002Fepic-${epic_id}\"\nstory_file=\"${epic_dir}\u002F${story_id}.md\"\ntasks_file=\"${epic_dir}\u002Fplans\u002Ftasks-${story_id}.md\"\n```\n\nThe skill does NOT exit when `tasks_file` is absent — Step 2 falls\nback to parsing Section 8 of `story_file`. It DOES exit `64` when\neither `--story-id` or `--epic-id` fails regex validation.\n\n### Step 2 — Identify story files\n\nPrefer the task breakdown (`tasks-story-XXXX-YYYY.md`), whose `Files:`\nbullet under each task is the authoritative source of truth. When the\nbreakdown is absent (legacy v1 stories), fall back to Section 8 of the\nstory file and extract `**Files:**` lines. De-duplicate and normalise\neach path to repo-relative form.\n\nIf the resulting list is empty, exit `1` (`STORY_FILES_NOT_FOUND`)\nwith message `Could not identify story files`.\n\n### Step 3 — Run scoped tests\n\nDispatch the build-tool-native filtered invocation. Maven default:\n\n```bash\nclass_csv=$(file_list_to_maven_classes \"${files[@]}\")\nmvn test -Dtest=\"${class_csv}\" -q\n```\n\nNon-Maven stacks use their own filters (listed in the full protocol);\nthe skill auto-detects the build tool by probing `pom.xml`,\n`build.gradle(.kts)`, `package.json`, `Cargo.toml`, `go.mod`,\n`pyproject.toml`. When no build tool is detected, the skill logs\n`test: no build tool detected; skipping` to stderr, emits `passed=true`\nfor the test gate (degraded but non-blocking), and continues to Step 4.\n\nNon-zero build-tool exit with parseable failure → exit `2`\n(`MVN_TEST_FAILED`). Non-zero with the build tool complaining about\npattern-match (e.g., `-Dtest=` matched zero classes) → treat as\n`test: no matching classes for pattern \u003C...>` failure, exit `0` with\n`passed=false`.\n\n### Step 4 — Parse filtered coverage\n\nRead the coverage XML (Maven default: `target\u002Fsite\u002Fjacoco\u002Fjacoco.xml`).\nFor each file in the story's identified list, sum `counter type=\"LINE\"`\nand `counter type=\"BRANCH\"` across the matching `\u003Cclass>` \u002F `\u003Csourcefile>`\nelements; compute percentage = `covered \u002F (covered + missed) * 100`\n(rounded to one decimal). Compare against `--coverage-threshold-line`\nand `--coverage-threshold-branch`.\n\nWhen the coverage XML is absent (build tool produced no report), emit\n`coverage: report not generated` to `failures` with `line=0` \u002F\n`branch=0` in `coverageDelta`, `passed=false`, exit `3`.\n\n### Step 5 — Cross-file consistency heuristics\n\nFor every pair of files in the story's list that share a **role**\n(heuristic: identical suffix — `*Controller.java`, `*Service.java`,\n`*Assembler.java`, `*Mapper.java`, `*Repository.java`, `*Port.java`,\n`*UseCase.java`, `*Dto.java`, `*Entity.java`), compare:\n\n1. **Constructor arity** — number of explicit constructor parameters\n   must match across siblings of the same role.\n2. **Return-type uniformity for common method names** — when two\n   siblings both declare `handle`, `execute`, `process`, `apply`,\n   `create`, `update`, `delete`, or `find*`, their return types must\n   match (ignoring generic parameters in Level 1; full generic match\n   in the `--strict-consistency` extension defined in the full\n   protocol).\n3. **Error-handling shape** — identical exception-thrown or Result\n   wrapper (domain convention): if one sibling throws and the other\n   returns `Optional`\u002F`Result`, emit `consistency: mixed error shape\n   across \u003CA> and \u003CB>`.\n\nEach violation appends to `failures` as `consistency: \u003Cshort desc>`.\nConsistency violations are MEDIUM severity and contribute to\n`passed=false` but do NOT change the exit code. Rationale: RULE-005\ntreats cross-file divergence as MEDIUM; blocking the build on every\nheuristic miss is too strict for mixed-role stories.\n\n### Step 6 — Smoke gate (conditional)\n\nActivate only when the project config declares `testing.smoke_tests == true`\n(read from the generator YAML or the merged project context). Delegate\nto the project smoke command (Maven default: `mvn verify -Psmoke`).\nParse the four smoke layers from the output:\n\n| Layer | Blocks `passed`? |\n| :--- | :--- |\n| Health Check | yes (hard) |\n| Critical Path | yes (hard) |\n| Response Time | no (advisory) |\n| Error Rate | no (advisory) |\n\nHard failures append `smoke: \u003Clayer> failed` to `failures`. Advisory\nlayers emit stderr warnings but do not alter `passed`.\n\n### Step 7 — AC validation (Gherkin → test mapping)\n\nExtract Section 7 scenarios from the story file (match `^Cenario:` or\n`^Scenario:` inside the fenced gherkin block). For each scenario,\nattempt to locate a test method whose name (case-insensitively)\ncontains a 3+ word slug derived from the scenario title (strip\naccents, collapse whitespace to `-`). Matching uses a breadth-first\nsearch rooted at `src\u002Ftest\u002F` with an early-exit on first match.\n\nWhen no match is found, append an `acCheckResults` entry with\n`hasTest=false` AND a `failures` line\n`ac: '\u003Cscenario title>' has no test`. Matches populate the same array\nwith `hasTest=true`.\n\n### Step 8 — Assemble and emit envelope\n\nCompose the JSON envelope via `jq -nc`. The exit code is the lowest\napplicable (0 success; 1 no files; 2 test failure; 3 coverage gap).\n\n```bash\njq -nc \\\n  --argjson passed \"${passed_bool}\" \\\n  --argjson coverageDelta \"${coverage_json}\" \\\n  --argjson failures \"${failures_json}\" \\\n  --argjson acCheckResults \"${ac_json}\" \\\n  '{passed:$passed, coverageDelta:$coverageDelta,\n    failures:$failures, acCheckResults:$acCheckResults}'\n```\n\n## Examples\n\n### Example 1 — Happy path: clean story, all gates green\n\n```bash\nSkill(skill: \"x-internal-verify-story\",\n      args: \"--story-id story-0049-0014 --epic-id 0049\")\n```\n\nEnvelope:\n\n```json\n{\"passed\":true,\"coverageDelta\":{\"line\":96.4,\"branch\":92.1,\"lineThreshold\":95,\"branchThreshold\":90,\"lineDelta\":1.4,\"branchDelta\":2.1},\"failures\":[],\"acCheckResults\":[{\"scenario\":\"Verify passa em story limpa\",\"hasTest\":true}]}\n```\n\nExit: 0.\n\n### Example 2 — AC gap\n\n```bash\nSkill(skill: \"x-internal-verify-story\",\n      args: \"--story-id story-0049-0014 --epic-id 0049\")\n```\n\nEnvelope includes `\"passed\":false` and `\"ac: 'Boundary — coverage exatamente no threshold' has no test\"` in `failures`. Exit: 0 (AC gap is envelope-reported, not a process error).\n\n### Example 3 — Coverage below threshold\n\n```bash\nSkill(skill: \"x-internal-verify-story\",\n      args: \"--story-id story-0049-0014 --epic-id 0049\")\n```\n\nEnvelope includes `\"passed\":false` and `coverageDelta.line=88.2, lineDelta=-6.8`. Exit: 3.\n\n### Example 4 — No story files identified\n\n```bash\nSkill(skill: \"x-internal-verify-story\",\n      args: \"--story-id story-0049-0014 --epic-id 0049\")\n```\n\nStderr: `Could not identify story files`. Exit: 1. No envelope emitted.\n\n### Example 5 — Boundary: coverage exactly on threshold\n\n```bash\nSkill(skill: \"x-internal-verify-story\",\n      args: \"--story-id story-0049-0014 --epic-id 0049\")\n```\n\nEnvelope `\"coverageDelta\":{\"line\":95.0,\"lineThreshold\":95,\"lineDelta\":0.0,…}` → `passed=true`. Exit: 0.\n\n### Example 6 — Custom thresholds (per-story override)\n\n```bash\nSkill(skill: \"x-internal-verify-story\",\n      args: \"--story-id story-0049-0014 --epic-id 0049 --coverage-threshold-line 80 --coverage-threshold-branch 75\")\n```\n\nEnvelope reports `lineThreshold=80, branchThreshold=75`. Use case:\nstories touching only documentation files override the project-wide\ndefaults.\n\n## Outputs\n\n| Artifact | Path | Description |\n| :--- | :--- | :--- |\n| Response envelope | stdout | Single-line JSON matching the Response Contract |\n| Error diagnostic | stderr | Single line, non-empty only on exit ≠ 0 |\n\nNo file is created or modified. The skill is **strictly read-only**\nagainst the project source tree (enforced by `allowed-tools: Bash`\nfrontmatter — no `Write` \u002F `Edit` available). It DOES execute the\nbuild tool, which mutates `target\u002F` (Maven) or equivalent — that is\nthe build tool's responsibility, not a state mutation in the sense of\nthe `x-internal-ops\u002F*` skills.\n\n## Error Handling\n\n| Scenario | Action |\n| :--- | :--- |\n| Missing required flag | Print `usage:` banner to stderr; exit 64 |\n| Unknown flag | Print `unknown flag \u003Cname>; usage:`; exit 64 |\n| Threshold outside `[0, 100]` | Print `threshold must be in [0,100]`; exit 64 |\n| `jq` \u002F `xmllint` absent on PATH | Print `dependency missing: \u003Ctool>`; exit 127 |\n| `pom.xml` \u002F build config absent | Print `no build tool detected`; emit `test: no build tool detected` in failures; continue Steps 4–7 best-effort |\n| Coverage XML unreadable | Emit `coverage: report unreadable (\u003Creason>)`; `passed=false`; exit 3 |\n| Test process segfaults \u002F OOM | Exit 2 with `Test suite failed (\u003Csignal>)`; no envelope |\n| Smoke suite absent while `smoke_tests=true` | Emit `smoke: configured but runner absent`; `passed=false`; no exit-code change |\n| Gherkin block malformed (unterminated fence) | Treat as zero scenarios; append `ac: gherkin block unparseable` to failures; continue |\n| Section 8 malformed (no `Files:` bullets) | Fall back to heuristic: treat every `*.java` \u002F `*.ts` \u002F `*.py` under `src\u002Fmain\u002F` mentioned in commit messages of the story's task branches; if none, exit 1 |\n| Stat flavour mismatch (GNU vs BSD) | Try `stat -f %m` (BSD) first; fall back to `stat -c %Y` (GNU) |\n\n## Performance Contract\n\nTarget: \u003C 3 minutes for a typical \"medium\" story (5–7 tasks, ~20\nclasses in scope) on a laptop-class machine. Breakdown budget:\n\n| Step | Target |\n| :--- | :--- |\n| Argument parse + file-list build | \u003C 200 ms |\n| Scoped test run | \u003C 120 s |\n| Coverage XML parse | \u003C 500 ms |\n| Cross-file consistency | \u003C 2 s |\n| Smoke (when enabled) | \u003C 45 s |\n| AC scenario mapping | \u003C 5 s (fanout bounded by scenario count) |\n| Envelope assembly | \u003C 50 ms |\n\nLarge stories (10+ tasks, 50+ classes) may exceed the total; the\nfull-protocol reference documents an opt-in `--parallel-tests` knob\n(Maven surefire `forkCount`) for those cases.\n\n## Testing\n\nThe story ships the following acceptance test scenarios, mirroring\nSection 7 of story-0049-0014:\n\n1. **Degenerate — verify passes on a clean story.** All ACs have tests,\n   coverage line=96 \u002F branch=92 → `passed=true`, exit 0.\n2. **Failure — AC without a test.** One scenario has no matching test\n   method → `passed=false`, `failures` contains the AC entry, exit 0.\n3. **Failure — coverage below threshold.** Line=88 with threshold=95 →\n   `passed=false`, exit 3.\n4. **Error — empty task breakdown.** No files identified → exit 1, no\n   envelope.\n5. **Boundary — coverage exactly on threshold.** Line=95 → `passed=true`,\n   exit 0.\n\nGoldens live under the smoke test resource path (see `Files:` of\nTASK-0049-0014-005). Coverage requirement: ≥ 95% line \u002F ≥ 90% branch\nacross the invoking Bash codepaths.\n\n## Generator Filter Contract\n\nThe `ia-dev-env` generator MUST exclude skills with\n`visibility: internal` from:\n\n1. The `.claude\u002FREADME.md` skill-inventory table.\n2. The `\u002Fhelp` menu listing surfaced by Claude Code.\n3. User-facing autocomplete in the chat input.\n\nInternal skills are still copied into `.claude\u002Fskills\u002F` (flat layout)\nso `Skill(skill: \"x-internal-...\")` invocations from other skills\nresolve correctly. The invariant: **user cannot see them; orchestrators\ncan invoke them.**\n\n## Telemetry\n\nInternal skills DO NOT emit `phase.start` \u002F `phase.end` markers —\ntelemetry is produced by the invoking orchestrator (the `phase`\nwrapping the orchestrator's own step — Phase 3 in this case — is the\ncorrect aggregation boundary). Passive hooks still capture `tool.call`\nfor the underlying `Bash` invocations (build tool, `jq`, `xmllint`).\n\nReference: Rule 13 (Skill Invocation Protocol), Rule 22 (Lifecycle\nIntegrity Audit), ADR-0010 (Interactive Gates Convention — exempts\ninternal skills from the 3-option menu contract).\n\n## Integration Notes\n\n| Skill | Relationship | Context |\n| :--- | :--- | :--- |\n| `x-implement-story` | caller (primary) | Phase 3 carve-out: the skill's stdout envelope replaces Steps 3.1 (coverage), 3.2 (cross-file consistency), 3.8 (smoke), and the implicit AC → test mapping — ~160 inline lines |\n| `x-implement-epic` | caller (indirect, via story-0049-0019 downstream) | Consumes the same envelope when iterating stories at the epic scope; `passed=false` drives per-story remediation loops |\n| `x-internal-load-story-context` | peer | Sibling `internal\u002Fplan\u002F` skill; provides the upstream envelope consumed by Phase 0 (`storyFile`, `taskCount`, `scopeTier`); this skill reads the story file independently for Section 7 scenarios (idempotent mtime-aware) |\n| `x-internal-build-story-plan` | peer | Sibling `internal\u002Fplan\u002F` skill; runs the Phase 1 planning dispatch; this skill runs the Phase 3 verification gate at the end of the same story's lifecycle |\n| `x-internal-write-report` | downstream | Consumes this skill's envelope to render the story dashboard `dashboard-story-XXXX-YYYY.md` |\n| `x-internal-update-status` | downstream | Consumes `passed` to transition `execution-state.json` → `COMPLETE` \u002F `FAILED` |\n| `x-execute-e2e-tests` | indirect | Project smoke runner invoked in Step 6 when `testing.smoke_tests == true` |\n\nDownstream stories that depend on this carve-out: story-0049-0019\n(orchestrator consumes the envelope and deletes the inline Phase 3\nblock).\n\nFull workflow detail (argument-parser rejection matrix, file-list\nheuristics per build tool, coverage-XML schema for JaCoCo \u002F Istanbul \u002F\nCobertura \u002F llvm-cov \u002F go-cover, cross-file consistency heuristic\ncatalogue with worked examples, AC scenario-slug → test-name matching\nalgorithm, smoke-layer parsing contract, and the\n`--parallel-tests` \u002F `--strict-consistency` extensions) lives in\n[`references\u002Ffull-protocol.md`](references\u002Ffull-protocol.md) per\nADR-0011.\n","## Global Output Policy\n\n- **Language**: English ONLY.\n- **Tone**: Technical, Direct, and Concise.\n- **Efficiency**: Remove all conversational fillers and greetings to save tokens.\n\n> 🔒 **INTERNAL SKILL**\n> Esta skill é invocada apenas por outras skills (orquestradores).\n> NÃO é destinada a invocação direta pelo usuário.\n> Caller principal: x-implement-story (Phase 3 carve-out).\n> Sexta skill da convenção `x-internal-*` (após x-internal-update-status\n> pilot 0049-0005, x-internal-write-report 0049-0006,\n> x-internal-normalize-args 0049-0007, x-internal-load-story-context\n> 0049-0011, e x-internal-build-story-plan 0049-0012). Terceira skill\n> na subdir `internal\u002Fplan\u002F` — o subdir `plan\u002F` agrupa orquestração de\n> planejamento e verificação da story (load → build → verify). Difere\n> de `internal\u002Fops\u002F`, cujas sibling skills mutam estado (execution-state,\n> reports).\n\n# Skill: x-internal-verify-story\n\n## Purpose\n\nCarve out Phase 3 (Story-Level Verification) of `x-implement-story`\ninto a single, single-responsibility skill. The ~160 inline lines\ncurrently inside `x-implement-story` Phase 3 (Step 3.1 coverage, Step\n3.2 cross-file consistency, Step 3.8 smoke gate, implicit AC → test\nmapping) become a single\n`Skill(skill: \"x-internal-verify-story\", …)` invocation; the\norchestrator shrinks to a read-the-envelope consumer that drives its\nremediation \u002F tech-lead-review branching off the four response fields.\n\nResponsibilities (single):\n\n1. Identify the files \"owned\" by the story via the task breakdown at\n   `ai\u002Fepics\u002Fepic-XXXX\u002Fplans\u002Ftasks-story-XXXX-YYYY.md` (Section 8\n   fallback of the story file when the breakdown is absent).\n2. Run `{{TEST_COMMAND}}` (Maven default: `mvn test`) filtered to the\n   identified file set via the build-tool-native filter (Maven:\n   `-Dtest=\u003Cclasses>`; other stacks in the full protocol).\n3. Parse the build-tool coverage XML (Maven default: JaCoCo at\n   `target\u002Fsite\u002Fjacoco\u002Fjacoco.xml`), re-scope the totals to the story's\n   file list, and compare against the line \u002F branch thresholds.\n4. Perform cross-file consistency checks on the story's files\n   (constructor arity uniformity, return-type uniformity per role)\n   using the heuristic catalogue described in the full protocol.\n5. When `testing.smoke_tests == true` in the project config, run the\n   smoke suite; the smoke result contributes to `passed` only when its\n   Health Check or Critical Path layer fails (Response-Time and\n   Error-Rate layers are advisory per EPIC-0042).\n6. Validate every Section 7 Gherkin scenario (`Cenario:` \u002F `Scenario:`)\n   maps to at least one test class \u002F method; a missing mapping emits\n   an `acCheckResults` entry with `hasTest=false` and appends to\n   `failures`.\n7. Emit a single-line JSON envelope on stdout:\n   `{passed, coverageDelta, failures, acCheckResults}`.\n\nNon-responsibilities (explicit):\n\n- The skill does NOT create branches, run PR operations, or mutate\n  git state — the caller (`x-implement-story` Phase 3) and\n  `x-internal-update-status` handle those.\n- The skill does NOT write reports; `x-internal-write-report` renders\n  the consolidated dashboard off the envelope this skill emits.\n- The skill does NOT update `execution-state.json`; the caller owns\n  the transition to `COMPLETE` \u002F `FAILED` after consuming `passed`.\n- The skill does NOT dispatch specialist reviews or the Tech Lead\n  review — Phase 3.4 \u002F 3.6 stay in the orchestrator.\n\n## Convention Anchors (x-internal-*)\n\n| Aspect | Value | Rationale |\n| :--- | :--- | :--- |\n| Path | `internal\u002Fplan\u002Fx-internal-verify-story\u002F` | `internal\u002F` prefix scopes visibility; `plan\u002F` co-locates with the other carve-outs of the story-level planning\u002Fverification pipeline (`x-internal-load-story-context`, `x-internal-build-story-plan`) |\n| Frontmatter `visibility` | `internal` | Generator filters these from `\u002Fhelp` menu |\n| Frontmatter `user-invocable` | `false` | Declarative complement to `visibility: internal` |\n| Body marker | `> 🔒 **INTERNAL SKILL**` block as first non-frontmatter content | Visible to humans browsing the repo; no parsing required |\n| Allowed tools | `Bash` only | The skill shells out to the build tool, parses XML with `xmllint` \u002F `jq`, and emits JSON with `jq -n`; no `Skill` \u002F `Agent` needed — verification is a leaf operation |\n| Naming | `x-internal-{subject}-{action}` | Mirrors Rule 04 skill taxonomy; `story-verify` = subject+action |\n\nAudit rule: Rule 22 (Lifecycle Integrity) validates every skill under\n`internal\u002F**` satisfies all 6 anchors above. Violations fail\n`LifecycleIntegrityAuditTest`.\n\n## Triggers\n\nBare-slash form is intentionally omitted — this skill is never\ninvoked by a human typing `\u002Fx-internal-verify-story` in chat. All\ninvocations follow Rule 13 INLINE-SKILL pattern from a calling\norchestrator:\n\n```markdown\nSkill(skill: \"x-internal-verify-story\",\n      args: \"--story-id story-0049-0014 --epic-id 0049\")\n```\n\n```markdown\nSkill(skill: \"x-internal-verify-story\",\n      args: \"--story-id story-0049-0014 --epic-id 0049 --coverage-threshold-line 90 --coverage-threshold-branch 85\")\n```\n\n## Parameters\n\n| Parameter | Required | Default | Description |\n| :--- | :--- | :--- | :--- |\n| `--story-id \u003Cid>` | M | — | Story identifier (`story-XXXX-YYYY` canonical form) |\n| `--epic-id \u003Cid>` | M | — | 4-digit epic identifier (`XXXX`) — used to resolve `ai\u002Fepics\u002Fepic-XXXX\u002F` |\n| `--coverage-threshold-line \u003CN>` | O | `95` | Minimum line coverage percentage (integer, 0-100) |\n| `--coverage-threshold-branch \u003CN>` | O | `90` | Minimum branch coverage percentage (integer, 0-100) |\n\nAll four argument forms (`--key value`, `--key=value`, empty, and\nunknown-flag rejection) are supported; unknown flags and missing\nrequired flags exit with `64` (sysexits `EX_USAGE`). The `--story-id`\nvalue is normalised to lowercase and validated against\n`^story-[0-9]{4}-[0-9]{4}$`; `--epic-id` is zero-padded to 4 digits.\nThresholds outside `[0, 100]` exit `64`.\n\n## Response Contract\n\nOn success (any exit code ≤ 3) the skill writes a single-line JSON\nobject to stdout. The envelope is always well-formed JSON; consumers\nMUST read `passed` as the authoritative gate.\n\n| Field | Type | Always Present | Description |\n| :--- | :--- | :--- | :--- |\n| `passed` | `Boolean` | yes | Global gate: `true` iff all four sub-gates pass (tests green, coverage ≥ thresholds, cross-file consistency clean, every AC scenario has a test, smoke Health Check + Critical Path green when smoke is enabled) |\n| `coverageDelta` | `Object` | yes | `{line: Number, branch: Number, lineThreshold: Number, branchThreshold: Number, lineDelta: Number, branchDelta: Number}` — the four `*Threshold` fields echo the inputs; `*Delta` is `actual − threshold` (negative when below) |\n| `failures` | `Array\u003CString>` | yes | One human-readable line per failure (empty array on happy path). Categories: `test:`, `coverage:`, `consistency:`, `ac:`, `smoke:` |\n| `acCheckResults` | `Array\u003C{scenario:String, hasTest:Boolean}>` | yes | One entry per Section 7 scenario; `hasTest=false` always corresponds to an `ac:` failure in `failures` |\n\n### Example envelope (happy path)\n\n```json\n{\"passed\":true,\"coverageDelta\":{\"line\":96.4,\"branch\":92.1,\"lineThreshold\":95,\"branchThreshold\":90,\"lineDelta\":1.4,\"branchDelta\":2.1},\"failures\":[],\"acCheckResults\":[{\"scenario\":\"Verify passa em story limpa\",\"hasTest\":true},{\"scenario\":\"Falha — AC sem teste\",\"hasTest\":true}]}\n```\n\n### Example envelope (coverage below + AC gap)\n\n```json\n{\"passed\":false,\"coverageDelta\":{\"line\":88.2,\"branch\":91.0,\"lineThreshold\":95,\"branchThreshold\":90,\"lineDelta\":-6.8,\"branchDelta\":1.0},\"failures\":[\"coverage: line 88.2 \u003C 95\",\"ac: 'Boundary — coverage exatamente no threshold' has no test\"],\"acCheckResults\":[{\"scenario\":\"Verify passa em story limpa\",\"hasTest\":true},{\"scenario\":\"Boundary — coverage exatamente no threshold\",\"hasTest\":false}]}\n```\n\n## Exit Codes\n\n| Code | Name | Condition | Message Format |\n| :--- | :--- | :--- | :--- |\n| 0 | SUCCESS | Envelope emitted with `passed=true` | — |\n| 1 | STORY_FILES_NOT_FOUND | Task breakdown empty AND no file-owning tasks in Section 8 | `Could not identify story files` |\n| 2 | MVN_TEST_FAILED | Build tool returned non-zero before coverage could be parsed | `Test suite failed` |\n| 3 | COVERAGE_BELOW_THRESHOLD | Envelope emitted with `passed=false` due to coverage | `Coverage below threshold` |\n| 64 | EX_USAGE | Unknown or malformed flag | `usage: --story-id \u003Cid> --epic-id \u003Cid> [--coverage-threshold-line N] [--coverage-threshold-branch N]` |\n\nWhen `passed=false` is driven by AC gap, consistency, or smoke (not\ncoverage), the exit code is `0` and the caller MUST branch off\n`passed` — the non-zero exit is reserved for infrastructure-level\nfailures (build errors, missing files). This keeps the envelope the\nsingle source of truth for the orchestrator.\n\n## Workflow\n\n### Step 1 — Argument parsing and path resolution\n\nParse the four flags; reject unknown and missing required flags with\nexit `64`. Resolve canonical paths:\n\n```bash\nepic_dir=\"ai\u002Fepics\u002Fepic-${epic_id}\"\nstory_file=\"${epic_dir}\u002F${story_id}.md\"\ntasks_file=\"${epic_dir}\u002Fplans\u002Ftasks-${story_id}.md\"\n```\n\nThe skill does NOT exit when `tasks_file` is absent — Step 2 falls\nback to parsing Section 8 of `story_file`. It DOES exit `64` when\neither `--story-id` or `--epic-id` fails regex validation.\n\n### Step 2 — Identify story files\n\nPrefer the task breakdown (`tasks-story-XXXX-YYYY.md`), whose `Files:`\nbullet under each task is the authoritative source of truth. When the\nbreakdown is absent (legacy v1 stories), fall back to Section 8 of the\nstory file and extract `**Files:**` lines. De-duplicate and normalise\neach path to repo-relative form.\n\nIf the resulting list is empty, exit `1` (`STORY_FILES_NOT_FOUND`)\nwith message `Could not identify story files`.\n\n### Step 3 — Run scoped tests\n\nDispatch the build-tool-native filtered invocation. Maven default:\n\n```bash\nclass_csv=$(file_list_to_maven_classes \"${files[@]}\")\nmvn test -Dtest=\"${class_csv}\" -q\n```\n\nNon-Maven stacks use their own filters (listed in the full protocol);\nthe skill auto-detects the build tool by probing `pom.xml`,\n`build.gradle(.kts)`, `package.json`, `Cargo.toml`, `go.mod`,\n`pyproject.toml`. When no build tool is detected, the skill logs\n`test: no build tool detected; skipping` to stderr, emits `passed=true`\nfor the test gate (degraded but non-blocking), and continues to Step 4.\n\nNon-zero build-tool exit with parseable failure → exit `2`\n(`MVN_TEST_FAILED`). Non-zero with the build tool complaining about\npattern-match (e.g., `-Dtest=` matched zero classes) → treat as\n`test: no matching classes for pattern \u003C...>` failure, exit `0` with\n`passed=false`.\n\n### Step 4 — Parse filtered coverage\n\nRead the coverage XML (Maven default: `target\u002Fsite\u002Fjacoco\u002Fjacoco.xml`).\nFor each file in the story's identified list, sum `counter type=\"LINE\"`\nand `counter type=\"BRANCH\"` across the matching `\u003Cclass>` \u002F `\u003Csourcefile>`\nelements; compute percentage = `covered \u002F (covered + missed) * 100`\n(rounded to one decimal). Compare against `--coverage-threshold-line`\nand `--coverage-threshold-branch`.\n\nWhen the coverage XML is absent (build tool produced no report), emit\n`coverage: report not generated` to `failures` with `line=0` \u002F\n`branch=0` in `coverageDelta`, `passed=false`, exit `3`.\n\n### Step 5 — Cross-file consistency heuristics\n\nFor every pair of files in the story's list that share a **role**\n(heuristic: identical suffix — `*Controller.java`, `*Service.java`,\n`*Assembler.java`, `*Mapper.java`, `*Repository.java`, `*Port.java`,\n`*UseCase.java`, `*Dto.java`, `*Entity.java`), compare:\n\n1. **Constructor arity** — number of explicit constructor parameters\n   must match across siblings of the same role.\n2. **Return-type uniformity for common method names** — when two\n   siblings both declare `handle`, `execute`, `process`, `apply`,\n   `create`, `update`, `delete`, or `find*`, their return types must\n   match (ignoring generic parameters in Level 1; full generic match\n   in the `--strict-consistency` extension defined in the full\n   protocol).\n3. **Error-handling shape** — identical exception-thrown or Result\n   wrapper (domain convention): if one sibling throws and the other\n   returns `Optional`\u002F`Result`, emit `consistency: mixed error shape\n   across \u003CA> and \u003CB>`.\n\nEach violation appends to `failures` as `consistency: \u003Cshort desc>`.\nConsistency violations are MEDIUM severity and contribute to\n`passed=false` but do NOT change the exit code. Rationale: RULE-005\ntreats cross-file divergence as MEDIUM; blocking the build on every\nheuristic miss is too strict for mixed-role stories.\n\n### Step 6 — Smoke gate (conditional)\n\nActivate only when the project config declares `testing.smoke_tests == true`\n(read from the generator YAML or the merged project context). Delegate\nto the project smoke command (Maven default: `mvn verify -Psmoke`).\nParse the four smoke layers from the output:\n\n| Layer | Blocks `passed`? |\n| :--- | :--- |\n| Health Check | yes (hard) |\n| Critical Path | yes (hard) |\n| Response Time | no (advisory) |\n| Error Rate | no (advisory) |\n\nHard failures append `smoke: \u003Clayer> failed` to `failures`. Advisory\nlayers emit stderr warnings but do not alter `passed`.\n\n### Step 7 — AC validation (Gherkin → test mapping)\n\nExtract Section 7 scenarios from the story file (match `^Cenario:` or\n`^Scenario:` inside the fenced gherkin block). For each scenario,\nattempt to locate a test method whose name (case-insensitively)\ncontains a 3+ word slug derived from the scenario title (strip\naccents, collapse whitespace to `-`). Matching uses a breadth-first\nsearch rooted at `src\u002Ftest\u002F` with an early-exit on first match.\n\nWhen no match is found, append an `acCheckResults` entry with\n`hasTest=false` AND a `failures` line\n`ac: '\u003Cscenario title>' has no test`. Matches populate the same array\nwith `hasTest=true`.\n\n### Step 8 — Assemble and emit envelope\n\nCompose the JSON envelope via `jq -nc`. The exit code is the lowest\napplicable (0 success; 1 no files; 2 test failure; 3 coverage gap).\n\n```bash\njq -nc \\\n  --argjson passed \"${passed_bool}\" \\\n  --argjson coverageDelta \"${coverage_json}\" \\\n  --argjson failures \"${failures_json}\" \\\n  --argjson acCheckResults \"${ac_json}\" \\\n  '{passed:$passed, coverageDelta:$coverageDelta,\n    failures:$failures, acCheckResults:$acCheckResults}'\n```\n\n## Examples\n\n### Example 1 — Happy path: clean story, all gates green\n\n```bash\nSkill(skill: \"x-internal-verify-story\",\n      args: \"--story-id story-0049-0014 --epic-id 0049\")\n```\n\nEnvelope:\n\n```json\n{\"passed\":true,\"coverageDelta\":{\"line\":96.4,\"branch\":92.1,\"lineThreshold\":95,\"branchThreshold\":90,\"lineDelta\":1.4,\"branchDelta\":2.1},\"failures\":[],\"acCheckResults\":[{\"scenario\":\"Verify passa em story limpa\",\"hasTest\":true}]}\n```\n\nExit: 0.\n\n### Example 2 — AC gap\n\n```bash\nSkill(skill: \"x-internal-verify-story\",\n      args: \"--story-id story-0049-0014 --epic-id 0049\")\n```\n\nEnvelope includes `\"passed\":false` and `\"ac: 'Boundary — coverage exatamente no threshold' has no test\"` in `failures`. Exit: 0 (AC gap is envelope-reported, not a process error).\n\n### Example 3 — Coverage below threshold\n\n```bash\nSkill(skill: \"x-internal-verify-story\",\n      args: \"--story-id story-0049-0014 --epic-id 0049\")\n```\n\nEnvelope includes `\"passed\":false` and `coverageDelta.line=88.2, lineDelta=-6.8`. Exit: 3.\n\n### Example 4 — No story files identified\n\n```bash\nSkill(skill: \"x-internal-verify-story\",\n      args: \"--story-id story-0049-0014 --epic-id 0049\")\n```\n\nStderr: `Could not identify story files`. Exit: 1. No envelope emitted.\n\n### Example 5 — Boundary: coverage exactly on threshold\n\n```bash\nSkill(skill: \"x-internal-verify-story\",\n      args: \"--story-id story-0049-0014 --epic-id 0049\")\n```\n\nEnvelope `\"coverageDelta\":{\"line\":95.0,\"lineThreshold\":95,\"lineDelta\":0.0,…}` → `passed=true`. Exit: 0.\n\n### Example 6 — Custom thresholds (per-story override)\n\n```bash\nSkill(skill: \"x-internal-verify-story\",\n      args: \"--story-id story-0049-0014 --epic-id 0049 --coverage-threshold-line 80 --coverage-threshold-branch 75\")\n```\n\nEnvelope reports `lineThreshold=80, branchThreshold=75`. Use case:\nstories touching only documentation files override the project-wide\ndefaults.\n\n## Outputs\n\n| Artifact | Path | Description |\n| :--- | :--- | :--- |\n| Response envelope | stdout | Single-line JSON matching the Response Contract |\n| Error diagnostic | stderr | Single line, non-empty only on exit ≠ 0 |\n\nNo file is created or modified. The skill is **strictly read-only**\nagainst the project source tree (enforced by `allowed-tools: Bash`\nfrontmatter — no `Write` \u002F `Edit` available). It DOES execute the\nbuild tool, which mutates `target\u002F` (Maven) or equivalent — that is\nthe build tool's responsibility, not a state mutation in the sense of\nthe `x-internal-ops\u002F*` skills.\n\n## Error Handling\n\n| Scenario | Action |\n| :--- | :--- |\n| Missing required flag | Print `usage:` banner to stderr; exit 64 |\n| Unknown flag | Print `unknown flag \u003Cname>; usage:`; exit 64 |\n| Threshold outside `[0, 100]` | Print `threshold must be in [0,100]`; exit 64 |\n| `jq` \u002F `xmllint` absent on PATH | Print `dependency missing: \u003Ctool>`; exit 127 |\n| `pom.xml` \u002F build config absent | Print `no build tool detected`; emit `test: no build tool detected` in failures; continue Steps 4–7 best-effort |\n| Coverage XML unreadable | Emit `coverage: report unreadable (\u003Creason>)`; `passed=false`; exit 3 |\n| Test process segfaults \u002F OOM | Exit 2 with `Test suite failed (\u003Csignal>)`; no envelope |\n| Smoke suite absent while `smoke_tests=true` | Emit `smoke: configured but runner absent`; `passed=false`; no exit-code change |\n| Gherkin block malformed (unterminated fence) | Treat as zero scenarios; append `ac: gherkin block unparseable` to failures; continue |\n| Section 8 malformed (no `Files:` bullets) | Fall back to heuristic: treat every `*.java` \u002F `*.ts` \u002F `*.py` under `src\u002Fmain\u002F` mentioned in commit messages of the story's task branches; if none, exit 1 |\n| Stat flavour mismatch (GNU vs BSD) | Try `stat -f %m` (BSD) first; fall back to `stat -c %Y` (GNU) |\n\n## Performance Contract\n\nTarget: \u003C 3 minutes for a typical \"medium\" story (5–7 tasks, ~20\nclasses in scope) on a laptop-class machine. Breakdown budget:\n\n| Step | Target |\n| :--- | :--- |\n| Argument parse + file-list build | \u003C 200 ms |\n| Scoped test run | \u003C 120 s |\n| Coverage XML parse | \u003C 500 ms |\n| Cross-file consistency | \u003C 2 s |\n| Smoke (when enabled) | \u003C 45 s |\n| AC scenario mapping | \u003C 5 s (fanout bounded by scenario count) |\n| Envelope assembly | \u003C 50 ms |\n\nLarge stories (10+ tasks, 50+ classes) may exceed the total; the\nfull-protocol reference documents an opt-in `--parallel-tests` knob\n(Maven surefire `forkCount`) for those cases.\n\n## Testing\n\nThe story ships the following acceptance test scenarios, mirroring\nSection 7 of story-0049-0014:\n\n1. **Degenerate — verify passes on a clean story.** All ACs have tests,\n   coverage line=96 \u002F branch=92 → `passed=true`, exit 0.\n2. **Failure — AC without a test.** One scenario has no matching test\n   method → `passed=false`, `failures` contains the AC entry, exit 0.\n3. **Failure — coverage below threshold.** Line=88 with threshold=95 →\n   `passed=false`, exit 3.\n4. **Error — empty task breakdown.** No files identified → exit 1, no\n   envelope.\n5. **Boundary — coverage exactly on threshold.** Line=95 → `passed=true`,\n   exit 0.\n\nGoldens live under the smoke test resource path (see `Files:` of\nTASK-0049-0014-005). Coverage requirement: ≥ 95% line \u002F ≥ 90% branch\nacross the invoking Bash codepaths.\n\n## Generator Filter Contract\n\nThe `ia-dev-env` generator MUST exclude skills with\n`visibility: internal` from:\n\n1. The `.claude\u002FREADME.md` skill-inventory table.\n2. The `\u002Fhelp` menu listing surfaced by Claude Code.\n3. User-facing autocomplete in the chat input.\n\nInternal skills are still copied into `.claude\u002Fskills\u002F` (flat layout)\nso `Skill(skill: \"x-internal-...\")` invocations from other skills\nresolve correctly. The invariant: **user cannot see them; orchestrators\ncan invoke them.**\n\n## Telemetry\n\nInternal skills DO NOT emit `phase.start` \u002F `phase.end` markers —\ntelemetry is produced by the invoking orchestrator (the `phase`\nwrapping the orchestrator's own step — Phase 3 in this case — is the\ncorrect aggregation boundary). Passive hooks still capture `tool.call`\nfor the underlying `Bash` invocations (build tool, `jq`, `xmllint`).\n\nReference: Rule 13 (Skill Invocation Protocol), Rule 22 (Lifecycle\nIntegrity Audit), ADR-0010 (Interactive Gates Convention — exempts\ninternal skills from the 3-option menu contract).\n\n## Integration Notes\n\n| Skill | Relationship | Context |\n| :--- | :--- | :--- |\n| `x-implement-story` | caller (primary) | Phase 3 carve-out: the skill's stdout envelope replaces Steps 3.1 (coverage), 3.2 (cross-file consistency), 3.8 (smoke), and the implicit AC → test mapping — ~160 inline lines |\n| `x-implement-epic` | caller (indirect, via story-0049-0019 downstream) | Consumes the same envelope when iterating stories at the epic scope; `passed=false` drives per-story remediation loops |\n| `x-internal-load-story-context` | peer | Sibling `internal\u002Fplan\u002F` skill; provides the upstream envelope consumed by Phase 0 (`storyFile`, `taskCount`, `scopeTier`); this skill reads the story file independently for Section 7 scenarios (idempotent mtime-aware) |\n| `x-internal-build-story-plan` | peer | Sibling `internal\u002Fplan\u002F` skill; runs the Phase 1 planning dispatch; this skill runs the Phase 3 verification gate at the end of the same story's lifecycle |\n| `x-internal-write-report` | downstream | Consumes this skill's envelope to render the story dashboard `dashboard-story-XXXX-YYYY.md` |\n| `x-internal-update-status` | downstream | Consumes `passed` to transition `execution-state.json` → `COMPLETE` \u002F `FAILED` |\n| `x-execute-e2e-tests` | indirect | Project smoke runner invoked in Step 6 when `testing.smoke_tests == true` |\n\nDownstream stories that depend on this carve-out: story-0049-0019\n(orchestrator consumes the envelope and deletes the inline Phase 3\nblock).\n\nFull workflow detail (argument-parser rejection matrix, file-list\nheuristics per build tool, coverage-XML schema for JaCoCo \u002F Istanbul \u002F\nCobertura \u002F llvm-cov \u002F go-cover, cross-file consistency heuristic\ncatalogue with worked examples, AC scenario-slug → test-name matching\nalgorithm, smoke-layer parsing contract, and the\n`--parallel-tests` \u002F `--strict-consistency` extensions) lives in\n[`references\u002Ffull-protocol.md`](references\u002Ffull-protocol.md) per\nADR-0011.\n",{"name":5,"category":24,"visibility":25,"description":7,"allowed-tools":26,"argument-hint":27,"context-budget":28,"user-invocable":20,"requires-capabilities":29},"internal-plan","internal","Bash","--story-id \u003Cstory-XXXX-YYYY> --epic-id \u003CXXXX> [--coverage-threshold-line \u003CN>] [--coverage-threshold-branch \u003CN>]","medium",[],"main","952a630c6f38d193a349d86fa18db1de8843e837","src\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring-fintech-pci\u002F.claude\u002Fskills\u002Fx-internal-verify-story",1,"https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment","https:\u002F\u002Fgithub.com\u002Freview-bench","https:\u002F\u002Freview-bench.ai","An open benchmark for AI code review.","2026-10-27 06:56:37",{"source":8,"skillName":5,"commands":40,"prompt":50,"zipAvailable":51},[41,44,47],{"tool":42,"command":43},"npx","npx skills add review-bench\u002Federcnj_ia-dev-environment --skill x-internal-verify-story",{"tool":45,"command":46},"bunx","bunx skills add review-bench\u002Federcnj_ia-dev-environment --skill x-internal-verify-story",{"tool":48,"command":49},"pnpm","pnpm dlx skills add review-bench\u002Federcnj_ia-dev-environment --skill x-internal-verify-story","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring-fintech-pci\u002F.claude\u002Fskills\u002Fx-internal-verify-story\u002FSKILL.md",true,[53],{"path":54,"resourceType":55,"resourceTypeDesc":56,"sizeBytes":57,"sourceHtmlUrl":58},"references\u002Ffull-protocol.md","REFERENCE","参考文档",13399,"https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring-fintech-pci\u002F.claude\u002Fskills\u002Fx-internal-verify-story\u002Freferences\u002Ffull-protocol.md",[60,67,74,81,88,95],{"skillNo":61,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":66,"publishedAt":19},"01M757M8J48TQ1Y3X25GSJBXAS","x-parallel-eval","Detects and classifies file-collision risks between work units (tasks, stories, or epic phases) before parallel execution. Reads ## File Footprint blocks produced by x-task-plan \u002F x-story-plan, applies the parallelism-heuristics knowledge pack (hard \u002F regen \u002F soft categories + hotspot overrides), and emits a collision matrix + serialization recommendation in Markdown (default) or JSON.","https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fx-parallel-eval\u002FSKILL.md",[],[],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"publishedAt":19},"01M757M57XMR9546S69466HDWT","parallelism-heuristics","Canonical catalog of file-collision heuristics for parallel task, story, and epic execution. Defines the File Footprint block format, the three Conflict Categories (hard \u002F regen \u002F soft), a hotspot list of high-contention paths, and the degrade-with-warning policy. Consumed by x-task-plan, x-story-plan, x-epic-map, x-parallel-eval, and x-dev-*-implement.","https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fparallelism-heuristics\u002FSKILL.md",[],[],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":19},"01M757M11SZ8P1VCQABT08QVYA","x-watch-pr-ci","Polls a PR's CI checks and Copilot review status, blocking until checks complete or timeout. Returns one of 8 stable exit codes (SUCCESS=0, CI_PENDING_PROCEED=10, CI_FAILED=20, TIMEOUT=30, PR_ALREADY_MERGED=40, NO_CI_CONFIGURED=50, PR_CLOSED=60, PR_NOT_FOUND=70). Writes a versioned state-file for session resume.","https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring\u002Fplatform-claude-code\u002F.claude\u002Fskills\u002Fx-watch-pr-ci\u002FSKILL.md",[],[],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":19},"01M757KW53K8KFPGADFB4PH949","x-validate-docs","Documentation freshness gate: validates 6 dimensions (readme, api-specs, grpc-proto, adr, skill-docs, system-architecture) against code changes in a PR. Stack-aware — only validates targets declared\u002Fauto-detected from ProjectConfig.documentation.targets. Returns exit non-zero on staleness; produces structured report.","https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring\u002Fplatform-claude-code\u002F.claude\u002Fskills\u002Fx-validate-docs\u002FSKILL.md",[],[],{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":19},"01M757KQZHSA10MKC0CR571D60","x-update-system-architecture","Incrementally updates docs\u002Farchitecture\u002Fsystem.md after an epic completes. Appends new entries to the Decision Log (§11) using x-internal-write-report --append (dedup by ## ID: marker) and surgically inserts component\u002Fintegration changes into sections 1-10 via Edit. Idempotent: re-running with the same epic produces a byte-identical system.md.","https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring\u002Fplatform-claude-code\u002F.claude\u002Fskills\u002Fx-update-system-architecture\u002FSKILL.md",[],[],{"skillNo":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":101,"publishedAt":19},"01M757KKBT5Q1SVF8DMJBVF46M","x-update-architecture","Incrementally updates the service architecture document with changes from architecture plans. Adds new components, integrations, flows, and ADR references without rewriting existing content. Use after implementation to keep architecture documentation current.","https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring\u002Fplatform-claude-code\u002F.claude\u002Fskills\u002Fx-update-architecture\u002FSKILL.md",[],[]]