devmethod-ai 0.1.0 → 0.2.0

package/.agents/skills/design-to-code/SKILL.md

@@ -1,12 +1,18 @@
 ---
 name: design-to-code
-description: Translate an approved mockup or design direction into coherent product UI and verify visual and interaction fidelity. Use for reference-driven screens, design-system adoption and UX audits; distinguish design creation from implementation of an already locked direction.
+description: Create or apply visual directions and mockups, implement product UI, and verify visual and interaction fidelity. Use for new art direction, image mockups, prototypes, reference-driven screens and UX audits; preserve an already approved direction.
 ---
 
 # Design to Code
 
 An approved mockup is a visual contract. Do not “improve” its direction without a request. Product, accessibility, and security constraints still apply; make a conflict visible rather than hiding it.
 
+## Select the design mode
+
+For a new direction or requested image mockups, read [visual creation](references/visual-creation.md): brief → visible alternatives → user selection → selected mockups → prototype → implementation and comparison. Image generation depends on an available host tool; DevMethod does not bundle one. Keep choices and evidence in the existing mission/design record.
+
+For an approved reference, continue directly below without reopening the direction.
+
 ## Execution
 
 1. Read and actually view the reference: screen/version, viewport, tokens, hierarchy, content, media, and states. If it is missing, find the referenced asset; do not invent its geometry or a fidelity verdict.

package/.agents/skills/design-to-code/references/visual-creation.md

@@ -0,0 +1,37 @@
+# Create a visual direction
+
+Use this procedure during `project-foundation design` when the user needs a new visual direction, image mockups or a prototype. Skip creative exploration when an approved reference already exists. It is part of the existing six-module kit, not a new command or a bundled image service.
+
+## Brief and alternatives
+
+Read the product outcome, audience, primary journey, constraints and any supplied references. View referenced images before describing them. Reuse brand tokens and assets where established. Record only missing decisions in the canonical mission/design record. If no product is specified for a demonstration, identify the fictional assumption before producing assets; never apply it to a real product without a request.
+
+When the direction is open, propose two or three distinct approaches to the same screen with the same content. Explain each through hierarchy, typography, palette, density, imagery and the user need it supports. Show comparable visual previews, not only style adjectives. Do not invent research or call a proposal approved. Request the user's choice on the visible alternatives; continue independent work while waiting. Unless selection was explicitly delegated, do not infer a choice from elapsed time, a default option or silence. An explicit existing direction skips this decision.
+
+## Master screen and page expansion
+
+When the user requests a master-to-pages workflow, keep three observable checkpoints within the existing `design` command: comparable directions, a selected detailed master screen, then the requested screen set derived from that master. These are natural-language scopes, not new CLI subcommands. Recommend `$project-foundation design` in Codex, or `/project-foundation design` in Claude Code/Cursor, with the next unfinished visual scope until the requested design work is complete; do not jump to architecture merely because a style direction was selected.
+
+Use the same representative screen and content for the alternatives. After selection, finalize that screen as the master and record its asset/version plus the user's approval. Derive the requested pages or states using the actual master image as tool input together with its shared tokens, components and copy. A prose style description alone is not evidence of reference-conditioned generation. Map every requested page/state to its output file and master version in the existing record. Do not invent routes to turn states of a small app into a larger product.
+
+Inspect cross-screen consistency and behavior before implementation. Reuse existing approvals for unchanged decisions; surface unexpected additions in the derived screens for approval. Preserve page-specific content while sharing the master hierarchy, type, palette and components. When documenting a demonstration, distinguish generated page images, implemented screens and captures; do not present images generated after the code as proof that those images guided that earlier code.
+
+## Selected mockups
+
+After selection, record the chosen asset/version and any requested changes. Use an available image tool and its skill when raster mockups or generated illustrations are requested; check actual tool availability rather than promising that installation provides it. If unavailable, report that the image step is unfulfilled. A prompt for an external tool is a handoff, not a generated image. Offer an appropriate HTML/SVG preview if useful, without presenting it as fulfilment of an explicit image request. Paid tools and external mutations follow the session's permissions.
+
+Generate the key screens at agreed desktop/mobile sizes with real intended copy and necessary states. Inspect every output for legibility, omitted controls and invented content. Save project-bound selected assets in the project, with prompt, tool, version and source/reference paths linked from the design record. Preserve previous versions. Image metadata and synthetic content must not imply real product data. Correct image text in the design contract when needed; a raster image is not the authoritative specification for behavior.
+
+Ask for approval of the selected detailed mockup before treating it as the implementation reference, unless that selection was already delegated. A direction choice alone does not approve unexpected additions in a later generated screen. Approval can be an explicit request to implement that visible version; no ceremonial extra approval is required. Do not create one document per stage.
+
+## Prototype and implementation
+
+Define intended behavior and empty/loading/error states independently of image appearance. Use a minimal interactive prototype when interaction needs validation; it may become the implementation rather than a throwaway copy. Label fixture data and simulated states. Controls must perform their declared behavior; do not fabricate success, network calls or persistence. For a reading tracker, a “Lire” control needs an actual reading destination; use “Commencer” for changing status instead of implying full books are available.
+
+Pass the approved reference, tokens, exact content, states, assets and criterion IDs into the main design-to-code execution. Reuse the project's stack and components. Resolve differences between the mockup and product/accessibility constraints explicitly, keeping user authorization current.
+
+## Fidelity and resumption
+
+Capture actual browser output at reference viewport sizes. Compare reference and implementation for hierarchy, layout, type, colors, assets, copy and state. Test the main interaction, keyboard/focus, mobile overflow and relevant failure recovery separately. Attach observations and reference/capture paths to existing criterion evidence; name mismatches and corrections. Do not claim pixel-perfect output from compilation, DOM tests or image generation. A preview alone is not a browser verification.
+
+On resume, load the chosen reference/version and current code, not every rejected direction. A changed reference or implementation invalidates affected visual evidence. A deliberate mismatch in a disposable evaluation can test whether the review detects it; restore the intended design and recheck before acceptance. Report selection, generation, prototype, implementation and visual verification separately, including unperformed steps.

package/.agents/skills/project-foundation/SKILL.md

@@ -39,7 +39,7 @@ At the end of every execution, state what is done, what remains uncertain or blo
 | Need | Skill to resolve by name |
 |---|---|
 | Decide product/stack trade-offs, ADRs, DDD, or backend boundaries | `decision-architecture` |
-| Translate an approved reference into UI and verify fidelity | `design-to-code` |
+| Create/select a visual direction and mockups, or implement an approved reference and verify fidelity | `design-to-code` |
 | Build/refactor React, hooks, state, and server/client boundaries | `react-feature-engineering` |
 | Design product agents, evidence, AI providers, and jobs | `reliable-ai-integration` |
 | Turn scope into verifiable delivery, review, and resumption | `scoped-delivery` |

