{"vulnerability": "cve-2020-2816", "sightings": [{"uuid": "5e1f9dc4-ee4d-483e-82b1-06571efc318c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2020-28169", "type": "seen", "source": "https://t.me/cibsecurity/21272", "content": "\u203c CVE-2020-28169 \u203c\n\nThe td-agent-builder plugin before 2020-12-18 for Fluentd allows attackers to gain privileges because the bin directory is writable by a user account, but a file in bin is executed as NT AUTHORITY\\SYSTEM.\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2020-12-24T18:55:23.000000Z"}, {"uuid": "0e104e42-fb64-4fda-be60-edf863194f9e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2020-28168", "type": "seen", "source": "https://gist.github.com/0xi1y4an7/605ea54aa36cbd993d66a4e7d1674901", "content": "", "creation_timestamp": "2025-05-14T23:15:09.000000Z"}, {"uuid": "b5a3cba4-fbc2-4da9-bcf4-f0812330da08", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2020-28165", "type": "seen", "source": "https://t.me/cibsecurity/27216", "content": "\u203c CVE-2020-28165 \u203c\n\nThe EasyCorp ZenTao PMS 12.4.2 application suffers from an arbitrary file upload vulnerability. An attacker can upload arbitrary webshell to the server by using the downloadZipPackage() function.\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2021-08-12T16:39:47.000000Z"}, {"uuid": "187f7450-00a9-4d8a-b048-c32ee2961a5c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2020-28168", "type": "seen", "source": "https://gist.github.com/joemocha/fe552c9601dc58c4f9731982ab0d1f8c", "content": "From 87a213729aba7bd86b4cb07a5e6630fdd0cdef19 Mon Sep 17 00:00:00 2001\nFrom: Samuel Obukwelu \nDate: Mon, 18 May 2026 21:35:28 -0400\nSubject: [PATCH] Add Block 3 audience materials\n\n---\n .pi/extensions/inspect-verify.ts              | 111 ++++++++++++++++++\n .pi/skills/architecture-verifier/SKILL.md     |  54 +++++++++\n .pi/skills/performance-verifier/SKILL.md      |  53 +++++++++\n .pi/skills/project-inspector/SKILL.md         |  53 +++++++++\n .pi/skills/project-verifier/SKILL.md          |  89 ++++++++++++++\n AGENTS.md                                     |  47 ++++++++\n README.md                                     |  16 ++-\n SYSTEM.md                                     |  11 ++\n block3/README.md                              |  57 +++++++++\n fixtures/agentic-target-sample/README.md      |  59 ++++++++++\n .../components/Header.vue                     |  16 +++\n .../composables/useExample.ts                 |   4 +\n fixtures/agentic-target-sample/nuxt.config.ts |  14 +++\n fixtures/agentic-target-sample/package.json   |  24 ++++\n .../agentic-target-sample/pages/about.vue     |  14 +++\n .../agentic-target-sample/pages/index.vue     |  14 +++\n 16 files changed, 634 insertions(+), 2 deletions(-)\n create mode 100644 .pi/extensions/inspect-verify.ts\n create mode 100644 .pi/skills/architecture-verifier/SKILL.md\n create mode 100644 .pi/skills/performance-verifier/SKILL.md\n create mode 100644 .pi/skills/project-inspector/SKILL.md\n create mode 100644 .pi/skills/project-verifier/SKILL.md\n create mode 100644 AGENTS.md\n create mode 100644 SYSTEM.md\n create mode 100644 block3/README.md\n create mode 100644 fixtures/agentic-target-sample/README.md\n create mode 100644 fixtures/agentic-target-sample/components/Header.vue\n create mode 100644 fixtures/agentic-target-sample/composables/useExample.ts\n create mode 100644 fixtures/agentic-target-sample/nuxt.config.ts\n create mode 100644 fixtures/agentic-target-sample/package.json\n create mode 100644 fixtures/agentic-target-sample/pages/about.vue\n create mode 100644 fixtures/agentic-target-sample/pages/index.vue\n\ndiff --git a/.pi/extensions/inspect-verify.ts b/.pi/extensions/inspect-verify.ts\nnew file mode 100644\nindex 0000000..9105826\n--- /dev/null\n+++ b/.pi/extensions/inspect-verify.ts\n@@ -0,0 +1,111 @@\n+/**\n+ * inspect-verify \u2014 Block 3 Pi extension\n+ *\n+ * Implements ARCH-A (sequential pipeline) on top of `project-inspector` and\n+ * `project-verifier` skills. Two invocation paths, each with a different\n+ * pedagogical purpose:\n+ *\n+ *   1. `/audit ` \u2014 explicit slash command. Injects a single coordinated\n+ *      prompt that asks the agent to run inspector then verifier in one turn.\n+ *      Works in BOTH interactive and non-interactive (-p / --print) modes.\n+ *      This is the primary, reliable path attendees install and use.\n+ *\n+ *   2. `agent_end` listener \u2014 when a turn ends and the output looks like a\n+ *      project-inspector structural briefing (JSON with `\"architecture\"` and\n+ *      `\"entry_points\"`), the extension calls `sendUserMessage` to queue a\n+ *      verifier follow-up. Works in INTERACTIVE mode only \u2014 `-p` mode exits\n+ *      after the first `agent_end` and ignores queued messages. The ambient\n+ *      lesson: once the pattern is wired, the system catches itself without\n+ *      the user remembering to invoke the verifier by name.\n+ *\n+ * Pedagogical thesis: a working engineer composes skills into self-checking\n+ * systems instead of running each skill by hand. Inspector finds architecture;\n+ * Verifier flags supply-chain risk; the extension wires them together. No\n+ * single skill catches everything \u2014 that's why we compose.\n+ */\n+\n+import type {\n+  AgentMessage,\n+  ExtensionAPI,\n+} from \"@earendil-works/pi-coding-agent\";\n+\n+const VERIFIER_FOLLOWUP_PROMPT =\n+  \"The previous response looks like a project-inspector structural briefing. \" +\n+  \"Now run the project-verifier skill on the same target. Read the \" +\n+  \"dependency manifest (package.json, pyproject.toml, go.mod, etc.) of the \" +\n+  \"repository you just inspected, identify pinned exact versions, and use web \" +\n+  \"search to look up known CVE / GHSA advisories per pinned version. Emit the \" +\n+  \"verifier's JSON report \u2014 do not produce another structural briefing.\";\n+\n+const AUDIT_COMMAND_PROMPT = (target: string) =>\n+  `Audit the repository at \\`${target}\\`. ` +\n+  `Step 1 \u2014 run the project-inspector skill: produce a structural briefing in the inspector's JSON shape. ` +\n+  `Step 2 \u2014 run the project-verifier skill on the same target: read the dependency manifest, identify pinned versions, look up CVE / GHSA advisories per pinned version, emit the verifier's JSON shape. ` +\n+  `Return both JSON outputs in order, separated by a \"---\" line.`;\n+\n+/**\n+ * Extract plain text from an assistant message's content blocks.\n+ * AssistantMessage.content is (TextContent | ThinkingContent | ToolCall)[].\n+ */\n+function assistantText(message: AgentMessage): string {\n+  if (message.role !== \"assistant\") return \"\";\n+  const content = message.content;\n+  if (typeof content === \"string\") return content;\n+  if (!Array.isArray(content)) return \"\";\n+  return content\n+    .filter((block: any) => block && block.type === \"text\")\n+    .map((block: any) => (typeof block.text === \"string\" ? block.text : \"\"))\n+    .join(\"\\n\");\n+}\n+\n+/**\n+ * Heuristic: does the text look like a project-inspector output?\n+ * Matches the inspector's documented JSON schema.\n+ */\n+function looksLikeInspectorBriefing(text: string): boolean {\n+  return (\n+    text.includes('\"architecture\"') &&\n+    text.includes('\"entry_points\"') &&\n+    // Quick exclusion: don't re-fire on verifier output\n+    !text.includes('\"lens\"') &&\n+    !text.includes('\"findings\"') &&\n+    !text.includes('\"missed_by_structural_briefing\"')\n+  );\n+}\n+\n+export default function (pi: ExtensionAPI) {\n+  // De-dupe: only fire the verifier once per distinct inspector output within\n+  // a single session. The fingerprint is the first ~200 chars of the output;\n+  // good enough for one session's worth of turns.\n+  const firedFingerprints = new Set();\n+\n+  pi.on(\"agent_end\", async (event) => {\n+    const lastAssistant = [...event.messages]\n+      .reverse()\n+      .find((m: AgentMessage) => m.role === \"assistant\");\n+    if (!lastAssistant) return;\n+\n+    const text = assistantText(lastAssistant);\n+    if (!looksLikeInspectorBriefing(text)) return;\n+\n+    const fingerprint = text.slice(0, 200);\n+    if (firedFingerprints.has(fingerprint)) return;\n+    firedFingerprints.add(fingerprint);\n+\n+    // Inject the verifier follow-up. `deliverAs: \"followUp\"` queues this for\n+    // the next turn so it doesn't fight an in-flight stream.\n+    pi.sendUserMessage(VERIFIER_FOLLOWUP_PROMPT, { deliverAs: \"followUp\" });\n+  });\n+\n+  // Explicit, loop-safe path: `/audit ` triggers inspector + verifier\n+  // in a single coordinated prompt. Useful when the auto-detect heuristic\n+  // misses or when the user wants the pipeline by name.\n+  pi.registerCommand(\"audit\", {\n+    description:\n+      \"Run project-inspector then project-verifier on the given repository path.\",\n+    handler: async (args, _ctx) => {\n+      const target = args.trim() || \".\";\n+      pi.sendUserMessage(AUDIT_COMMAND_PROMPT(target));\n+    },\n+  });\n+}\ndiff --git a/.pi/skills/architecture-verifier/SKILL.md b/.pi/skills/architecture-verifier/SKILL.md\nnew file mode 100644\nindex 0000000..713a636\n--- /dev/null\n+++ b/.pi/skills/architecture-verifier/SKILL.md\n@@ -0,0 +1,54 @@\n+---\n+name: architecture-verifier\n+description: Audit a codebase against architectural and structural quality concerns that a feature-focused briefing misses. Trigger when the user asks for an architecture review, structural critique, design audit, or wants to verify a project briefing against design-quality concerns.\n+---\n+\n+# Architecture Verifier\n+\n+You are a staff-level architect reviewing a codebase for structural and design-quality concerns that a feature-focused inspector typically misses. Apply the **architecture lens**: coupling, layering, module boundaries, naming consistency, separation of concerns, and the structural debt that compounds as a system grows.\n+\n+## When you run\n+\n+You run alongside other verifiers (security, performance) as part of a multi-lens audit composed by a deliberator agent. Your output is one slice of a composed verification report.\n+\n+You may also run standalone when a user asks to architecturally review a codebase.\n+\n+## Process\n+\n+1. **Map the module boundaries.** Identify directories that represent layers (e.g., `pages/` vs `components/` vs `composables/` vs `server/`). Note whether boundaries are respected or whether code crosses them inappropriately.\n+2. **Check coupling.** Sample a few entry points; trace their imports. Note tight coupling, circular references, or modules that \"know too much\" about their callers.\n+3. **Naming + conventions.** Check whether names communicate purpose at the file, function, and module level. Flag inconsistencies (e.g., camelCase mixed with kebab-case in similar-purpose files).\n+4. **Missing abstractions.** Look for repeated patterns that should be extracted (3+ near-duplicate handlers, recurring fetch-then-transform shapes, etc.).\n+5. **Premature abstractions.** Look for the inverse: indirection that doesn't earn its keep \u2014 single-impl interfaces, factories that wrap one constructor, config layers nobody configures.\n+6. **Test architecture.** If tests exist, note whether they exercise behavior or implementation. If they don't, flag the absence as architectural risk.\n+7. **Score severity.** For each finding: severity (critical / high / moderate / low), one-sentence description, one-sentence recommendation.\n+\n+## Output format\n+\n+Return **only** valid JSON in the following shape \u2014 no prose before or after the JSON block:\n+\n+```json\n+{\n+  \"verified\": false,\n+  \"target\": \"\",\n+  \"lens\": \"architecture\",\n+  \"findings\": [\n+    {\n+      \"concern\": \"\",\n+      \"severity\": \"critical | high | moderate | low\",\n+      \"summary\": \"\",\n+      \"recommendation\": \"\"\n+    }\n+  ],\n+  \"recommendation\": \"<2\u20133 sentence summary of architectural posture>\"\n+}\n+```\n+\n+Set `verified: true` only when there are zero findings of severity `high` or `critical`.\n+\n+## Constraints\n+\n+- **Be specific.** Generic findings (\"could be more modular\") help no one. Cite file paths or directory names.\n+- **Honest scoping.** A 7-file fixture has architectural choices but not architectural problems at scale. Don't manufacture findings to look thorough. If the project is genuinely clean, say so.\n+- **One lens only.** This skill is architecture-focused. Don't comment on security, performance, dependencies, or test coverage outside the architecture-relevant slice. The composed audit covers those concerns through other verifiers.\n+- **No fabrication.** Only reference patterns you can verify by reading the code.\ndiff --git a/.pi/skills/performance-verifier/SKILL.md b/.pi/skills/performance-verifier/SKILL.md\nnew file mode 100644\nindex 0000000..75b6389\n--- /dev/null\n+++ b/.pi/skills/performance-verifier/SKILL.md\n@@ -0,0 +1,53 @@\n+---\n+name: performance-verifier\n+description: Audit a codebase for performance and bundle-hygiene concerns that a structural briefing does not surface. Trigger when the user asks for a performance review, bundle audit, runtime cost analysis, or wants to verify a project briefing against build/runtime performance concerns.\n+---\n+\n+# Performance Verifier\n+\n+You are a senior engineer reviewing a codebase for performance and bundle-hygiene concerns that a structural inspector typically misses. Apply the **performance lens**: bundle weight, dependency cost, runtime hot paths, render efficiency in framework code (Vue/Nuxt/React), and the operational performance debt that compounds in production.\n+\n+## When you run\n+\n+You run alongside other verifiers (security, architecture) as part of a multi-lens audit composed by a deliberator agent. Your output is one slice of a composed verification report.\n+\n+You may also run standalone when a user asks to performance-review a codebase.\n+\n+## Process\n+\n+1. **Read the dependency manifest.** Identify heavyweight deps (Lodash full import, Moment, large UI libs, AWS SDK monoliths). Note tree-shakable vs not.\n+2. **Check the bundler config.** For Vite / webpack / Nuxt / Next, look for: missing code-splitting boundaries, large `manualChunks` opportunities missed, source maps shipped to production, devtools left enabled.\n+3. **Sample a hot path.** For a framework like Nuxt/Vue, inspect a representative page. Look for: synchronous waterfalls in `setup()`, unbounded `watch` chains, unkeyed `v-for` over large arrays, deep reactivity where shallow would do.\n+4. **Asset hygiene.** Note images > 200KB, unbounded fonts, CDN-vs-local mismatches in obvious places.\n+5. **Build-time cost.** Note signals of slow builds: large `tsconfig` includes, missing `paths` aliases, `node_modules` directly imported from source.\n+6. **Score severity.** For each finding: severity (critical / high / moderate / low), one-sentence description, one-sentence recommendation.\n+\n+## Output format\n+\n+Return **only** valid JSON in the following shape \u2014 no prose before or after the JSON block:\n+\n+```json\n+{\n+  \"verified\": false,\n+  \"target\": \"\",\n+  \"lens\": \"performance\",\n+  \"findings\": [\n+    {\n+      \"concern\": \"\",\n+      \"severity\": \"critical | high | moderate | low\",\n+      \"summary\": \"\",\n+      \"recommendation\": \"\"\n+    }\n+  ],\n+  \"recommendation\": \"<2\u20133 sentence summary of performance posture>\"\n+}\n+```\n+\n+Set `verified: true` only when there are zero findings of severity `high` or `critical`.\n+\n+## Constraints\n+\n+- **Be quantitative when possible.** \"Lodash full import\" \u2192 cite the file. \"Large asset\" \u2192 estimate the kB. Vague findings degrade the audit.\n+- **Workshop-fixture awareness.** Small fixtures (<10 files) won't have many real performance findings. Don't manufacture issues to look thorough \u2014 say the project is performance-clean if it is.\n+- **One lens only.** Performance-focused. Don't comment on security, architecture, dependencies' CVEs, or test coverage outside the performance-relevant slice.\n+- **No fabrication.** Only reference patterns you can verify by reading the code.\ndiff --git a/.pi/skills/project-inspector/SKILL.md b/.pi/skills/project-inspector/SKILL.md\nnew file mode 100644\nindex 0000000..044a595\n--- /dev/null\n+++ b/.pi/skills/project-inspector/SKILL.md\n@@ -0,0 +1,53 @@\n+---\n+name: project-inspector\n+description: Inspect any code repository and produce a structured architectural briefing. Trigger whenever the user asks to understand, summarize, onboard to, get a briefing on, or describe a codebase, even if they do not literally say \"inspect.\" Outputs valid JSON with architecture, entry_points, data_flow, key_dependencies, and test_patterns fields.\n+---\n+\n+# Project Inspector\n+\n+You are a senior software engineer onboarding to a new project. Your job is to produce a structured, factual briefing of the codebase you're shown so that another senior engineer can navigate it cold.\n+\n+## Process (think step-by-step)\n+\n+1. **Scan the directory structure.** Note the top-level layout, any monorepo or workspace boundaries, and any unusual organization.\n+2. **Identify the framework.** Read `package.json`, `pyproject.toml`, `go.mod`, or equivalent. Note the runtime, the framework, and the major libraries. If multiple frameworks are present, report them all.\n+3. **Locate the entry points.** Identify where execution begins \u2014 main file(s), route registration, top-level components. List at least three when present.\n+4. **Trace data flow.** For the most prominent entry point, follow the imports and call paths far enough to understand how a single request or invocation moves through the code.\n+5. **Note test patterns.** Identify the test framework, where tests live, and a representative example. If tests are missing, say so.\n+6. **Summarize.** Produce the structured output below.\n+\n+## Output format\n+\n+Return **only** valid JSON in the following shape \u2014 no prose before or after the JSON block:\n+\n+```json\n+{\n+  \"architecture\": \"<2\u20134 sentence summary of the overall shape and framework>\",\n+  \"entry_points\": [\"\", \"\", \"\"],\n+  \"data_flow\": \"<2\u20133 sentence trace of how a request/invocation moves through the most prominent entry point>\",\n+  \"key_dependencies\": [\"\", \"\", \"...\"],\n+  \"test_patterns\": \"<1\u20132 sentence note on test framework, location, conventions; or 'No tests detected.'>\"\n+}\n+```\n+\n+## Example\n+\n+For a small Express app:\n+\n+```json\n+{\n+  \"architecture\": \"Node.js HTTP service built on Express 4. Single-package layout with handler functions in src/routes/, business logic in src/services/, and a thin server.ts entry point.\",\n+  \"entry_points\": [\"src/server.ts\", \"src/routes/index.ts\", \"src/routes/users.ts\"],\n+  \"data_flow\": \"HTTP request enters src/server.ts which mounts route handlers from src/routes/. Each route handler validates input and delegates to a service in src/services/. Services use a shared db client from src/db.ts.\",\n+  \"key_dependencies\": [\"express\", \"zod\", \"pg\", \"pino\"],\n+  \"test_patterns\": \"Vitest tests colocated next to source files as *.test.ts. One example: src/services/users.test.ts.\"\n+}\n+```\n+\n+## Constraints\n+\n+- **Never invent file paths.** Only reference files you can observe in the input. If a path is unclear, omit it rather than guess.\n+- **Never echo secrets.** If the codebase contains API keys, access tokens, AWS credentials, or other secret-shaped values (e.g., strings matching `sk-`, `AKIA`, JWT shapes), **do not include those values in your output**. Note that secrets are present but redact the values themselves.\n+- **Be honest about ambiguity.** If the framework is unclear (e.g., a Vite + React project with no meta-framework), report exactly what you see. Do not assert a framework that isn't there.\n+- **If the input is not a codebase** \u2014 e.g., the user asks an unrelated question \u2014 refuse politely and ask for a codebase to inspect. Do not produce a briefing for non-repo input.\n+- **If the codebase is empty or too small to analyze meaningfully**, return the JSON with appropriate fields noting the limitation rather than fabricating content.\ndiff --git a/.pi/skills/project-verifier/SKILL.md b/.pi/skills/project-verifier/SKILL.md\nnew file mode 100644\nindex 0000000..6d5a780\n--- /dev/null\n+++ b/.pi/skills/project-verifier/SKILL.md\n@@ -0,0 +1,89 @@\n+---\n+name: project-verifier\n+description: Audit a codebase against the security and supply-chain risks that a structural briefing misses. Trigger whenever the user asks to verify, audit, double-check, or second-opinion a project briefing, or asks about CVEs, vulnerable dependencies, security posture, or supply-chain risk in a repo. Especially trigger when a project-inspector briefing has just been produced.\n+---\n+\n+# Project Verifier\n+\n+You are a security-aware verifier auditing a codebase against risks that a structural briefing does not cover. Your job is to apply a **different lens** to the same input the structural inspector saw \u2014 the lens of pinned versions, known advisories, and supply-chain risk \u2014 and produce a verification report that flags what the structural briefing missed.\n+\n+## When you run\n+\n+You run after a structural inspector (e.g., `project-inspector`) has produced an architectural briefing of a target repository. Your input is the target repository path. Your output is a verification report.\n+\n+You may also run standalone when a user asks to audit a repository for security issues.\n+\n+## Process (think step-by-step)\n+\n+1. **Locate the dependency manifest.** Read `package.json`, `pyproject.toml`, `go.mod`, `Cargo.toml`, or equivalent from the target repo. If none is found, report that and exit.\n+2. **Extract pinned versions.** For each declared dependency, record its name and its version constraint. Note which are pinned to **exact** versions (no `^`, `~`, or range operators) vs. which are floating.\n+3. **Look up known advisories.** For each pinned dependency, use web search / web grounding to look up known CVE advisories, security bulletins, or GitHub Security Advisories (GHSA) for that exact version. Prefer authoritative sources: NVD, GitHub Security Advisories, npm advisory database, Snyk vuln DB.\n+4. **Cross-reference with `npm audit`** when available. If the target repo has a `package-lock.json` or you can run `npm audit --package-lock-only --json` against it, capture that output and reconcile against your web-grounded findings.\n+5. **Score severity.** For each finding, capture: package name, pinned version, CVE/GHSA ID, severity (critical/high/moderate/low), one-sentence summary, and a remediation hint (typically: the patched version range).\n+6. **Disagreement check.** If a structural-briefing input is provided (e.g., the output of `project-inspector`), explicitly note which of your findings the structural briefing did NOT mention. This is the verifier's primary value \u2014 surfacing what the prior agent missed.\n+7. **Emit the report.**\n+\n+## Output format\n+\n+Return **only** valid JSON in the following shape \u2014 no prose before or after the JSON block:\n+\n+```json\n+{\n+  \"verified\": false,\n+  \"target\": \"\",\n+  \"lens\": \"security / supply-chain\",\n+  \"manifest\": \"\",\n+  \"findings\": [\n+    {\n+      \"package\": \"\",\n+      \"pinned\": \"\",\n+      \"advisory\": \"\",\n+      \"severity\": \"critical | high | moderate | low\",\n+      \"summary\": \"\",\n+      \"remediation\": \"\"\n+    }\n+  ],\n+  \"missed_by_structural_briefing\": [\"\", \"...\"],\n+  \"recommendation\": \"<2\u20133 sentence summary of risk posture and what to do next>\"\n+}\n+```\n+\n+Set `verified: true` only when there are zero findings of severity `high` or `critical`. Otherwise `verified: false`.\n+\n+## Example output (illustrative)\n+\n+```json\n+{\n+  \"verified\": false,\n+  \"target\": \"fixtures/agentic-target-sample/\",\n+  \"lens\": \"security / supply-chain\",\n+  \"manifest\": \"fixtures/agentic-target-sample/package.json\",\n+  \"findings\": [\n+    {\n+      \"package\": \"axios\",\n+      \"pinned\": \"0.21.0\",\n+      \"advisory\": \"CVE-2020-28168\",\n+      \"severity\": \"high\",\n+      \"summary\": \"Server-Side Request Forgery via maliciously-crafted URLs in axios <0.21.1.\",\n+      \"remediation\": \"Upgrade to axios >=0.21.1\"\n+    }\n+  ],\n+  \"missed_by_structural_briefing\": [\"axios\", \"lodash\", \"minimist\", \"serialize-javascript\"],\n+  \"recommendation\": \"Four pinned dependencies have public high/critical advisories. The structural briefing identified the package names but did not flag the version-bound security exposure. Upgrade or pin to the indicated remediation ranges before shipping.\"\n+}\n+```\n+\n+## Constraints\n+\n+- **Never fabricate CVEs.** If you cannot find a verifiable advisory for a pinned version, omit it rather than guess. It is better to under-report than to fabricate.\n+- **Cite the advisory ID.** Every finding must reference a real, lookup-able advisory ID (CVE or GHSA). If no ID is available, do not include the finding.\n+- **Pinned-exact-versions are the focus.** Range-constrained deps (`^1.2.3`, `~4.5.6`) are usually resolved to the latest patched version by the package manager; report them only if the explicitly-allowed range includes vulnerable versions and there's no patched version within range.\n+- **Be honest about limits.** If your web search is rate-limited, unavailable, or returns inconclusive results for a pinned version, say so in the recommendation field rather than asserting \"no findings.\"\n+- **Do not echo secrets.** If the dependency manifest or related files contain API keys, tokens, or credentials, do not include those values in your output. This skill audits dependencies, not secret-handling.\n+- **Do not modify the target repo.** This skill is read-only with respect to the target.\n+\n+## Composition note (for the workshop)\n+\n+This skill is half of a composed pipeline. The other half is `project-inspector`, which produces a structural briefing. Run them together \u2014 either by chaining manually (`/inspect`, then `/verify`) or via the `inspect-verify` extension (`.pi/extensions/inspect-verify.ts`), which triggers this skill automatically after an inspector run.\n+\n+The pedagogical point: *no single skill catches everything.* The Inspector's spec doesn't ask for security posture. The Verifier's spec doesn't ask for architecture. Composed, they cover what either alone would miss. That's agentic engineering at the workflow altitude.\ndiff --git a/AGENTS.md b/AGENTS.md\nnew file mode 100644\nindex 0000000..9494243\n--- /dev/null\n+++ b/AGENTS.md\n@@ -0,0 +1,47 @@\n+# AGENTS.md \u2014 AI Engineering Workshop\n+\n+> Project instructions loaded automatically by Pi (`pi.dev`) at session start. Pi reads `AGENTS.md` from `~/.pi/agent/`, every parent directory of the cwd, and the cwd itself \u2014 and concatenates them in that order. This file is the **project-local layer**: everything specific to this workshop repo lives here.\n+\n+## What this repo is\n+\n+Workshop materials for *AI Engineering: From Prompt Architecture to Production Infrastructure* \u2014 VueConf US 2026, Atlanta, 2026-05-19. Four blocks (see [README.md](README.md)). Block 3 is the Pi / agentic-engineering block; the `.pi/` directory below holds its skills + extensions.\n+\n+## Where things live\n+\n+| Path | What |\n+|------|------|\n+| `.pi/skills/project-inspector/` | Block 2 artifact, ported into Pi for Block 3 |\n+| `.pi/skills/project-verifier/` | Block 3 security/CVE lens \u2014 primary lab skill |\n+| `.pi/skills/architecture-verifier/` | Block 3 showcase stub (architectural critique lens) |\n+| `.pi/skills/performance-verifier/` | Block 3 showcase stub (performance/bundle lens) |\n+| `.pi/extensions/inspect-verify.ts` | Block 3 extension \u2014 wires inspector \u2192 verifier; registers `/audit` |\n+| `fixtures/agentic-target-sample/` | Block 3 dramatic-failure target \u2014 Nuxt-shaped, vulnerable deps planted |\n+| `fixtures/{nuxt,monorepo,vite-react,leaky-secret}-sample/` | Block 2 eval fixtures |\n+| `prompts/project-inspector-v5.txt` | Canonical Block 1 fallback prompt |\n+| `evals/` | Block 2 eval suite (with planted non-discriminating assertion) |\n+| `bifrost/`, `nuxt-app/` | Block 4 infrastructure + Vue/Nuxt integration target |\n+\n+## Conventions when operating in this repo\n+\n+- **Skills are the unit of agent capability.** A new lens (security / architecture / performance / etc.) lives as a new skill under `.pi/skills//`. Don't bury new behavior in extension code if it could be a skill \u2014 extensions wire skills; skills implement reasoning.\n+- **Extensions wire, skills reason.** Extensions hook into events and dispatch; they don't contain prompt logic. If you find yourself writing a prompt inside an extension, that's a skill in disguise.\n+- **One JSON shape per verifier.** All verifier skills (`*-verifier`) emit `{verified, target, lens, findings[], recommendation}`. Don't drift the envelope \u2014 the deliberator pattern in Block 3's showcase relies on consistent shape.\n+- **Never echo secrets.** This repo contains `fixtures/leaky-secret-sample/` with planted fake API keys for Block 2 adversarial testing. They are documented test patterns (`sk-test-*`, `AKIAEXAMPLE*`) but no skill should reproduce them in output regardless.\n+- **Honest scoping.** On the small workshop fixtures (\u226410 files each), don't manufacture findings to look thorough. A clean lens is a valid result.\n+\n+## What NOT to load into context\n+\n+Pi auto-discovers skills and extensions. Be deliberate about what runs:\n+\n+- `node_modules/`, `.nuxt/`, `.output/` \u2014 generated; never load\n+- `bifrost/data/` (if present at workshop time) \u2014 runtime state; never load\n+- `nuxt-app/` during Block 3 \u2014 out of scope; loading it inflates context unnecessarily\n+- Session history under `~/.pi/agent/sessions/` \u2014 Pi manages this; don't reference\n+\n+If running `--tools read,bash,grep,find,ls` (the typical Block 3 toolset), the `find` / `grep` defaults will naturally skip these \u2014 but if you broaden tools, add explicit exclusions.\n+\n+## Workshop-day operational notes\n+\n+- **Default provider:** `pi` defaults to Google (Gemini). Gemini's web grounding is what makes the security-CVE lookup in `project-verifier` work without extra wiring.\n+- **Print mode (`-p`) caveat:** `--print` exits after one `agent_end`. The extension's auto-fire on `agent_end` only lights up in interactive mode. The `/audit` slash command works in both modes \u2014 use it when scripting.\n+- **Pre-staged extensions:** `.pi/extensions/inspect-verify.ts` is auto-loaded by Pi when run from the repo root. Override with `-e ` if loading from elsewhere.\ndiff --git a/README.md b/README.md\nindex 8d69258..d4d1d49 100644\n--- a/README.md\n+++ b/README.md\n@@ -12,7 +12,7 @@ Workshop materials for four blocks of hands-on AI engineering:\n |---|---|---|\n | **1** | Foundations | Write a v5 prompt for the Project Inspector running example |\n | **2** | Build & Eval a Skill | Promote the prompt to a working skill via the `skill-creator` plugin; run the eval loop; learn to *evaluate the eval* |\n-| **3** | Vibe Coding \u2192 Agentic Engineering | (Instructor's separate materials) |\n+| **3** | Vibe Coding \u2192 Agentic Engineering | Port your Block 2 skill into Pi; compose it with a verifier skill and a hook extension; watch the system catch what one skill alone misses |\n | **4** | AI Gateway (Production) | Configure Bifrost; tour the production-gateway surface; integrate with a Vue/Nuxt app |\n \n ## Quick start\n@@ -34,17 +34,26 @@ See the [Prerequisites](#) (handed out separately). Minimum:\n - Two LLM provider API keys with $5+ credit each (Anthropic + OpenAI recommended)\n - An AI coding CLI installed (Claude Code, Codex CLI, or Gemini CLI)\n - The `skill-creator` plugin installed via the Anthropic plugin marketplace\n+- **Pi installed** (`pi.dev`) \u2014 `bun install -g @earendil-works/pi-coding-agent`, then verify `pi --version` returns cleanly. (Block 3 runtime.)\n+- **A second CLI for verification** \u2014 Gemini CLI authenticated against your Google account (primary) or Codex CLI against your OpenAI key (alternative). Used by Block 3's verifier skill.\n \n ## Repository layout\n \n ```\n ai-engineering-workshop/\n+\u251c\u2500\u2500 AGENTS.md                   # Block 3: project instructions loaded by Pi at session start\n+\u251c\u2500\u2500 SYSTEM.md                   # Block 3: per-project system-prompt append\n \u251c\u2500\u2500 skills/project-inspector/   # Block 2: your skill goes here (stub provided)\n+\u251c\u2500\u2500 .pi/                        # Block 3: Pi-specific resources\n+\u2502   \u251c\u2500\u2500 skills/                 #   ported inspector + verifier skills (security / arch / perf)\n+\u2502   \u2514\u2500\u2500 extensions/             #   inspect-verify.ts \u2014 auto-fires verifier after inspector\n \u251c\u2500\u2500 prompts/                    # Block 1: prompt-evolution reference (v0 baseline, v5 canonical fallback)\n \u251c\u2500\u2500 evals/                      # Block 2: eval suite\n \u2502   \u251c\u2500\u2500 evals.json              # 5 test cases with planted pathology (see Block 2 spec)\n \u2502   \u2514\u2500\u2500 trigger-eval.json       # 20 queries for the description optimizer\n-\u251c\u2500\u2500 fixtures/                   # Block 2: test inputs (Nuxt, monorepo, Vite+React, leaky-secret)\n+\u251c\u2500\u2500 fixtures/                   # Block 2 + 3: test inputs\n+\u2502   \u2514\u2500\u2500 agentic-target-sample/  # Block 3: Nuxt-shaped fixture with planted vulnerable deps\n+\u251c\u2500\u2500 block3/                     # Block 3: instructor notes, narration script, attendee walkthrough\n \u251c\u2500\u2500 nuxt-app/                   # Block 4.9: Vue/Nuxt integration target\n \u251c\u2500\u2500 bifrost/                    # Block 4: Bifrost config (with semantic_cache plugin)\n \u2514\u2500\u2500 scripts/                    # Helper one-liners (cache demo, test prompts)\n@@ -58,6 +67,9 @@ Open `prompts/project-inspector-v0.txt` and walk it through the 5-layer enhancem\n **Block 2 \u2014 Build & Eval a Skill (morning, after break)**\n Open `skills/project-inspector/SKILL.md`. Paste your v5 from Block 1. Then run the `skill-creator` plugin against the `evals/` and `fixtures/` directories. The plugin will spawn parallel with-skill and baseline runs, grade them, and open a viewer. **Watch the Benchmark tab.** Something's planted in case 0 \u2014 the analyzer pass will tell you what.\n \n+**Block 3 \u2014 Vibe Coding \u2192 Agentic Engineering (afternoon, post-lunch)**\n+Copy your Block 2 skill into `.pi/skills/project-inspector/`. Launch `pi` from the repo root and inspect `fixtures/agentic-target-sample/`. The inspector will produce a clean Nuxt-3 briefing \u2014 and confidently miss something. We'll find the lie together, install the verifier skill, wire the `.pi/extensions/inspect-verify.ts` hook so the verifier fires automatically, and finish with the `AGENTS.md` / `SYSTEM.md` hygiene primitives. Attendee-facing walkthrough lives at [`block3/README.md`](block3/README.md).\n+\n **Block 4 \u2014 AI Gateway (afternoon)**\n Boot Bifrost: `npm run bifrost`. Configure providers, models, a Virtual Key, a budget, a routing rule, and the semantic cache. Then `cd nuxt-app && npm install && npm run dev` and wire the Vue app to your gateway.\n \ndiff --git a/SYSTEM.md b/SYSTEM.md\nnew file mode 100644\nindex 0000000..ad712c3\n--- /dev/null\n+++ b/SYSTEM.md\n@@ -0,0 +1,11 @@\n+# SYSTEM.md \u2014 AI Engineering Workshop\n+\n+> Optional per-project system-prompt **append** for Pi. When this file is present in the cwd, Pi appends its contents to the default system prompt. Use it for project-specific framing that should shape every response in this repo.\n+\n+You are operating inside the **AI Engineering: From Prompt Architecture to Production Infrastructure** workshop repository for VueConf US 2026. The user is either an instructor preparing the workshop or an attendee mid-workshop. Optimize for clarity and pedagogical honesty over polish:\n+\n+- **When a skill is invoked, run the skill faithfully and emit its declared output shape.** Verifier skills (`project-verifier`, `architecture-verifier`, `performance-verifier`) emit JSON only \u2014 no preamble, no postscript.\n+- **When composing skills (e.g., via `/audit`), run them in declared order and present each output verbatim.** Don't summarize a verifier's JSON into prose; the JSON itself is the deliverable.\n+- **Honest scoping over performative thoroughness.** A clean verifier result (`verified: true`, empty findings) is a valid and pedagogically valuable output on this repo's small fixtures. Don't manufacture concerns to look diligent.\n+- **Cite, never fabricate, advisories.** When the `project-verifier` skill is invoked, every reported CVE/GHSA must be a real, lookup-able advisory ID. If an advisory cannot be verified for a pinned version, omit it rather than guess.\n+- **Skill boundaries are pedagogical, not legal.** If an attendee asks you to do something outside the declared scope of a skill, do it \u2014 but in your role as a general agent, not as the skill. Note the role shift briefly so attendees see the boundary working.\ndiff --git a/block3/README.md b/block3/README.md\nnew file mode 100644\nindex 0000000..08dafd2\n--- /dev/null\n+++ b/block3/README.md\n@@ -0,0 +1,57 @@\n+# Block 3 \u2014 Vibe Coding \u2192 Agentic Engineering\n+\n+Attendee walkthrough for the Block 3 afternoon slot (1:00 \u2013 2:30 PM, 90 min).\n+\n+> **Thesis:** How working engineers move from vibe coding to agentic engineering. Same skill, new altitude.\n+\n+## What you'll do\n+\n+1. **Port** your Block 2 Project Inspector skill into Pi\n+2. **Run** it against a Nuxt-shaped fixture and see it produce a confidently-incomplete answer\n+3. **Install** a verifier skill that applies a different lens (security / supply-chain) to the same input\n+4. **Wire** a Pi extension (`.ts`) that auto-fires the verifier after the inspector finishes \u2014 and register a `/audit` slash command as the explicit, reliable alternative\n+5. **Drop in** `AGENTS.md` and `SYSTEM.md` \u2014 Pi's project-scoped hygiene primitives\n+6. **Watch** the multi-lens showcase: three verifiers in parallel, a deliberator merging findings\n+\n+## Prereqs (verify before lunch)\n+\n+- Pi installed: `pi --version` returns cleanly\n+- A second CLI for verification: Gemini CLI authed against Google, OR Codex CLI authed against your OpenAI key\n+\n+If either prereq is missing, raise your hand during the lunch break \u2014 five minutes of setup is faster than fifteen minutes of debugging during the lab.\n+\n+## Files you'll touch\n+\n+| Path | What |\n+|------|------|\n+| `.pi/skills/project-inspector/SKILL.md` | Where you copy your Block 2 skill |\n+| `.pi/skills/project-verifier/SKILL.md` | Pre-staged \u2014 the security/CVE lens |\n+| `.pi/extensions/inspect-verify.ts` | Pre-staged \u2014 the hook + slash command |\n+| `fixtures/agentic-target-sample/` | The Nuxt-shaped target with the planted failure |\n+| `AGENTS.md`, `SYSTEM.md` | Pre-staged at repo root \u2014 project-scoped Pi config |\n+\n+## The 90-minute shape\n+\n+| Time | Beat | Mode |\n+|------|------|------|\n+| 1:00 \u2013 1:05 | Frame | Mirrored |\n+| 1:05 \u2013 1:25 | Port Project Inspector into Pi | YOUR TURN |\n+| 1:25 \u2013 1:30 | The failure \u2014 what the briefing doesn't say | Mirrored |\n+| 1:30 \u2013 1:50 | Verifier agent enters | Mixed |\n+| 1:50 \u2013 2:05 | Hooks \u2014 Pi extension | Mixed |\n+| 2:05 \u2013 2:15 | Hygiene \u2014 AGENTS.md + SYSTEM.md | Mixed |\n+| 2:15 \u2013 2:23 | Showcase \u2014 pattern extended (3 verifiers + deliberator) | Demo |\n+| 2:23 \u2013 2:27 | Showcase \u2014 roundtable cameo | Demo |\n+| 2:27 \u2013 2:30 | Q&A | Conversation |\n+\n+## What you take home\n+\n+A repo you can use as a template:\n+\n+- One inspector skill + one verifier skill + one extension that wires them\n+- An `AGENTS.md` and `SYSTEM.md` you can adapt for any of your own projects\n+- The composition pattern: *no single skill catches everything; that's why we compose*\n+\n+## What to do Monday\n+\n+Pick one skill from your own work where the output is *technically correct but operationally incomplete* \u2014 and build the verifier that catches what it misses. Same pattern. Same primitives. Different domain.\ndiff --git a/fixtures/agentic-target-sample/README.md b/fixtures/agentic-target-sample/README.md\nnew file mode 100644\nindex 0000000..468efe0\n--- /dev/null\n+++ b/fixtures/agentic-target-sample/README.md\n@@ -0,0 +1,59 @@\n+# agentic-target-sample\n+\n+> \u26a0\ufe0f **Instructor-facing.** Do NOT share this README with attendees pre-workshop. The Block 3 dramatic-failure beat depends on attendees not knowing what's planted.\n+\n+A Nuxt-shaped fixture used as the **Block 3 \"skills can lie\" target.** Structurally identical to `nuxt-sample/`; differs only in `package.json`, which pins a stack of well-documented vulnerable transitive dependencies.\n+\n+## Structure\n+\n+```\n+agentic-target-sample/\n+\u251c\u2500\u2500 package.json         # Nuxt 3 deps + planted vulnerable transitives\n+\u251c\u2500\u2500 nuxt.config.ts       # Nuxt configuration\n+\u251c\u2500\u2500 pages/\n+\u2502   \u251c\u2500\u2500 index.vue\n+\u2502   \u2514\u2500\u2500 about.vue\n+\u251c\u2500\u2500 components/\n+\u2502   \u2514\u2500\u2500 Header.vue\n+\u2514\u2500\u2500 composables/\n+    \u2514\u2500\u2500 useExample.ts\n+```\n+\n+## The planted vulnerabilities\n+\n+| Dep | Pinned | Advisory | Severity |\n+|-----|--------|----------|----------|\n+| `axios` | `0.21.0` | CVE-2020-28168 (SSRF) | High |\n+| `lodash` | `4.17.20` | CVE-2021-23337 (command injection) | High |\n+| `minimist` | `1.2.5` | CVE-2021-44906 (prototype pollution) | Critical |\n+| `serialize-javascript` | `3.0.0` | CVE-2020-7660 (XSS) | High |\n+\n+All advisories are public, stable, and not at risk of expiry. None of the planted versions are runtime-active in the fixture's code \u2014 they exist only as declared dependencies.\n+\n+## What Project Inspector says (the lie)\n+\n+Project Inspector v5 confidently produces a clean Nuxt-3 architectural briefing:\n+\n+- Framework: Nuxt 3\n+- Entry points: `nuxt.config.ts`, `pages/index.vue`, `pages/about.vue`\n+- Data-flow trace through page \u2192 component \u2192 composable\n+- `key_dependencies`: likely lists most or all of `nuxt`, `vue`, `vue-router`, `typescript`, `axios`, `lodash`, `minimist`, `serialize-javascript`\n+\n+**The lie isn't omission \u2014 it's lensing.** Inspector lists the dependency *names* (per its spec) but reports **no version context** and **no security posture**. Its output schema is `[\"\", ...]` \u2014 names only. A reader looking at Inspector's briefing has no signal that four of those deps are pinned at exact versions with public high/critical CVEs.\n+\n+That's the failure mode this fixture exercises: not that v5 is broken, but that v5's spec doesn't ask it to evaluate security posture. The discipline of *agentic engineering* is composing past that limit, not training one skill to do everything.\n+\n+## What Project Verifier catches\n+\n+`.pi/skills/project-verifier/` reads `package.json`, identifies the pinned exact versions, and uses Gemini's web grounding to look up CVE advisories per pinned version. Output flags all four planted vulns with severity and advisory ID.\n+\n+## Why no lockfile\n+\n+The fixture honors the existing fixtures-README size constraint (\u226410 files, \u226420 KB). A real `package-lock.json` for a Nuxt project would blow the budget. The verifier doesn't need one \u2014 it operates on declared versions in `package.json` plus web-grounded CVE lookup, which is the lesson: *a verifier can use a different lens (the web, an external CLI, a different model) to catch what your local-only skill cannot.*\n+\n+## Pre-workshop verification checklist\n+\n+- [ ] Run Project Inspector v5 against this fixture; confirm it produces a clean briefing with no security mentions in \u22659/10 runs\n+- [ ] Run Project Verifier (via Pi + Gemini CLI) against the same fixture; confirm all 4 pinned vulns are flagged in \u22659/10 runs\n+- [ ] Capture before/after screenshots for the slide deck (Inspector output side-by-side with Verifier output)\n+- [ ] Confirm file size remains within fixture conventions (`du -k .`)\ndiff --git a/fixtures/agentic-target-sample/components/Header.vue b/fixtures/agentic-target-sample/components/Header.vue\nnew file mode 100644\nindex 0000000..ce316ba\n--- /dev/null\n+++ b/fixtures/agentic-target-sample/components/Header.vue\n@@ -0,0 +1,16 @@\n+\n+const links = [\n+  { to: '/', label: 'Home' },\n+  { to: '/about', label: 'About' },\n+]\n+\n+\n+\n+  \n\n+    \n\n+      \n+        {{ link.label }}\n+      \n+    \n+  \n+\ndiff --git a/fixtures/agentic-target-sample/composables/useExample.ts b/fixtures/agentic-target-sample/composables/useExample.ts\nnew file mode 100644\nindex 0000000..54ecd8c\n--- /dev/null\n+++ b/fixtures/agentic-target-sample/composables/useExample.ts\n@@ -0,0 +1,4 @@\n+export const useExample = () => {\n+  const greeting = ref('Hello from the Nuxt sample fixture')\n+  return { greeting }\n+}\ndiff --git a/fixtures/agentic-target-sample/nuxt.config.ts b/fixtures/agentic-target-sample/nuxt.config.ts\nnew file mode 100644\nindex 0000000..0b5183f\n--- /dev/null\n+++ b/fixtures/agentic-target-sample/nuxt.config.ts\n@@ -0,0 +1,14 @@\n+// https://nuxt.com/docs/api/configuration/nuxt-config\n+export default defineNuxtConfig({\n+  compatibilityDate: '2026-01-01',\n+  devtools: { enabled: true },\n+  modules: [],\n+  app: {\n+    head: {\n+      title: 'Nuxt Sample',\n+      meta: [\n+        { name: 'description', content: 'A small Nuxt 3 sample app used as a workshop fixture.' },\n+      ],\n+    },\n+  },\n+})\ndiff --git a/fixtures/agentic-target-sample/package.json b/fixtures/agentic-target-sample/package.json\nnew file mode 100644\nindex 0000000..bb34d2e\n--- /dev/null\n+++ b/fixtures/agentic-target-sample/package.json\n@@ -0,0 +1,24 @@\n+{\n+  \"name\": \"agentic-target-sample\",\n+  \"private\": true,\n+  \"type\": \"module\",\n+  \"scripts\": {\n+    \"build\": \"nuxt build\",\n+    \"dev\": \"nuxt dev\",\n+    \"generate\": \"nuxt generate\",\n+    \"preview\": \"nuxt preview\"\n+  },\n+  \"dependencies\": {\n+    \"axios\": \"0.21.0\",\n+    \"lodash\": \"4.17.20\",\n+    \"minimist\": \"1.2.5\",\n+    \"serialize-javascript\": \"3.0.0\"\n+  },\n+  \"devDependencies\": {\n+    \"@nuxt/devtools\": \"latest\",\n+    \"nuxt\": \"^3.13.0\",\n+    \"typescript\": \"^5.5.0\",\n+    \"vue\": \"^3.5.0\",\n+    \"vue-router\": \"^4.4.0\"\n+  }\n+}\ndiff --git a/fixtures/agentic-target-sample/pages/about.vue b/fixtures/agentic-target-sample/pages/about.vue\nnew file mode 100644\nindex 0000000..7be546c\n--- /dev/null\n+++ b/fixtures/agentic-target-sample/pages/about.vue\n@@ -0,0 +1,14 @@\n+\n+useHead({ title: 'About \u2014 Nuxt Sample' })\n+\n+\n+\n+  \n\n+    \n\n+    \n\n+      \nAbout this sample\n+      \nA minimal Nuxt 3 project used as a fixture for the Project Inspector skill.\n+      Home\n+    \n+  \n+\ndiff --git a/fixtures/agentic-target-sample/pages/index.vue b/fixtures/agentic-target-sample/pages/index.vue\nnew file mode 100644\nindex 0000000..a847a1b\n--- /dev/null\n+++ b/fixtures/agentic-target-sample/pages/index.vue\n@@ -0,0 +1,14 @@\n+\n+const { greeting } = useExample()\n+\n+\n+\n+  \n\n+    \n\n+    \n\n+      \n{{ greeting }}\n+      \nThis is the home page of the Nuxt sample fixture.\n+      About\n+    \n+  \n+\n-- \n2.43.0\n\n", "creation_timestamp": "2026-05-19T01:47:50.000000Z"}]}