@su-record/vibe 3.2.64 → 4.0.1

package/skills/vibe.e2e-commerce/templates/test-scenarios.md

@@ -1,170 +0,0 @@
-# E2E Commerce Test Scenario Template
-
-## Setup
-
-```typescript
-// {{TEST_FILE}}.spec.ts
-import { test, expect } from "@playwright/test";
-import { setupServer } from "msw/node";
-import { http, HttpResponse } from "msw";
-
-// Seed test data once per suite — clean up in afterAll
-test.beforeAll(async ({ request }) => {
-  await request.post("/api/test/seed", {
-    data: {
-      product: { id: "{{PRODUCT_ID}}", stock: 10, price: {{PRICE}} },
-      user: { email: "{{TEST_USER_EMAIL}}", password: "{{TEST_USER_PASSWORD}}" },
-      coupon: { code: "{{COUPON_CODE}}", type: "percentage", value: 10 },
-    },
-  });
-});
-
-test.afterAll(async ({ request }) => {
-  await request.post("/api/test/cleanup", { data: { scope: "{{TEST_SUITE_ID}}" } });
-});
-```
-
-## P0 — Happy Path Checkout
-
-```typescript
-test("happy path: cart → checkout → payment → confirmation", async ({ page }) => {
-  // 1. Add to cart
-  await page.goto("/products/{{PRODUCT_SLUG}}");
-  await page.getByRole("button", { name: "Add to Cart" }).click();
-  await page.getByRole("link", { name: "View Cart" }).click();
-
-  // 2. Proceed to checkout
-  await expect(page.getByText("{{PRODUCT_NAME}}")).toBeVisible();
-  await page.getByRole("button", { name: "Checkout" }).click();
-
-  // 3. Fill shipping
-  await page.fill('[name="address"]', "{{TEST_ADDRESS}}");
-  await page.fill('[name="city"]', "{{TEST_CITY}}");
-  await page.getByRole("button", { name: "Continue to Payment" }).click();
-
-  // 4. Pay (use PG sandbox card)
-  await page.fill('[name="cardNumber"]', "{{SANDBOX_CARD_NUMBER}}");
-  await page.fill('[name="expiry"]', "{{SANDBOX_CARD_EXPIRY}}");
-  await page.fill('[name="cvv"]', "{{SANDBOX_CARD_CVV}}");
-  await page.getByRole("button", { name: "Place Order" }).click();
-
-  // 5. Confirm — verify order status text, not just URL
-  await page.waitForURL("**/order-confirmation/**");
-  await expect(page.getByText("Order Confirmed")).toBeVisible();
-  await expect(page.getByTestId("order-id")).not.toBeEmpty();
-});
-```
-
-## P0 — Payment Failure + Stock Release
-
-```typescript
-test("payment failure releases reserved stock", async ({ page, request }) => {
-  const stockBefore = await request
-    .get("/api/products/{{PRODUCT_ID}}/stock")
-    .then((r) => r.json());
-
-  await page.goto("/products/{{PRODUCT_SLUG}}");
-  await page.getByRole("button", { name: "Add to Cart" }).click();
-  await page.goto("/checkout");
-  await page.fill('[name="cardNumber"]', "4000000000000002"); // Decline card
-
-  await page.getByRole("button", { name: "Place Order" }).click();
-  await expect(page.getByText(/payment failed|declined/i)).toBeVisible();
-
-  // Verify stock is released — not just error shown
-  const stockAfter = await request
-    .get("/api/products/{{PRODUCT_ID}}/stock")
-    .then((r) => r.json());
-  expect(stockAfter.available).toBe(stockBefore.available);
-});
-```
-
-## P0 — Duplicate Payment Prevention
-
-```typescript
-test("double-click does not create duplicate order", async ({ page, request }) => {
-  await page.goto("/checkout?prefilled=true");
-  const submitBtn = page.getByRole("button", { name: "Place Order" });
-
-  // Simulate double-click simultaneously
-  await Promise.all([submitBtn.click(), submitBtn.click()]);
-  await page.waitForURL("**/order-confirmation/**");
-
-  const orderId = await page.getByTestId("order-id").textContent();
-
-  // Verify only one order was created via API
-  const orders = await request
-    .get(`/api/orders?reference={{TEST_IDEMPOTENCY_KEY}}`)
-    .then((r) => r.json());
-  expect(orders.total).toBe(1);
-});
-```
-
-## P0 — Out-of-Stock Blocks Checkout
-
-```typescript
-test("out-of-stock product blocks checkout with clear message", async ({ page, request }) => {
-  // Deplete stock via test API
-  await request.post("/api/test/deplete-stock", { data: { productId: "{{PRODUCT_ID}}" } });
-
-  await page.goto("/checkout?prefilled=true");
-  await page.getByRole("button", { name: "Place Order" }).click();
-
-  await expect(page.getByText(/out of stock|unavailable/i)).toBeVisible();
-  await expect(page).not.toHaveURL("**/order-confirmation/**");
-});
-```
-
-## P1 — Coupon Calculation
-
-```typescript
-test("percentage coupon applies correct discount", async ({ page }) => {
-  await page.goto("/cart");
-  await page.fill('[name="couponCode"]', "{{COUPON_CODE}}");
-  await page.getByRole("button", { name: "Apply" }).click();
-
-  const total = await page.getByTestId("cart-total").textContent();
-  // {{PRICE}} * (1 - 0.10) = expected total
-  await expect(page.getByTestId("discount-amount")).toContainText("{{EXPECTED_DISCOUNT}}");
-});
-```
-
-## P1 — Cart Merge on Login
-
-```typescript
-test("guest cart merges into user cart on login", async ({ page }) => {
-  // Add item as guest
-  await page.goto("/products/{{PRODUCT_SLUG}}");
-  await page.getByRole("button", { name: "Add to Cart" }).click();
-
-  // Login
-  await page.goto("/login");
-  await page.fill('[name="email"]', "{{TEST_USER_EMAIL}}");
-  await page.fill('[name="password"]', "{{TEST_USER_PASSWORD}}");
-  await page.getByRole("button", { name: "Sign In" }).click();
-
-  // Guest cart item should appear in user cart
-  await page.goto("/cart");
-  await expect(page.getByText("{{PRODUCT_NAME}}")).toBeVisible();
-});
-```
-
-## MSW Mock PG Server (CI)
-
-```typescript
-// mocks/pg-server.ts
-export const pgHandlers = [
-  http.post("{{PG_ENDPOINT}}", async ({ request }) => {
-    const body = await request.json() as Record<string, unknown>;
-    const card = body.cardNumber as string;
-
-    if (card === "4000000000000002") {
-      return HttpResponse.json({ status: "FAILED", code: "CARD_DECLINED" }, { status: 400 });
-    }
-    return HttpResponse.json({
-      status: "APPROVED",
-      transactionId: `mock_${Date.now()}`,
-    });
-  }),
-];
-```