package/.agents/skills/project-foundation/assets/PROJECT_PROFILE.md

@@ -8,6 +8,7 @@ Complete from source material during first startup; keep unknowns explicit. This
 - Foundational constraints: operator time, fixed budget, variable cost, deadline.
 - Product source and accepted decisions (links + date/version):
 - Ticket source / readiness criteria:
+- Canonical mission / plan / evidence locations (reuse existing conventions; links only, no copied status):
 - Approved UI reference (screen, version, viewport, states):
 - Canonical code (repository, branch, inspected commit):
 - Effective stack (runtime, frameworks, package manager, lockfile versions):

package/.agents/skills/project-foundation/references/mission-context.md

@@ -2,6 +2,16 @@
 
 One mission owns a user outcome, observable acceptance, scope/exclusions, invariants, sources, uncertainties, dependencies, responsibilities, checks, stop conditions and exact resume action. Keep Quick records inline; use the scoped-delivery mission template for substantial work. No mandatory stack migration or fourteen-document process.
 
+## Location and ownership
+
+Reuse the project's ticket, plan and evidence conventions first. Record their canonical paths or URLs once in the existing project profile. Without a convention, keep one `docs/missions/<mission-id>.md` record using the mission template; keep the plan, criterion evidence and latest handoff as sections in that file until their size justifies extraction. Do not create a mission directory during a read-only assessment or for Quick work. Do not move existing records just to match this fallback.
+
+Each value has one current owner: mission outcome/status/next action in the mission record (or existing tracker); task status/dependencies in the existing plan or ticket; check results and inspected revision in its evidence rows. Link to the owner instead of copying live status into the profile, roadmap, slice and checkpoint. A mission's outcome status and a task's execution status describe different scopes. Snapshot reports/checkpoints must identify their captured revision and canonical record; they are historical evidence, never a second live tracker. Reconcile them against current code on resume.
+
+Use stable criterion IDs in the plan and evidence. Keep one row per criterion/check with the affected change, actual result, artifact or concise observation, inspected revision, and review reference. Review identifies self-review or independent review, inspected diff/revision, findings and resolution. A ready plan proves no implementation; a passed check proves only what it inspected. Update affected rows after changes, retaining failures and invalidating dependent reviews. Separate local verification from integration/deployment.
+
+Create a separate slice only when the plan lacks executable scope; a separate verification file only when evidence no longer fits; a checkpoint only for interruption or handoff, preferably as the latest handoff section. Optional JSON mission/plan/checkpoint records serve the existing inspectors: adopt them when machine inspection is useful, never require Markdown plus JSON copies of live state. Their schemas remain unchanged; do not invent cross-record fields and claim the CLI validates these links.
+
 Select useful project, domain, mission and execution sources. Record why each is relevant, inspected revision, subject-specific authority, and fact/assumption/proposal/accepted-decision status. New proposals do not supersede accepted contracts. Declare contradictions and resolve affected work; continue independent authorized scope. Load file contents progressively.
 
 Optional offline candidate CLI commands:

package/.agents/skills/project-foundation/references/operating-commands.md

@@ -16,7 +16,7 @@ Use [work sizing](work-sizing.md) to select relevant stages. A quick change may
 |---|---|---|
 | `/explore` | Understand the problem, users, market, and constraints | `/frame` |
 | `/frame` | Define value, scope, exclusions, and metrics | `/design` or `/architecture` |
-| `/design` | Define or apply an approved UX/UI direction | `/architecture` |
+| `/design` | Create/select visual direction, master and derived screens, or apply approved UX; resolve design-to-code for visual work | `/design` for unfinished visual scope, then `/architecture` |
 | `/architecture` | Define boundaries, ADRs, contracts, risks, and open decisions | `/plan` |
 | `/plan` | Break work into milestones, epics, and ready tickets | `/ready` |
 | `/ready <ticket>` | Verify scope, DoD, dependencies, contract, and tests | `/implement <ticket>` |
@@ -29,7 +29,19 @@ Use [work sizing](work-sizing.md) to select relevant stages. A quick change may
 | `/status` | Distinguish planned, in progress, PR, merged, and deployed | `/next` or `/correct-course` |
 | `/handoff` | Create a concise checkpoint for another session or agent | `/next` |
 
-## Output rules
+## Responsibility and minimal context
+
+Start from the canonical mission/plan locations in the existing profile; see [mission context](mission-context.md). Read applicable rules and the current task first, then only the decisions, sources and evidence needed for this command. Do not regenerate the profile or read every previous stage document on each invocation.
+
+- `status` reports actual state, evidence gaps and blockers without changing records or executing checks. `next` reconciles the canonical record with real state and selects the next authorized slice; it does not start implementation merely because a candidate exists.
+- `explore`, `frame`, `design` and `architecture` add only missing decisions to their existing owner. `plan` owns task decomposition, dependencies and executable criteria, reusing the current plan. Neither creates a new status ledger or proves delivery.
+- `ready` assesses the selected task's scope, dependencies and checks without executing them or starting implementation. Under an implementation request, this assessment can happen inline and continue without another user turn when ready.
+- `implement` maintains the affected task and evidence through its implementation loop. `review` inspects the identified diff and evidence, recording findings without silently fixing code unless fixes were requested. `verify` runs missing or invalidated checks and updates criterion evidence. Reuse unchanged evidence whose inputs and environment still apply; do not rerun solely because a new stage was invoked.
+- `handoff` records a compact snapshot with links to canonical state. `correct-course` updates only affected decisions, scope and dependent evidence. `integrate` records the actual authorized delivery result with its reference.
+
+For prose-only changes, inspect accuracy, links and diff; do not invent `npm run quality` or trigger an application build by habit. Follow stricter repository gates when documented, and explain once why they apply. Report executed checks, never planned checks as success.
+
+## Response
 
 At the end of every command, provide:
 

package/.agents/skills/scoped-delivery/SKILL.md

@@ -13,6 +13,8 @@ Read `CONTRIBUTING.md`, accepted decisions, applicable instructions, the decisio
 
 Use [the mission record](assets/MISSION.md) for substantial work; keep Quick records inline. Scope is ready when objective, exclusions, contracts, dependencies, and success criteria are sufficiently defined. Use [the slice record](assets/SLICE.md) for a substantial ticket, without bureaucracy for a clear fix. A contradiction blocks only work depending on that trade-off.
 
+Reuse the existing tracker/plan before creating any record. Without project conventions, use one `docs/missions/<mission-id>.md` with plan, evidence and latest handoff sections. Extract a slice or verification record only when the existing record cannot hold useful detail. Keep mission state in its canonical owner, task state in the plan/ticket, and results in evidence; other records link to them. A checkpoint is a revision-labelled snapshot, not another current status source.
+
 ## Deliver
 
 - One coherent intent per slice; prefer a useful vertical slice to disconnected layers.

package/.agents/skills/scoped-delivery/assets/MISSION.md

@@ -1,5 +1,7 @@
 # Mission
 
+Reuse an existing mission/ticket record; otherwise use `docs/missions/<mission-id>.md` unless project conventions specify another location. Quick work stays inline. The sections below can contain the plan, evidence and latest handoff; separate files are optional. Link existing owners instead of duplicating their live fields.
+
 ID / owner / Quick, Standard or Major:
 User outcome:
 Observable acceptance criteria (stable IDs):
@@ -9,10 +11,25 @@ Sources (path, revision, authority for this subject, fact/assumption/proposal/ac
 Uncertainties and declared contradictions:
 Dependencies (owner, resolved/blocked, exact missing input):
 Responsibilities and owned paths:
-Acceptance ID → change → verification kind/command → outcome → artifact/revision:
+Plan / task status owner (link, or a task table here with IDs, dependencies and status):
 Actual state (active/blocked/complete):
 Stop conditions:
 Exact next action (none when complete):
 Current authorization and external actions still requiring authorization:
 
+## Evidence and review
+
+| Acceptance ID | Change or task | Verification kind / executed command or procedure | Result | Artifact or observation / inspected revision | Review reference |
+|---|---|---|---|---|---|
+| AC-01 | Owned change | Planned check until executed | not run | No evidence yet | not reviewed |
+
+Review (here or linked): self-review/independent, reviewer, inspected revision/diff, findings and resolutions.
+Delivery evidence (here or linked): local / PR / merged / deployed / production-verified.
+
+## Latest handoff (only when needed)
+
+Captured revision / dirty files / changed sources:
+Evidence to retain or invalidate / unresolved blockers:
+Resume from the canonical status and exact next action above; do not copy another live status here.
+
 Select useful project rules, domain contracts, mission scope and execution evidence. Escalate when risk, uncertainty or contracts change. A failed check returns to the affected implementation/design step. Status is read-only. Record passed, failed, blocked or not run truthfully; planned commands are not evidence. Preserve independent pins and invalidate affected evidence after changes. Never renew old external authorization from this record.

package/COMPATIBILITY.md

@@ -1,6 +1,6 @@
 # Compatibility evidence
 
-Historical platform assessment date: 2026-09-12; those results apply only to their recorded revision. Current release status: [0.1.0 validation](docs/RELEASE-0.1.0.md); [rc.2 validation](docs/RC2-VALIDATION.md) remains a historical record. Target: local project skills, not every cloud or chat product carrying the same brand. Packaged installation passed on native Linux x64, macOS ARM64 and Windows Server 2025 x64 runners with Node.js 22.23.2; see [the operating-system results](VALIDATION.md#native-operating-system-results). These results do not establish authenticated coding-agent behavior.
+Historical platform assessment date: 2026-09-12; those results apply only to their recorded revision. Release status: [0.2.0 candidate](docs/RELEASE-0.2.0.md), [published 0.1.0 validation](docs/RELEASE-0.1.0.md); [rc.2 validation](docs/RC2-VALIDATION.md) remains a historical record. Target: local project skills, not every cloud or chat product carrying the same brand. Packaged installation passed on native Linux x64, macOS ARM64 and Windows Server 2025 x64 runners with Node.js 22.23.2; see [the operating-system results](VALIDATION.md#native-operating-system-results). These results do not establish authenticated coding-agent behavior.
 
 | Host | Export directory | Invocation | Evidence |
 |---|---|---|---|

package/README.md

@@ -4,13 +4,32 @@ From idea to delivery with your AI coding agents.
 
 [![npm](https://img.shields.io/npm/v/devmethod-ai?label=npm)](https://www.npmjs.com/package/devmethod-ai) [![license](https://img.shields.io/npm/l/devmethod-ai)](LICENSE) [![platform tests](https://github.com/montassarkhalloufi/DevMethod/actions/workflows/platform-tests.yml/badge.svg)](https://github.com/montassarkhalloufi/DevMethod/actions/workflows/platform-tests.yml)
 
+## Watch DevMethod build Lisière — 2 min 58 s
+
+[![Play the 4K demo: approved master and derived Lisière screens](docs/media/visual-chain/video-preview.jpg)](https://github.com/montassarkhalloufi/DevMethod/raw/refs/heads/main/docs/media/visual-chain/devmethod-du-besoin-au-produit-4k.fr.mp4)
+
+**[▶ Watch the video — 4K, French narration](https://github.com/montassarkhalloufi/DevMethod/raw/refs/heads/main/docs/media/visual-chain/devmethod-du-besoin-au-produit-4k.fr.mp4)** · [Subtitles and execution evidence](docs/media/visual-chain/README.md) · [Download the working prototype](https://github.com/montassarkhalloufi/DevMethod/raw/refs/heads/main/docs/media/visual-chain/lisiere-visual-source.zip)
+
+**Concrete example: Lisière, a personal reading library.** Start with an idea, compare three visual directions, approve a master screen, derive the other screen images, choose a suitable architecture, then build and verify the application.
+
+| Step shown | Concrete result |
+| --- | --- |
+| Explore and frame | Add books, filter readings and track three statuses |
+| Design | Three alternatives → selected editorial master → add-book and completed-reading images |
+| Architecture | HTML/CSS/JavaScript, testable book rules and browser-local storage |
+| Plan, ready and implement | Working form, filters, status changes and saved books |
+| Review and verify | Corrected alert/focus behavior, 6 tests and real Chrome desktop/mobile journeys |
+| Integrate and handoff | Local prototype, references, evidence and resumption context |
+
+The video uses illustrative Codex commands with real generated images and recorded application interactions. DevMethod guides the coding agent; image generation requires an available host tool. The visual workflow is in the current GitHub source and is not included in npm 0.1.0. [Follow the visual workflow](docs/VISUAL-WORKFLOW.md).
+
 ![DevMethod workflow](docs/images/devmethod-flow.svg)
 
 DevMethod is the public name of the kit. Its entry-point skill remains `project-foundation`, preserving existing invocations and the six-module structure.
 
 A reusable workflow for taking a software project from exploration to delivery: decisions, UX, architecture, tickets, development, tests, review and handoff. Six focused skills support fourteen workflow stages, each ending with evidence, limitations and one suggested next command.
 
-**Release: 0.1.0.** The release includes mission/context inspection, Git-aware evidence resumption, explicit update conflicts, manual task planning and optional stack profiles. See the [release record](docs/RELEASE-0.1.0.md) for publication status and verification.
+**npm stable: 0.1.0 (`latest`). Next release candidate: 0.2.0.** [0.2.0 changes and publication status](docs/RELEASE-0.2.0.md). The release includes mission/context inspection, Git-aware evidence resumption, explicit update conflicts, manual task planning and optional stack profiles. See the [release record](docs/RELEASE-0.1.0.md) for publication status and verification.
 
 For developers and small teams using coding agents in new or existing repositories. Requires Node.js 22+ and npm; Git is required for context provenance. Application examples have separate framework/database prerequisites. DevMethod records scope, decisions and verification; it does not certify agent output, infer all dependencies, deploy applications or run an autonomous backlog. Installation and deterministic fixture results are separate from native host validation. See [compatibility](COMPATIBILITY.md).
 
@@ -32,7 +51,7 @@ npx --yes devmethod-ai@0.1.0 init --tool claude --dest ../foundation-staging --d
 
 Remove `--dry-run` to write. Select a subset with `--modules decision-architecture,scoped-delivery`; `project-foundation` is always included. Without `--modules`, all six modules are installed. The installer refuses divergent files and duplicate skills across host directories. It never edits AGENTS.md, CLAUDE.md or your package.json. Review the staging output, then merge only what the project needs.
 
-The installer has no runtime dependencies and makes no network requests after npm obtains the package. To pin the final version, use `npx --yes devmethod-ai@0.1.0 init ...`. To use a reviewed repository commit instead, use `npx --yes --package=github:montassarkhalloufi/DevMethod#<commit-sha> devmethod init ...`.
+The installer has no runtime dependencies and makes no network requests after npm obtains the package. To pin the final version, use `npx --yes devmethod-ai@0.1.0 init ...`. To use the visual workflow before 0.2.0 is published, use a reviewed repository commit: `npx --yes --package=github:montassarkhalloufi/DevMethod#<commit-sha> devmethod init ...`.
 
 Complete PROJECT_PROFILE.md with your real stack, commands, scope, deployment permissions and data requirements. Merge AGENTS.foundation.md into the project's existing instructions only after review. Claude Code reads CLAUDE.md: preserve its current content and, if the project has AGENTS.md, optionally add `@AGENTS.md` to import it. Keep existing accepted architecture decisions authoritative.
 
@@ -90,7 +109,7 @@ Replace `status` with an action below. These are prompts to the skill, not shell
 |---|---|
 | `explore` | Problem, users, alternatives and constraints |
 | `frame` | Product scope, exclusions and success measures |
-| `design` | UX direction and acceptance criteria |
+| `design` | Visual directions, selected mockups and UX criteria; image tooling depends on the host |
 | `architecture` | Decisions, boundaries and contracts |
 | `plan` | Milestones and tickets with dependencies |
 | `ready TASK-1` | Readiness assessment before implementation |
@@ -105,15 +124,15 @@ Replace `status` with an action below. These are prompts to the skill, not shell
 
 See the [full command contract](.agents/skills/project-foundation/references/operating-commands.md). A failed check returns to correction; a blocked gate leads to handoff or replanning. Tests, code review and native permissions remain necessary.
 
-```mermaid
-flowchart TD
-  A[Understand] --> B[Decide]
-  B --> C[Build]
-  C --> D[Verify]
-  D -->|evidence passes| E[Integrate]
-  D -->|failure or uncertainty| B
-  E --> F[Handoff]
-```
+![DevMethod delivery loop: accepted references, implementation, verification and correction](docs/images/devmethod-delivery.svg)
+
+## More recorded examples
+
+[Detailed recorded Lisière chain](docs/media/full-chain-4k/README.md) · [Short Clair demo](docs/media/from-zero/README.md) · [Run Clair](examples/clair-from-zero/README.md). Clair is a separate from-zero example; the featured video above follows Lisière throughout.
+
+## Visual design and architecture
+
+DevMethod connects art-direction selection, an approved master screen, derived image mockups and browser fidelity checks with technology and architecture decisions. Follow the [visual workflow guide](docs/VISUAL-WORKFLOW.md) and [recorded Lisière pilot](examples/visual-pilot/README.md). These capabilities are included in the 0.2.0 candidate; npm 0.1.0 predates them. See the [0.2.0 release record](docs/RELEASE-0.2.0.md) for publication status.
 
 ## Included modules
 

package/docs/MISSIONS.md

@@ -2,6 +2,8 @@
 
 A mission is one authorized user outcome with observable acceptance, scope/exclusions, invariants, selected sources, uncertainties, dependencies, ownership, verification, stop conditions and an exact next action. Quick work can keep this inline. Standard work benefits from a reusable record. Major work splits dependent missions after resolving structural decisions. JSON is optional; it does not replace your tracker or project policy.
 
+For storage, status ownership and criterion-to-review links, follow [mission context](../.agents/skills/project-foundation/references/mission-context.md). Prefer existing conventions; the fallback is one `docs/missions/<mission-id>.md` with plan, evidence and latest handoff sections. This is guidance for the agent, not a new CLI tracker, auto-discovery path or schema validation feature.
+
 Move Quick to Standard when a second component, uncertain dependency or changed contract needs an explicit record. Move to Major for structural decisions or migrations. Failed verification returns to implementation or design at the affected boundary; preserve the failure. Evaluation/status reads do not imply implementation, review does not imply integration, and integration does not imply publication.
 
 ## Source-checkout quick start

package/docs/RELEASE-0.1.0.md

@@ -1,6 +1,6 @@
 # DevMethod 0.1.0
 
-Status: PRs #6–#10 merged; integrated validation and authorized npm publication in progress. This page is the current release record. Earlier rc.2 and native-pilot documents describe their recorded revisions, not the current validation state.
+Status: PRs #6–#10 merged; all integrated checks passed. `devmethod-ai@0.1.0` is published on npm under `latest`; the downloaded registry archive passed verification. This page records the published 0.1.0 release; see [0.2.0](RELEASE-0.2.0.md) for the next candidate. Earlier rc.2 and native-pilot documents describe their recorded revisions, not the current validation state.
 
 ## Supported release scope
 
@@ -30,11 +30,11 @@ For an existing project, stage the installation, complete the project profile fr
 
 For a new project, fill the profile with the product scope, stack, verification commands and deployment permissions, then invoke `project-foundation` with the intended goal. An installed skill is guidance, not proof that a host used it correctly.
 
-After authorized publication, the version-pinned command will be `npx --yes devmethod-ai@0.1.0 init --tool codex --dest ../devmethod-staging`. Until registry verification, use the reviewed checkout or its local tarball.
+Install the verified published version with `npx --yes devmethod-ai@0.1.0 init --tool codex --dest ../devmethod-staging`.
 
 ## Validation record
 
-Local release verification passed: clean locked dependency installation, 72 core tests plus 18 greenfield checks, Markdown links, package inspection and extracted-tarball smoke for all three host layouts, a subset, customization preservation and mission/context/planning. Independent review reproduced the JSON-error regression and found no remaining blocker in the inspected public CLI changes. The final commit, archive digest and exact platform jobs are recorded separately in the repository release evidence and the release PR to avoid a self-referential archive hash. Publication still requires those exact jobs to be green; earlier CI runs are not substitutes.
+Local release verification passed: clean locked dependency installation, 72 core tests plus 18 greenfield checks, Markdown links, package inspection and extracted-tarball smoke for all three host layouts, a subset, customization preservation and mission/context/planning. Independent review reproduced the JSON-error regression and found no remaining blocker in the inspected public CLI changes. The final commit, archive digest and exact platform jobs are recorded separately in the repository release evidence and the release PR to avoid a self-referential archive hash. Those exact jobs passed before publication; earlier CI runs were not used as substitutes.
 
 Native evidence: [first bounded pilot](NATIVE-PILOT-RESULTS.md), [subagent adapter validation](CODEX-ADAPTER-VALIDATION.md). The follow-up campaign remains stopped with incomplete final usage; no model runs are necessary to package the supported CLI scope.
 
@@ -47,3 +47,14 @@ For a reviewed final version, publish the exact verified archive rather than rep
 ## From-zero application validation
 
 [Pocket Tasks validation](GREENFIELD-VALIDATION.md) records a new project built from a frozen brief, independent review and API acceptance, real browser interaction, and a method improvement derived from a discovered defect. This is separate from the incomplete BMAD campaign.
+
+## Exact final artifact (2026-09-13)
+
+- Source: `24a909b2e1293e46683960b7b127e17f29fbf74a`.
+- [Platform CI](https://github.com/montassarkhalloufi/DevMethod/actions/runs/34749164123): Linux, macOS and Windows succeeded on Node 22, including core tests, greenfield tests and packed installation checks.
+- [Fullstack CI](https://github.com/montassarkhalloufi/DevMethod/actions/runs/34749164119): Next.js/NestJS/PostgreSQL checks succeeded on the same revision.
+- `devmethod-ai-0.1.0.tgz`: 174 files; SHA-256 `2962fab73686f54ebbaa6b084cc6f1ef2f11db26a61feb85c633174247149d05`.
+- npm SHA-1: `810337a9da52d711ae2465c57480879aadbf2d0a`.
+- npm integrity: `sha512-bNyJ4to76YUZNvV0xrCIKzBqqh8QqcmtvMVCOx6CsCav0w3h0L/DUHdDpx2VLl/zePa2Eyg7ho8SOvlQOOz/Qg==`.
+
+The retained archive passed extracted-package smoke, including the new application and independent suites, all installation layouts, and preservation of a customized real rc.1 installation. No runtime data, private evaluations, environment files or dependency directories were packaged. Final independent review identified no remaining release blocker. The published npm tag is `latest`; `next` remains `0.1.0-rc.2`. After maintainer authentication, npm confirmed publication. The registry initially returned the previous metadata during propagation, then exposed 0.1.0. A fresh registry download matched the SHA-256 and npm integrity above and passed package smoke, including application/independent tests and legacy customization preservation. This post-publication status record is not inside the immutable published archive.

package/docs/RELEASE-0.2.0.md

@@ -0,0 +1,37 @@
+# DevMethod 0.2.0 — visual design through verified delivery
+
+Status: candidate prepared for maintainer review. Not published on npm. The registry still serves 0.1.0 under `latest`; npm authentication is required to publish this candidate. GitHub updates and package preparation are separate from publication.
+
+## Changes
+
+- The existing `design` stage now explicitly covers comparable artistic directions, an approved master screen, derived screen images and browser comparison. Stay in design while requested visual references are missing.
+- Existing approvals are retained for unchanged scope. Generated mockups, source references and browser captures are identified separately. The master is supplied as an actual image reference when the host supports it.
+- Design works alongside technology and architecture decisions; no framework or stack is imposed. There are still six skills and fourteen workflow stages, with no new standalone master/pages commands.
+- The README features the complete 2 min 58 s Lisière demonstration and two legible, complementary SVG diagrams for the overall workflow and delivery loop.
+- Documentation, narration, subtitles and the runnable prototype evidence cover framing, visual design, architecture, readiness, implementation, review, verification and local handoff.
+
+Image generation requires an available host tool; it is not bundled. The film contains illustrative commands and real generated images / application interactions, not a continuous Codex Desktop capture. The native pilot does not establish Claude Code or Cursor execution parity. The public CLI does not gain autonomous task dispatch.
+
+## Adopt without overwriting project work
+
+Until publication, use a reviewed GitHub revision:
+
+```sh
+npx --yes --package=github:montassarkhalloufi/DevMethod#<reviewed-commit> devmethod init --tool codex --dest ../devmethod-staging
+```
+
+After the registry confirms publication, the versioned command will be:
+
+```sh
+npx --yes devmethod-ai@0.2.0 init --tool codex --dest ../devmethod-staging
+```
+
+Stage and compare updates. Keep existing project decisions, customized skills, filled profiles and instructions. There is no automatic migration.
+
+## Candidate verification
+
+Local candidate checks passed: locked installation, 72 core tests, 24 greenfield tests, Markdown links, both diagrams rendered in Chrome, package-content inspection and installation smoke from the archive for all three host layouts, including a subset and customization preservation. Exact source revision, final archive digest and platform CI results are recorded in the release PR before publication. Platform installation checks do not prove authenticated agent behavior.
+
+Native workflow evidence is retained in the [Lisière execution record](media/visual-chain/execution.fr.md) and [visual pilot](../examples/visual-pilot/README.md). The release reuses that evidence for the unchanged skills; it does not claim fresh model runs.
+
+Publish only the reviewed archive with an explicit `latest` tag for an authorized final release. After publication, download the registry tarball, compare its integrity and run package smoke again. Keep 0.1.0 available as a rollback reference.

package/docs/ROADMAP.md

@@ -17,6 +17,8 @@ Aim: a compact engineering workflow for verifiable changes in existing repositor
 
 ## What to add only after demand
 
+The [visual creation proposal](VISUAL-CREATION-PROPOSAL.md) scopes a possible direction-selection, mockup and prototype flow into the existing design stage. The procedure is now available through the design stage; see the [pilot record](missions/visual-workflow.md) for validation status. Image generation still requires a host tool.
+
 Additional stack packs, a workflow builder or orchestration should solve repeated problems shown by real projects. The six existing modules remain the core. Do not add persona counts, a dashboard, cloud services or a vector store as proxies for workflow quality.
 
 ## Principles

package/docs/VISUAL-CREATION-PROPOSAL.md

@@ -0,0 +1,21 @@
+# Visual creation proposal
+
+Historical proposal, 2026-09-13. The reusable procedure is now implemented in [visual creation](../.agents/skills/design-to-code/references/visual-creation.md). Follow the [pilot record](missions/visual-workflow.md) for observed execution and outstanding selection/verification; implementation of instructions does not establish end-to-end validation. The existing `design` stage can frame UX; `design-to-code` already describes implementation and fidelity checks against an approved reference. The missing procedure to evaluate is how to create and select that reference when none exists.
+
+## Proposed flow inside the existing design stage
+
+1. Reuse the mission's audience, main journey, constraints and existing brand/assets. Ask only for missing choices that materially affect the direction. Keep a short visual brief in the existing mission/design record.
+2. If no direction is approved, propose two or three genuinely different directions applied to the same key screen and content. For each, show typography, palette, layout density, imagery approach, a short rationale and trade-offs. For a fictional reading app, candidates might be an editorial layout with serif headings, a compact utilitarian library, and an illustrated reading journal; these are examples, not a default style imposed on projects.
+3. Let the user choose or combine directions before detailed production, unless selection was explicitly delegated. Record the chosen version and remaining assumptions in the existing design owner. An established reference skips this exploration.
+4. Produce the selected key screen at desktop/mobile sizes and its necessary empty, loading and error states. When an image tool is available, use its applicable skill for raster concepts, illustrations or image mockups; record the prompt, output path and selected version. An image-generation tool is available in this session, but no images were generated for this proposal. Tool availability depends on the host, not DevMethod installation. Keep precise UI text, tokens and interactions in the design record; a raster mockup cannot prove responsive behavior or accessibility.
+5. Build a small interactive prototype only when navigation, state changes or motion need validation. Use existing project tools and clearly labelled fixture data. Review the main journey, keyboard/focus and mobile behavior. Skip this extra artifact when a static reference already resolves the question.
+6. Pass the selected reference to `design-to-code`: actual assets, screen/version, viewports, tokens, content, states, interactions and criterion IDs. Resolve conflicts between the design record, mockup and product constraints before dependent implementation; do not silently choose the newest artifact.
+7. Render the implementation at the reference dimensions. Attach reference/capture pairs and interaction results to the same criterion evidence rows. Record mismatches, corrections and residual limitations, then invalidate affected visual evidence after changes. A successful build is insufficient for fidelity acceptance.
+
+## Bounded evaluation before adoption
+
+Use one fictional screen and its main interaction, without changing any project studied in a pilot. Success means the user can choose from visible alternatives, the selected reference is versioned and reusable, and the resulting browser UI has criterion-linked visual and interaction evidence. Check resumption from that reference and an intentional mismatch that must be caught. Measure created records, user interventions, elapsed time and exposed usage; do not claim savings without a comparable baseline. Store assets using project conventions and link them from one design owner rather than adding a mandatory document per step.
+
+## Relationship to BMad
+
+The official [Design UX and Architecture](https://docs.bmad-method.org/plan/design-ux-and-architecture/) page, inspected 2026-09-13, documents `bmad-ux`, `DESIGN.md` and `EXPERIENCE.md`, creative directions, wireframes, key-screen mocks and a handoff to external design tools. It also defines conflict precedence for those documents. These are documented capabilities, not behavior evaluated here. Creating visuals is therefore not exclusive to DevMethod; the proposed focus is a compact transition from a chosen reference to criterion-linked fidelity evidence. No superiority claim or comparative benchmark is established.

package/docs/VISUAL-WORKFLOW.md

@@ -0,0 +1,75 @@
+# Create a direction, then build it
+
+The 0.2.0 candidate and current GitHub source include a visual-creation procedure in the existing `design` stage. It preserves six modules and does not install an image service. The published npm `0.1.0` package predates this evolution; reinstalling that version does not obtain it. See the [0.2.0 release record](RELEASE-0.2.0.md) before choosing the installation command.
+
+## Start
+
+From the target repository, install the current reviewed GitHub source into a staging directory:
+
+```sh
+npx --yes --package=github:montassarkhalloufi/DevMethod devmethod init --tool codex --dest ../devmethod-staging
+```
+
+For reproducibility, replace the repository reference with `github:montassarkhalloufi/DevMethod#<reviewed-commit>`. Inspect the staging files and preserve existing instructions and customized profiles during adoption. Claude Code uses `--tool claude`; Cursor uses `--tool cursor`.
+
+In the agent conversation, not the terminal:
+
+```text
+$project-foundation design
+Create a visual direction for [product and audience].
+Show me alternatives, let me choose, then prepare the key screen mockups.
+```
+
+Use `/project-foundation design` in Claude Code or Cursor. An already approved direction skips new alternatives. A brief can specify that the agent chooses the direction if that is what you want.
+
+## What the procedure delivers
+
+1. A brief grounded in the product, audience and supplied references.
+2. Two or three comparable visible directions when the choice is open.
+3. A recorded user choice, or an explicitly delegated selection.
+4. Key-screen image mockups when an image tool is available, with prompts and versioned assets. Missing tooling is reported; an external-tool prompt is not an image.
+5. An interactive prototype for the behavior that needs checking. The prototype may become the implementation.
+6. Browser captures and interaction evidence compared with the approved reference, with mismatches and limitations recorded.
+
+A build passing is not visual acceptance. Image generation is performed by the host's tool, not by the installer. The workflow does not promise identical output across models, hosts or runs.
+
+## Recorded examples
+
+- [Lisière](../examples/visual-pilot/README.md): supervised visual pilot, generated directions, user-selected and approved mockup, implementation and browser checks. This is not an independent end-to-end agent evaluation.
+- [Mission and evidence](missions/visual-workflow.md): scope, checks and known typography/spacing differences.
+
+Source adoption is separate from npm publication. No new npm version is announced by this guide.
+
+## Full filmed chain
+
+The [4K French walkthrough](media/full-chain-4k/README.md) shows actual Codex CLI commands and outputs, the prior approved visual choices, a fresh implementation, review findings, corrections, browser interaction and verification. CLI transcripts are reformatted for legibility; the provenance and limitations are explicit.
+
+## Master screen → images des écrans → application
+
+Le parcours visuel reste dans `design` jusqu'à ce que les visuels demandés soient prêts. « Master » et « pages » désignent le contenu du travail, pas de nouvelles sous-commandes du CLI.
+
+Dans la conversation Codex, on peut envoyer successivement :
+
+```text
+$project-foundation design
+Propose trois directions comparables sur le même écran principal.
+```
+
+```text
+$project-foundation design
+Je choisis A. Finalise le master screen de cette direction.
+```
+
+Après examen et approbation du master :
+
+```text
+$project-foundation design
+Décline ce master approuvé en images des écrans demandés.
+Utilise le fichier du master comme référence visuelle.
+```
+
+Les écrans gardent la typographie, la palette et les composants du master. L'agent examine les résultats, identifie leur référence/version et soumet les ajouts inattendus à validation. Il n'invente pas de routes : bibliothèque, ajout et filtre peuvent être des états d'une seule application.
+
+La suite est `architecture` si des décisions restent nécessaires, puis `plan`, préparation `ready`, `implement`, `review`/`verify` et `integrate`. Les petites tranches peuvent regrouper préparation et réalisation. Les images précèdent l'implémentation qu'elles sont censées guider ; les captures navigateur servent ensuite à la comparaison.
+
+Le [film complet de 2 min 58 s](media/visual-chain/README.md) montre ce passage avec des images réellement générées à partir du master, puis une nouvelle implémentation. Il poursuit avec les choix d’architecture et de technologies, la préparation, l’implémentation, la revue, la vérification et la livraison locale. La génération exige un outil d'image disponible dans l'agent ; DevMethod fournit les instructions du parcours, pas un moteur d'image intégré au paquet npm.

package/docs/images/devmethod-delivery.svg

@@ -0,0 +1,10 @@
+<svg xmlns="http://www.w3.org/2000/svg" width="1200" height="650" viewBox="0 0 1200 650" role="img" aria-labelledby="title desc">
+<title id="title">DevMethod delivery loop</title><desc id="desc">Accepted scope, design and architecture guide implementation. Review and verification either justify delivery or return work to correction. A blocked slice keeps a handoff record.</desc>
+<defs><marker id="arrow" markerWidth="8" markerHeight="8" refX="6" refY="3" orient="auto"><path d="M0 0L6 3L0 6" fill="#ddac86"/></marker></defs>
+<rect width="1200" height="650" rx="28" fill="#10272b"/><g font-family="Arial, sans-serif">
+<text x="52" y="65" fill="#eeb88e" font-size="16" letter-spacing="3">DEVMETHOD / THE DELIVERY LOOP</text><text x="52" y="117" fill="#fff9ef" font-size="36" font-weight="700">A finished slice needs evidence</text>
+<text x="52" y="154" fill="#b9ccc4" font-size="20">Design approval guides the work. Tests and browser checks verify the result.</text>
+<rect x="52" y="203" width="320" height="157" rx="16" fill="#1a363a" stroke="#49615e"/><text x="74" y="250" fill="#fff9ef" font-size="24" font-weight="700">Accepted references</text><text x="74" y="293" fill="#c6d7ce" font-size="18">Scope · design · architecture</text><text x="74" y="325" fill="#c6d7ce" font-size="18">Plan and readiness</text><rect x="440" y="203" width="320" height="157" rx="16" fill="#1a363a" stroke="#49615e"/><text x="462" y="250" fill="#fff9ef" font-size="24" font-weight="700">Implement and review</text><text x="462" y="293" fill="#c6d7ce" font-size="18">Build the real interactions</text><text x="462" y="325" fill="#c6d7ce" font-size="18">Review code, risks and tests</text><rect x="828" y="203" width="320" height="157" rx="16" fill="#1a363a" stroke="#49615e"/><text x="850" y="250" fill="#fff9ef" font-size="24" font-weight="700">Verify the result</text><text x="850" y="293" fill="#c6d7ce" font-size="18">Run the agreed checks</text><text x="850" y="325" fill="#c6d7ce" font-size="18">Compare UI with the design</text><g stroke="#ddac86" stroke-width="3" fill="none" marker-end="url(#arrow)"><path d="M378 281h54"/><path d="M766 281h54"/><path d="M988 365v75"/><path d="M600 450v-78"/><path d="M930 365v40H210v35"/></g>
+<rect x="828" y="452" width="320" height="117" rx="16" fill="#24483f" stroke="#74b49a"/><text x="850" y="490" fill="#fff9ef" font-size="23" font-weight="700">Checks pass → deliver</text><text x="850" y="526" fill="#c6d7ce" font-size="18">Integrate within permissions</text><text x="850" y="552" fill="#c6d7ce" font-size="18">Record evidence and handoff</text>
+<rect x="52" y="452" width="708" height="117" rx="16" fill="#3b3531" stroke="#ddac86"/><text x="74" y="491" fill="#fff9ef" font-size="23" font-weight="700">Failed check or changed constraint → correct</text><text x="74" y="526" fill="#decbbb" font-size="18">Fix the slice or revisit the affected design / architecture decision.</text><text x="74" y="552" fill="#decbbb" font-size="18">If blocked, preserve a checkpoint; do not mark the slice delivered.</text>
+<text x="52" y="616" fill="#b9ccc4" font-size="18">status / next resume from the evidence; they do not create an autonomous backlog.</text></g></svg>

package/docs/images/devmethod-flow.svg

@@ -1,26 +1,13 @@
-<svg xmlns="http://www.w3.org/2000/svg" width="1200" height="420" viewBox="0 0 1200 420" role="img" aria-labelledby="title desc">
-  <title id="title">DevMethod workflow</title>
-  <desc id="desc">A project moves from clarity through a verified delivery to a reusable checkpoint.</desc>
-  <rect width="1200" height="420" rx="28" fill="#0b1020"/>
-  <text x="72" y="86" fill="#ffffff" font-family="Arial, sans-serif" font-size="38" font-weight="700">From an idea to a verified delivery</text>
-  <text x="72" y="124" fill="#aeb9d7" font-family="Arial, sans-serif" font-size="20">DevMethod keeps decisions, implementation and evidence connected.</text>
-  <g font-family="Arial, sans-serif">
-    <rect x="72" y="190" width="290" height="144" rx="20" fill="#182347" stroke="#7190ff" stroke-width="2"/>
-    <circle cx="116" cy="234" r="20" fill="#7190ff"/><text x="108" y="241" fill="#0b1020" font-size="18" font-weight="700">1</text>
-    <text x="154" y="240" fill="#fff" font-size="25" font-weight="700">Make it clear</text>
-    <text x="104" y="286" fill="#c8d2ef" font-size="18">Explore · frame · design</text>
-    <text x="104" y="314" fill="#c8d2ef" font-size="18">Architecture · plan · ready</text>
-    <path d="M390 262h88" stroke="#7190ff" stroke-width="5" stroke-linecap="round"/><path d="M468 250l22 12-22 12" fill="#7190ff"/>
-    <rect x="512" y="190" width="290" height="144" rx="20" fill="#182347" stroke="#4dd6ad" stroke-width="2"/>
-    <circle cx="556" cy="234" r="20" fill="#4dd6ad"/><text x="548" y="241" fill="#0b1020" font-size="18" font-weight="700">2</text>
-    <text x="594" y="240" fill="#fff" font-size="25" font-weight="700">Build the slice</text>
-    <text x="544" y="286" fill="#c8d2ef" font-size="18">Implement · test · review</text>
-    <text x="544" y="314" fill="#c8d2ef" font-size="18">Correct when evidence fails</text>
-    <path d="M830 262h88" stroke="#4dd6ad" stroke-width="5" stroke-linecap="round"/><path d="M908 250l22 12-22 12" fill="#4dd6ad"/>
-    <rect x="952" y="190" width="176" height="144" rx="20" fill="#182347" stroke="#ffcf5b" stroke-width="2"/>
-    <circle cx="996" cy="234" r="20" fill="#ffcf5b"/><text x="988" y="241" fill="#0b1020" font-size="18" font-weight="700">3</text>
-    <text x="984" y="240" fill="#fff" font-size="23" font-weight="700">Prove it</text>
-    <text x="984" y="286" fill="#c8d2ef" font-size="17">Verify · integrate</text>
-    <text x="984" y="314" fill="#c8d2ef" font-size="17">Handoff · next</text>
-  </g>
-</svg>
+<svg xmlns="http://www.w3.org/2000/svg" width="1200" height="720" viewBox="0 0 1200 720" role="img" aria-labelledby="title desc">
+<title id="title">DevMethod: from idea to verified delivery</title><desc id="desc">Six stages connect product scope, visual design, architecture, planning, implementation and verified delivery. Revisit decisions when evidence changes.</desc>
+<rect width="1200" height="720" rx="28" fill="#10272b"/>
+<g font-family="Arial, sans-serif"><text x="52" y="64" fill="#eeb88e" font-size="16" letter-spacing="3">DEVMETHOD / THE COMPLETE WORKFLOW</text>
+<text x="52" y="119" fill="#fff9ef" font-size="38" font-weight="700">From an idea to a verified product</text>
+<text x="52" y="157" fill="#b9ccc4" font-size="20">Make the decisions visible. Build a useful slice. Check the result.</text>
+<rect x="52" y="202" width="352" height="183" rx="16" fill="#1a363a" stroke="#49615e"/><text x="76" y="237" fill="#eeb88e" font-size="17" font-weight="700">01</text><text x="76" y="278" fill="#fff9ef" font-size="23" font-weight="700">Understand the product</text><text x="76" y="316" fill="#eeb88e" font-size="18">Explore · frame</text><text x="76" y="350" fill="#c6d7ce" font-size="17">Users, scope and success criteria</text>
+<rect x="424" y="202" width="352" height="183" rx="16" fill="#1a363a" stroke="#49615e"/><text x="448" y="237" fill="#eeb88e" font-size="17" font-weight="700">02</text><text x="448" y="278" fill="#fff9ef" font-size="23" font-weight="700">Design the experience</text><text x="448" y="316" fill="#eeb88e" font-size="18">Design</text><text x="448" y="350" fill="#c6d7ce" font-size="17">Directions → master → screens</text>
+<rect x="796" y="202" width="352" height="183" rx="16" fill="#1a363a" stroke="#49615e"/><text x="820" y="237" fill="#eeb88e" font-size="17" font-weight="700">03</text><text x="820" y="278" fill="#fff9ef" font-size="23" font-weight="700">Choose the architecture</text><text x="820" y="316" fill="#eeb88e" font-size="18">Architecture</text><text x="820" y="350" fill="#c6d7ce" font-size="17">Technologies, boundaries, trade-offs</text>
+<rect x="52" y="409" width="352" height="183" rx="16" fill="#1a363a" stroke="#49615e"/><text x="76" y="444" fill="#eeb88e" font-size="17" font-weight="700">04</text><text x="76" y="485" fill="#fff9ef" font-size="23" font-weight="700">Prepare a useful slice</text><text x="76" y="523" fill="#eeb88e" font-size="18">Plan · ready</text><text x="76" y="557" fill="#c6d7ce" font-size="17">Dependencies and acceptance checks</text>
+<rect x="424" y="409" width="352" height="183" rx="16" fill="#1a363a" stroke="#49615e"/><text x="448" y="444" fill="#eeb88e" font-size="17" font-weight="700">05</text><text x="448" y="485" fill="#fff9ef" font-size="23" font-weight="700">Build and improve</text><text x="448" y="523" fill="#eeb88e" font-size="18">Implement · review</text><text x="448" y="557" fill="#c6d7ce" font-size="17">Working behavior, tests and fixes</text>
+<rect x="796" y="409" width="352" height="183" rx="16" fill="#1a363a" stroke="#49615e"/><text x="820" y="444" fill="#eeb88e" font-size="17" font-weight="700">06</text><text x="820" y="485" fill="#fff9ef" font-size="23" font-weight="700">Verify and deliver</text><text x="820" y="523" fill="#eeb88e" font-size="18">Verify · integrate · handoff</text><text x="820" y="557" fill="#c6d7ce" font-size="17">Evidence, delivery and resumption</text>
+<path d="M52 630h1096" stroke="#49615e"/><text x="52" y="664" fill="#c6d7ce" font-size="18">Adapt the depth to the project. Revisit decisions when constraints or checks change.</text><text x="52" y="694" fill="#9fb8af" font-size="16">Skill guidance for your coding agent · Image generation requires an available host tool.</text></g></svg>

package/docs/media/from-zero/README.md

@@ -0,0 +1,17 @@
+# DevMethod — French demonstration video
+
+[Watch/download the MP4](https://github.com/montassarkhalloufi/DevMethod/raw/refs/heads/main/docs/media/from-zero/devmethod-demo.fr.mp4) · [French subtitles](devmethod-demo.fr.srt) · [Narration and scenes](scenes.json)
+
+A short promotional/explanatory video: product promise, an actual from-zero Clair agent trial, real recorded browser interactions, the separate Lisière visual pilot, verification and a GitHub call to action. The explanatory cards summarize work; they are not a recording of every development step.
+
+The French narration is synthetic system speech (Thomas). No music, testimonials, customer results or comparative savings are invented. App records and generated book covers are fictional. The visible Lisière art-direction board is AI-generated; Clair's interface is implemented HTML/CSS. The source workflow is newer than npm 0.1.0; use the [source guide](../../VISUAL-WORKFLOW.md).
+
+## Reproduce
+
+Requires macOS `say` with Thomas, ffmpeg/ffprobe, Chrome and an installed Playwright module. Start Clair on localhost:8766 using the example README. From the repository root, run `node scripts/media/record-demo.cjs` (set PLAYWRIGHT_MODULE if needed), then `python3 scripts/media/encode-demo.py`. The narration text/timing lives in scenes.json. The recorder saves intermediate clips under /private/tmp/devmethod-video; the encoder writes MP4 and SRT here. Do not reuse old intermediate speech files after editing the narration.
+
+[Desktop capture](https://github.com/montassarkhalloufi/DevMethod/raw/refs/heads/main/docs/media/from-zero/captures/clair-desktop.png) and [mobile capture](https://github.com/montassarkhalloufi/DevMethod/raw/refs/heads/main/docs/media/from-zero/captures/clair-mobile.png) are browser evidence. Tests validate selected behavior, not all accessibility, platforms or deployment conditions. See the [example report](../../../examples/clair-from-zero/README.md).
+
+## Verification record
+
+Final MP4: 1280×720 H.264, AAC narration, French mov_text subtitle track; approximately 70.5 seconds, 2.5 MB. Scene screenshots and an encoded interaction frame were visually inspected. Audio is non-silent (mean -15.7 dB, peak -0.4 dB); no claim of a full human listening review. Six Clair logic/storage tests and the independent browser journey passed. The suite disables animation for evidence screenshots.