package/skills/vibe.educational-content/SKILL.md

@@ -1,164 +0,0 @@
----
-name: vibe.educational-content
-description: Use when producing a lesson, course, tutorial, workshop, explainer, or assessment that needs observable learning outcomes and every claim traced to a source, with verified fact kept separate from inference.
-user-invocable: false
----
-
-# Create Educational Content
-
-## Done Criteria
-
-- [ ] 각 학습 목표가 관찰 가능한 행동으로 작성되어 있다.
-- [ ] 핵심 사실에 출처 또는 저장소 근거가 연결되어 있다.
-- [ ] 연습 과제와 정답 또는 평가 기준이 존재한다.
-- [ ] 최종 산출물이 요청된 형식과 경로에 존재한다.
-
-Turn a subject into a publishable learning experience whose outcome can be observed. Design the learning before polishing the presentation.
-
-## Set the contract
-
-Infer missing low-risk details and state the assumptions. Ask only when audience, format, or publication constraints would materially change the result.
-
-Capture:
-
-- outcome: what the learner can do afterward
-- audience: age or role, prior knowledge, motivation, language, accessibility needs
-- context: self-study, classroom, onboarding, reference, campaign, or performance support
-- format: lesson, article, workshop, video, course, worksheet, assessment, or short-form
-- source: curriculum, document, URL, repository, expert input, dataset, or user notes
-- constraints: duration, length, standards, platform, brand, deadline
-- proof bar: demonstration, explanation, performance, artifact, quiz, rubric, or observation
-
-Do not begin with a broad topic such as “teach climate change” or “teach Docker.” Rewrite it as an observable outcome such as “a learner distinguishes weather from climate using three examples” or “a frontend developer deploys a two-service Compose app and verifies health checks.”
-
-Read [references/learning-design.md](references/learning-design.md) when selecting objectives, activities, scaffolding, or assessments.
-
-## Choose a teaching path
-
-Prefer a progression from concrete experience to independent performance:
-
-1. Activate relevant prior knowledge or expose a meaningful problem.
-2. Model the target performance with a concrete example.
-3. Guide practice with prompts, hints, or worked steps.
-4. Give feedback against explicit criteria.
-5. Remove support and require independent application or transfer.
-
-For technical tool education, the progression may be easy surface → inspectable implementation → power-user surface → automation. Use a different order when prerequisites, domain practice, or safety require it. Avoid fact or feature tours; organize around learner performance.
-
-## Research the claim surface
-
-Build a claim ledger before drafting. For each consequential claim record:
-
-| Claim | Evidence | Status | Content use |
-|---|---|---|---|
-| What the tool does | primary docs or observed run | verified | state directly |
-| Why it behaved that way | code, docs, or controlled test | verified/inferred | label inference |
-| What may vary | version, OS, account, UI, network | uncertain | add caveat |
-
-Prefer primary, authoritative, and current sources. Use multiple credible perspectives for contested subjects. Inspect target materials in full before explaining them. Never invent quotations, citations, commands, settings, UI labels, research findings, statistics, benchmark numbers, or results.
-
-For source-video-derived work, read [references/source-method.md](references/source-method.md) to preserve the method without copying the source presentation.
-
-## Build the learning evidence
-
-Create the smallest realistic activity that elicits the promised outcome.
-
-1. Record environment and prerequisites.
-2. Establish the initial state.
-3. Model one successful performance or worked example.
-4. Give the learner a meaningful action, decision, explanation, or creation task.
-5. Capture evidence with a criterion-aligned check.
-6. Record one likely misconception and corrective feedback path.
-
-For code, tools, experiments, or procedures, keep demonstrations reproducible where possible and verify actual results. For conceptual subjects, require explanation, classification, comparison, prediction, or application instead of relying only on recall. Separate paid, destructive, medical, legal, physical, or external actions from harmless learning checks and require appropriate authorization or supervision.
-
-## Design the narrative
-
-Use this spine:
-
-1. **Promise** — show the concrete end state.
-2. **Mental model** — explain only the concepts needed for the next action.
-3. **Setup** — connect prior knowledge and define prerequisites.
-4. **Model** — demonstrate the target thinking or performance.
-5. **Practice** — progress through small, observable attempts.
-6. **Feedback** — address a realistic misconception or failure.
-7. **Assess** — elicit independent evidence of learning.
-8. **Extend** — transfer the idea to a new context.
-9. **Recap** — map the evidence back to the learning outcome.
-
-Pair every explanation with evidence:
-
-- explanation establishes what and why
-- example or demonstration shows how
-- learner activity elicits performance
-- assessment shows whether the outcome was reached
-
-Do not confuse exposure with learning. Watching, reading, or clicking is not sufficient evidence unless the stated objective only requires recognition. Explain decisions, relationships, constraints, and changes in understanding.
-
-## Draft the production package
-
-Produce only artifacts the requested format needs. Use the schemas in [references/output-patterns.md](references/output-patterns.md).
-
-At minimum include:
-
-- title and one-sentence learner promise
-- audience and prerequisites
-- outline with estimated pacing
-- model, guided practice, and independent practice
-- assessment, answer guidance, or scoring rubric
-- evidence or capture plan
-- safety and uncertainty notes
-- final quality checklist
-
-For video, add scene intent, narration, visual action, learner prompt, and evidence shot. For articles, add reflection or practice prompts and expected reasoning; add runnable code and expected output when technical. For workshops, add checkpoints, facilitator moves, and misconception recovery.
-
-## Apply gates
-
-Stop and repair the artifact when a gate fails.
-
-### Accuracy gate
-
-- Every consequential claim is verified or explicitly labeled as inference.
-- Version-sensitive facts are current and sourced.
-- Commands and code match the stated environment.
-
-### Learning-evidence gate
-
-- The activity elicits the behavior named in the objective.
-- Practice includes timely, actionable feedback.
-- Independent assessment does not give away the answer.
-- Expected evidence and evaluation criteria are explicit.
-
-### Teaching gate
-
-- Each section advances the learner toward the promise.
-- New concepts appear immediately before use.
-- Jargon is defined once and then used consistently.
-- Cognitive load fits the audience and format.
-- Examples are inclusive, relevant, and free of avoidable stereotypes.
-
-### Safety gate
-
-- External writes, destructive actions, and high-stakes activities have an approval or supervision boundary.
-- Secrets, personal data, and account details are absent from captures.
-- Minor learners and sensitive subjects receive appropriate privacy and safeguarding treatment.
-
-### Production gate
-
-- Claims, narration, captions, visuals, activities, and assessments agree.
-- No placeholder, fabricated output, or unsupported superlative remains.
-- The final artifact names limitations and the next useful action.
-
-## Handle failure
-
-- If the source cannot be accessed, report the missing evidence and request an artifact or alternate source; do not fabricate an analysis.
-- If a live tool is unavailable, use a recorded fixture and label it as simulated.
-- If a technical demonstration fails, reproduce once, state one root-cause hypothesis, add a failing check, then fix.
-- If learners cannot complete an activity, distinguish missing prerequisite knowledge, unclear instruction, excessive load, and a flawed assessment before adding more explanation.
-- If behavior is nondeterministic, show the invariant acceptance criteria instead of promising identical output.
-- If evidence is contested or culturally situated, present the source context and credible disagreement rather than manufacturing certainty.
-- If the requested scope exceeds the format, preserve the core learning outcome and move depth into a follow-up resource.
-
-## Finish
-
-Return the production-ready artifact, the verification evidence, and a short list of assumptions or unresolved uncertainties. Keep research notes out of the final content unless they help the learner judge a claim.

package/skills/vibe.educational-content/references/learning-design.md

@@ -1,81 +0,0 @@
-# Learning design
-
-Use this reference to align objectives, activities, feedback, and assessment.
-
-## Write observable objectives
-
-Use `learner + action + conditions + criterion` when the criterion matters.
-
-- weak: understand photosynthesis
-- observable: explain how light energy becomes stored chemical energy using a labeled diagram
-- weak: know Git branches
-- observable: create a feature branch, resolve one merge conflict, and explain why each resolution is correct
-
-Match the action to the desired depth:
-
-- remember: identify, recall, label
-- explain: summarize, compare, classify, explain
-- apply: use, calculate, execute, demonstrate
-- analyze: diagnose, distinguish, map, justify
-- create: design, produce, compose, implement
-- evaluate: critique, prioritize, defend with criteria
-
-## Align the learning sequence
-
-For every objective, provide:
-
-1. a model or example of the target performance
-2. guided practice that exposes learner thinking
-3. feedback specific to the success criteria
-4. independent practice without answer leakage
-5. an assessment using the same skill at an appropriate difficulty
-6. a transfer task in a changed context when durable learning matters
-
-Do not assess a deeper behavior than the instruction and practice prepared. Do not use recall questions as proof of application or analysis.
-
-## Diagnose the audience
-
-Distinguish:
-
-- prerequisite knowledge: facts or skills needed before starting
-- misconceptions: plausible but incorrect mental models
-- motivation: why the outcome matters to the learner
-- constraints: time, language, device, accessibility, instructor support
-
-Use a short pre-check when assumptions materially affect the path. Offer a bypass for learners who already demonstrate the prerequisite.
-
-## Scaffold and fade
-
-Move from worked example → completion task → independent task. Reduce hints as competence grows. Keep essential information near the activity that uses it. Split intrinsic complexity into meaningful chunks without fragmenting the overall mental model.
-
-## Give feedback
-
-Make feedback:
-
-- timely: close enough to the attempt to guide correction
-- specific: name the criterion and evidence
-- actionable: identify the next attempt
-- explanatory: address the learner's reasoning, not only correctness
-
-Avoid praise or correction that reveals no path forward. For high-stakes assessment, separate coaching practice from scored performance.
-
-## Design fair assessment
-
-Check:
-
-- validity: does the task measure the stated objective?
-- reliability: would equivalent performance receive equivalent judgment?
-- accessibility: can learners perceive and respond without irrelevant barriers?
-- fairness: does success depend on unstated cultural, linguistic, or technical knowledge?
-- authenticity: does the task resemble meaningful use of the skill?
-
-Provide acceptable variants and a rubric for open-ended work. Never fabricate learner results or claim effectiveness without evidence.
-
-## Adapt by format
-
-- self-study: make navigation, answers, and recovery self-contained
-- instructor-led: include facilitation prompts, timing, observation cues, and optional extensions
-- video: use retrieval pauses; do not replace practice with passive viewing
-- short-form: teach one distinction or action and give one immediate retrieval prompt
-- reference material: optimize lookup and decision support; do not force an unnecessary lesson arc
-- onboarding: use the real performance context, safe fixtures, and operational boundaries

package/skills/vibe.educational-content/references/output-patterns.md

@@ -1,109 +0,0 @@
-# Output patterns
-
-Select one primary pattern and omit unused fields.
-
-## Article or tutorial
-
-```markdown
-# Title: learner-visible outcome
-Audience:
-Prerequisites:
-Tested with:
-
-## What you will build
-## Mental model
-## Worked example
-## Step 1 — action
-Exact input:
-Expected result:
-Verification:
-## Common failure and recovery
-## Independent practice
-## Assessment and answer guidance
-## Extension
-## Recap
-## Sources and limitations
-```
-
-## Screencast or course chapter
-
-| Time | Learning beat | Narration intent | Visual action | Learner prompt | Evidence shot | Asset |
-|---|---|---|---|---|---|---|
-| 00:00 | Promise | Name the outcome | Show final state | Predict or notice | Working result | capture |
-
-Add a capture manifest:
-
-```yaml
-- id: proof-final
-  state: exact prerequisite state
-  action: command, prompt, or UI action
-  evidence: expected visible result
-  privacy: crop or redact requirements
-  retry: recovery action
-```
-
-## Lesson or workshop
-
-```markdown
-Outcome:
-Duration:
-Starting repository/state:
-Prior-knowledge check:
-
-Checkpoint 1:
-- learner action
-- facilitator proof
-- likely misconception
-- feedback or recovery
-
-Independent task:
-Acceptance criteria:
-Answer guidance or rubric:
-Cleanup or rollback:
-```
-
-## Short-form educational content
-
-```markdown
-Hook: surprising observable result
-Context: one sentence
-Teach: one model, contrast, or no more than three actions
-Retrieve: one prediction, decision, or recall prompt
-Proof: answer, demonstration, or comparison
-Caveat: scope, evidence, safety, or limitation
-CTA: reproducible next step, not engagement bait
-```
-
-## Assessment item
-
-```yaml
-objective: "observable learning outcome"
-prompt: "task that elicits the outcome"
-evidence: "what a valid response must demonstrate"
-criteria:
-  - name: "criterion"
-    levels: ["not yet", "developing", "meets", "extends"]
-answer_guidance: "reasoning and acceptable variants"
-misconceptions:
-  - signal: "common wrong pattern"
-    feedback: "specific corrective prompt"
-fairness_check: "language, accessibility, cultural, or prerequisite issue"
-```
-
-## Verification appendix
-
-```yaml
-environment:
-  context: ""
-  versions: []
-claims:
-  - claim: ""
-    status: verified | inferred | uncertain
-    evidence: ""
-    checked_at: "YYYY-MM-DD"
-checks:
-  - learner_action: ""
-    expected: ""
-    observed: ""
-unresolved: []
-```

package/skills/vibe.educational-content/references/source-method.md

@@ -1,40 +0,0 @@
-# Source-derived method
-
-Use this reference when adapting the method demonstrated in [Yalco's Codex training video](https://youtu.be/Bzdcg70ivrs). It records reusable principles, not a transcript.
-
-## Evidence basis
-
-- YouTube metadata identifies the video as “코덱스 참교육 - Codex 업무 자동화부터 바이브 코딩까지” by 얄팍한 코딩사전.
-- The creator's official course page identifies the public video as the 13:19 introduction, “코덱스 소개 & 강의에서 배울 것.” It describes the course examples and method across the Codex app, editor, CLI, plugins, automation, skills, MCP, testing, review, and harness engineering.
-- Full captions and frame-level playback were unavailable during source analysis because YouTube blocked the server request. Do not present the wider course curriculum as a scene-by-scene account of the 13:19 video.
-- Exact UI labels, model names, generated configuration, availability, and account requirements are version-sensitive. Verify them against current primary documentation before publishing.
-
-## Reusable principles
-
-1. Contrast a chat answer with an agent changing observable state.
-2. Start beginners on the lowest-friction surface, then reveal editor and CLI depth.
-3. Teach through a continuous result: create a file, inspect it, render it, then extend it.
-4. Show exact prompts or commands alongside their actual effects.
-5. Verify in the destination system: browser, filesystem, calendar, draft folder, or job history.
-6. Keep human approval around file deletion, messages, purchases, publication, and other external writes.
-7. Isolate agent work with a bounded project folder or sandbox.
-8. Explain that generated details may vary while acceptance criteria remain stable.
-9. Promote a successful one-off task to scheduled automation only after manual validation.
-10. Give automation an explicit scope, cadence, observable failure, and way to disable it.
-11. Structure agent requests with a goal, context, constraints, and observable completion criteria.
-12. Teach adjustment and verification instead of promising output identical to a recording.
-
-## Content adaptation
-
-Translate the method, not the examples:
-
-- replace the demonstrated product with the target technology
-- replace “app → editor → CLI” with “easy surface → inspectable implementation → power-user surface”
-- replace calendar or email proof with the target system's independent readback
-- replace feature enumeration with a single outcome that crosses two or three depth levels
-
-Attribute ideas when closely discussing the source. Do not reproduce long wording, full transcripts, or the source's visual identity.
-
-## Reliability notes
-
-Treat any detailed timeline produced by automated video analysis as an index to verify, not as authoritative evidence. Recheck timestamps and screen text before including them in published content. If direct playback or captions are unavailable, label the gap and avoid exact quotations.

package/skills/vibe.event/SKILL.md

@@ -1,66 +0,0 @@
----
-name: vibe.event
-description: 커뮤니티 행사 일정·홍보·운영을 준비하거나 D-Day 기준 자동화가 필요할 때 — event 유형을 판별하고 외부 발송 전 승인을 강제한다.
-argument-hint: '"event description" | status | dashboard'
-user-invocable: true
----
-
-# /vibe.event
-
-## 완료 기준
-
-- [ ] event 유형, 날짜, D-Day가 상태 파일에 기록되어 있다.
-- [ ] 선택한 planning·communications·operations 단계의 산출물이 존재한다.
-- [ ] 외부 발송은 명시적 승인 기록 없이는 실행되지 않았다.
-- [ ] 완료된 task와 남은 task 상태가 저장되어 있다.
-
-Route one event request across planning, communications, and operations without loading unrelated detail.
-
-## Usage
-
-```text
-/vibe.event "MDC 12차 3/30"
-/vibe.event "webinar AI에이전트 4/15"
-/vibe.event "DWK 5차 5/20 오프라인"
-/vibe.event status
-/vibe.event dashboard
-```
-
-## Routing
-
-1. Parse event type (`MDC`, `webinar`, `DWK`), edition, date, topic, and format.
-2. Load `.event_state.json` when present; update it after each completed action.
-   For the complete phase tables, parsing examples, state schema, dashboard,
-   and legacy safety contract, read `references/orchestration-legacy.md`.
-3. Select only the required reference:
-   - timeline, speakers, outreach, intro/SNS/review content → `references/planning.md`
-   - SMS, email, invitations, reminders, SNS delivery copy → `references/comms.md`
-   - nametags, checklist, slides, Slido, images, settlement → `references/operations.md`
-4. When a request crosses modes, execute planning before communications and operations, sharing the same event state and output paths.
-
-Claude Code maps named event workers to Task/Agent; Codex maps them to native
-collaboration. Inherit the session model and delegate independent work only
-when it does not race on `.event_state.json` or shared output files.
-
-## Safety Gate
-
-- Drafts, previews, test sends, and local artifacts may be produced automatically.
-- Never send SMS/email/SNS, publish content, upload, or contact a real person without explicit confirmation in the current conversation.
-- Before confirmation show recipient count, exact preview, channel, and cost estimate where applicable. Email recipients use BCC.
-- Autonomous mode never bypasses this external-state confirmation.
-
-## State and Outputs
-
-- State: `.event_state.json`
-- Speaker history: `data/speakers/{name}.json`
-- Reports and copy: `output/reports/`
-- Images and prompts: `output/images/`
-
-## Done
-
-- Event identity and current D-Day phase are explicit.
-- Every requested artifact exists at its documented path.
-- State reflects completed, pending, and confirmation-blocked work.
-- No external send or publish occurred without explicit approval.
-
-ARGUMENTS: $ARGUMENTS