devmethod-ai 0.1.0 → 0.3.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.agents/skills/decision-architecture/SKILL.md +10 -0
- package/.agents/skills/decision-architecture/assets/ADR.md +6 -3
- package/.agents/skills/design-to-code/SKILL.md +7 -1
- package/.agents/skills/design-to-code/references/visual-creation.md +37 -0
- package/.agents/skills/project-foundation/SKILL.md +3 -1
- package/.agents/skills/project-foundation/assets/CADRAGE.md +11 -0
- package/.agents/skills/project-foundation/assets/EXISTANT.md +14 -0
- package/.agents/skills/project-foundation/assets/OPPORTUNITES.md +10 -0
- package/.agents/skills/project-foundation/assets/PROJECT_PROFILE.md +4 -2
- package/.agents/skills/project-foundation/assets/REGLES.md +6 -0
- package/.agents/skills/project-foundation/assets/START_HERE.md +2 -0
- package/.agents/skills/project-foundation/references/delivery-planning.md +11 -0
- package/.agents/skills/project-foundation/references/exploration.md +11 -0
- package/.agents/skills/project-foundation/references/mission-context.md +37 -0
- package/.agents/skills/project-foundation/references/operating-commands.md +26 -6
- package/.agents/skills/project-foundation/references/work-sizing.md +1 -1
- package/.agents/skills/scoped-delivery/SKILL.md +6 -0
- package/.agents/skills/scoped-delivery/assets/MISSION.md +18 -1
- package/.agents/skills/scoped-delivery/assets/PLAN.md +20 -0
- package/.agents/skills/scoped-delivery/assets/REPRISE.md +10 -0
- package/.agents/skills/scoped-delivery/assets/REVIEW.md +34 -0
- package/.agents/skills/scoped-delivery/assets/SLICE.md +5 -0
- package/.agents/skills/scoped-delivery/assets/TICKET.md +21 -0
- package/.agents/skills/scoped-delivery/references/review-workflow.md +29 -0
- package/COMPATIBILITY.md +1 -1
- package/README.md +46 -17
- package/START_HERE.md +2 -0
- package/dist/cli.js +122 -90
- package/dist/review-app.js +462 -0
- package/dist/review-browser.js +567 -0
- package/dist/review-cli.js +68 -0
- package/dist/review-model.js +101 -0
- package/dist/review-open.js +19 -0
- package/dist/review-ui.css +782 -0
- package/dist/review.js +13 -0
- package/docs/ADR-007-conversation-and-mission-ownership.md +13 -0
- package/docs/ADR-008-review-presentation.md +13 -0
- package/docs/MISSIONS.md +2 -0
- package/docs/RELEASE-0.1.0.md +14 -3
- package/docs/RELEASE-0.2.0.md +48 -0
- package/docs/RELEASE-0.3.0.md +24 -0
- package/docs/REVIEW-SOURCES.md +13 -0
- package/docs/REVIEW-VALIDATION.md +34 -0
- package/docs/REVIEWS.md +75 -0
- package/docs/ROADMAP.md +2 -0
- package/docs/VISUAL-CREATION-PROPOSAL.md +21 -0
- package/docs/VISUAL-WORKFLOW.md +75 -0
- package/docs/WORKFLOW-0.3-VALIDATION.md +32 -0
- package/docs/WORKFLOW-0.3.md +34 -0
- package/docs/images/devmethod-delivery.svg +10 -0
- package/docs/images/devmethod-flow.svg +13 -26
- package/docs/images/review-interface-desktop.jpg +0 -0
- package/docs/images/review-interface-mobile.jpg +0 -0
- package/docs/media/from-zero/README.md +17 -0
- package/docs/media/from-zero/devmethod-demo.fr.srt +59 -0
- package/docs/media/from-zero/scenes.json +50 -0
- package/docs/media/full-chain-4k/README.md +37 -0
- package/docs/media/full-chain-4k/devmethod-chaine-complete.fr.srt +435 -0
- package/docs/media/full-chain-4k/scenes.json +173 -0
- package/docs/media/full-chain-4k/transcripts.fr.md +315 -0
- package/docs/media/visual-chain/README.md +44 -0
- package/docs/media/visual-chain/assets/add-book-v1.png +0 -0
- package/docs/media/visual-chain/assets/completed-v1.png +0 -0
- package/docs/media/visual-chain/devmethod-du-besoin-au-produit.fr.srt +147 -0
- package/docs/media/visual-chain/execution.fr.md +30 -0
- package/docs/media/visual-chain/image-prompts.json +9 -0
- package/docs/media/visual-chain/reference-hashes.json +5 -0
- package/docs/media/visual-chain/scenes.json +232 -0
- package/docs/media/visual-chain/video-preview.jpg +0 -0
- package/docs/missions/visual-workflow.md +46 -0
- package/docs/missions/workflow-0.3-reviews/interface/REVIEW.md +109 -0
- package/docs/missions/workflow-0.3-reviews/interface/review.json +255 -0
- package/docs/missions/workflow-0.3.md +17 -0
- package/examples/clair-from-zero/AGENT-EVALUATION.md +15 -0
- package/examples/clair-from-zero/MISSION.md +41 -0
- package/examples/clair-from-zero/README.md +24 -0
- package/examples/clair-from-zero/app/app.mjs +69 -0
- package/examples/clair-from-zero/app/domain.mjs +30 -0
- package/examples/clair-from-zero/app/index.html +20 -0
- package/examples/clair-from-zero/app/storage.mjs +4 -0
- package/examples/clair-from-zero/app/styles.css +128 -0
- package/examples/clair-from-zero/browser-check.cjs +2 -0
- package/examples/clair-from-zero/tests/domain.test.mjs +37 -0
- package/examples/mission-dialogue/PROJECT_PROFILE.md +9 -0
- package/examples/mission-dialogue/architecture/decisions/001-storage.md +7 -0
- package/examples/mission-dialogue/docs/missions/first-save/PLAN.md +13 -0
- package/examples/mission-dialogue/docs/missions/first-save/REPRISE.md +6 -0
- package/examples/mission-dialogue/docs/missions/first-save/tickets/SAVE-1.md +14 -0
- package/examples/mission-dialogue/docs/missions/legacy-copy.md +9 -0
- package/examples/mission-dialogue/docs/produit/REGLES.md +5 -0
- package/examples/review/review.json +199 -0
- package/examples/visual-pilot/README.md +11 -0
- package/examples/visual-pilot/app/app.js +10 -0
- package/examples/visual-pilot/app/index.html +1 -0
- package/examples/visual-pilot/app/reference.png +0 -0
- package/examples/visual-pilot/app/style.css +3 -0
- package/examples/visual-pilot/browser-check.cjs +3 -0
- package/examples/visual-pilot/desktop-actual.png +0 -0
- package/examples/visual-pilot/directions-prompt.txt +1 -0
- package/examples/visual-pilot/directions-v1.png +0 -0
- package/examples/visual-pilot/editorial-mockup-prompt.txt +1 -0
- package/examples/visual-pilot/editorial-mockup-v1.png +0 -0
- package/examples/visual-pilot/mismatch-probe.png +0 -0
- package/examples/visual-pilot/mobile-actual.png +0 -0
- package/examples/visual-pilot/quick-filter/AGENT-RESULT.md +25 -0
- package/examples/visual-pilot/quick-filter/baseline.log +42 -0
- package/examples/visual-pilot/quick-filter/filter.mjs +3 -0
- package/examples/visual-pilot/quick-filter/filter.test.mjs +9 -0
- package/package.json +3 -3
- package/scripts/build-review.mjs +8 -0
- package/scripts/media/demo-actions.cjs +16 -0
- package/scripts/media/encode-demo.py +22 -0
- package/scripts/media/record-demo.cjs +30 -0
- package/scripts/media/visual-short/check.cjs +1 -0
- package/scripts/media/visual-short/encode.py +16 -0
- package/scripts/media/visual-short/record.cjs +4 -0
- package/scripts/media/visual-short/story.py +34 -0
- package/scripts/package-smoke.mjs +16 -3
package/dist/review.js
ADDED
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
import fs from 'node:fs';
|
|
2
|
+
import { createHash } from 'node:crypto';
|
|
3
|
+
import { sanitizedReview, redactReviewText } from './review-model.js';
|
|
4
|
+
export function renderReviewHTML(input) {
|
|
5
|
+
const review = input.review == null ? null : sanitizedReview(input.review);
|
|
6
|
+
const legacy = input.legacy == null ? null : redactReviewText(input.legacy);
|
|
7
|
+
const script = fs.readFileSync(new URL('./review-browser.js', import.meta.url), 'utf8');
|
|
8
|
+
const css = fs.readFileSync(new URL('./review-ui.css', import.meta.url), 'utf8');
|
|
9
|
+
const scriptHash = createHash('sha256').update(script).digest('base64');
|
|
10
|
+
const payload = JSON.stringify({ review, legacy, currentRevision: input.currentRevision ?? null, changedTargets: input.changedTargets ?? [] }).replace(/</g, '\\u003c').replace(/>/g, '\\u003e').replace(/&/g, '\\u0026');
|
|
11
|
+
return `<!doctype html>
|
|
12
|
+
<html lang="fr"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1"><meta name="referrer" content="no-referrer"><meta http-equiv="Content-Security-Policy" content="default-src 'none'; script-src 'sha256-${scriptHash}'; style-src 'unsafe-inline'; img-src data:; connect-src 'none'; font-src 'none'; object-src 'none'; base-uri 'none'; form-action 'none'"><title>DevMethod · Review</title><style>${css}</style></head><body><div id="app"><p class="loading">Chargement de la review…</p></div><noscript>Activez JavaScript pour les filtres et la consultation. Le rapport Markdown reste disponible via le CLI.</noscript><script id="review-data" type="application/json">${payload}</script><script>${script}</script></body></html>\n`;
|
|
13
|
+
}
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
# ADR 007: Conversation before commitment and single-owner mission records
|
|
2
|
+
|
|
3
|
+
Status: accepted for this implementation, 2026-09-13, under the user's explicit specification and authorization to implement and release this scope.
|
|
4
|
+
|
|
5
|
+
The request explicitly selects research before product commitment, conversational structural decisions, delivery-scope discussion and a proposed multi-file mission layout. It preserves approved design, existing trackers, lightweight fixes and legacy missions. These requirements settle this kit change; they do not delegate future adopters' product decisions.
|
|
6
|
+
|
|
7
|
+
Keep guidance and Markdown templates in the six existing skills. An executable decision state machine or automatic tracker migration would add schemas, commands and compatibility risk without meeting a requested runtime need. A single larger mission template alone would retain ownership ambiguity for substantial work. Use PLAN for mission goals/order, tickets for task state and evidence, REPRISE for a dated handoff; link other domain owners. Preserve the legacy template and optional JSON schemas.
|
|
8
|
+
|
|
9
|
+
The installer already walks Markdown assets and references, profiles host paths and hashes the complete selected payload. New resources require distribution regression tests, not installer logic changes. The initial scope extended CLI help to distinguish model stages from offline JSON inspectors. The subsequently authorized review interface adds its own result/presentation contract; this does not change the mission/context schemas. No changes to the design module or its approved directions.
|
|
10
|
+
|
|
11
|
+
The inspected downstream correction established the need for conversation before architecture detail and explicit choice/delegation, not merely a PROPOSED ADR. Integrate that generic intent with the requested constraints and planning rules, without downstream project facts.
|
|
12
|
+
|
|
13
|
+
Revisit if real adoption reveals unresolved ownership, missing resources in host subsets, migration friction or repeated conversational failures. Automated content/distribution checks cannot certify model behavior; record scenario walkthroughs separately from fresh native-host transcripts.
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
# ADR 008: Versioned review results and local presentation
|
|
2
|
+
|
|
3
|
+
Status: accepted through explicit user delegation, 2026-09-13.
|
|
4
|
+
|
|
5
|
+
The user explicitly requested a versioned validated review record, common derived counters/report/interface, safe local browser consultation from the npm package, legacy Markdown support and the supplied visual direction. The existing kit accepts strict TypeScript, Node.js >=22, no runtime dependencies, offline operation and no automatic migrations.
|
|
6
|
+
|
|
7
|
+
The implemented shared components are independent of the final opening mode: a pure format-1 model/validator used by Node and the browser, derived Markdown, and an HTML rendering with bundled CSS/program/data. The CLI can generate that required report artifact. It does not execute checks or read arbitrary evidence paths. Explicit reviewed raster data and HTTPS navigation avoid exposing the project filesystem. Text is rendered as text; CSP pins the shipped program. Legacy Markdown stays historical text.
|
|
8
|
+
|
|
9
|
+
The decision brief was presented in conversation: a self-contained HTML report is portable and offline, requires no service lifecycle and matches existing dependency constraints. A loopback server is an alternative for future live refresh and controlled local-resource access, but adds process, route and filesystem security responsibilities. Recommendation: self-contained HTML for this release, with snapshot freshness and deliberately included evidence; revisit if real usage requires live refresh or local evidence linking. No account, external hosting or dashboard scope is introduced.
|
|
10
|
+
|
|
11
|
+
The user explicitly delegated this choice in conversation (“je te delegue le choix”), on 2026-09-13. Under that delegation, select the self-contained offline HTML report. `review --output report.html --open` requests opening through the operating system's browser handler, with fixed executable/argument boundaries and no shell. Opening failure preserves the generated report and explains manual recovery. No server is needed. Revisit this decision if live refresh or controlled local evidence access becomes an actual requirement.
|
|
12
|
+
|
|
13
|
+
Browser verification found and corrected a real focus-loss defect. Direct file:// reopening is blocked by the browser tool's URL policy; that limitation remains recorded, without a workaround or a claim of successful offline-browser reopening. The opening adapter is checked without launching a browser; the remaining offline reopening limitation must stay explicit in release evidence. Publication follows the authorized repository gates.
|
package/docs/MISSIONS.md
CHANGED
|
@@ -2,6 +2,8 @@
|
|
|
2
2
|
|
|
3
3
|
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.
|
|
4
4
|
|
|
5
|
+
For storage, status ownership and criterion-to-review links, follow [mission context](../.agents/skills/project-foundation/references/mission-context.md). Prefer existing conventions; substantial work without conventions uses a proposed `docs/missions/<mission-id>/PLAN.md`, `tickets/<ticket-id>.md` and dated `REPRISE.md`, with `preuves/` only when useful. Existing single-file `docs/missions/<mission-id>.md` records remain supported. See [migration and ownership](WORKFLOW-0.3.md). This is guidance for the agent, not a new CLI tracker, auto-discovery path or schema validation feature.
|
|
6
|
+
|
|
5
7
|
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.
|
|
6
8
|
|
|
7
9
|
## Source-checkout quick start
|
package/docs/RELEASE-0.1.0.md
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# DevMethod 0.1.0
|
|
2
2
|
|
|
3
|
-
Status: PRs #6–#10 merged; integrated
|
|
3
|
+
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.
|
|
4
4
|
|
|
5
5
|
## Supported release scope
|
|
6
6
|
|
|
@@ -30,11 +30,11 @@ For an existing project, stage the installation, complete the project profile fr
|
|
|
30
30
|
|
|
31
31
|
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.
|
|
32
32
|
|
|
33
|
-
|
|
33
|
+
Install the verified published version with `npx --yes devmethod-ai@0.1.0 init --tool codex --dest ../devmethod-staging`.
|
|
34
34
|
|
|
35
35
|
## Validation record
|
|
36
36
|
|
|
37
|
-
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.
|
|
37
|
+
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.
|
|
38
38
|
|
|
39
39
|
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.
|
|
40
40
|
|
|
@@ -47,3 +47,14 @@ For a reviewed final version, publish the exact verified archive rather than rep
|
|
|
47
47
|
## From-zero application validation
|
|
48
48
|
|
|
49
49
|
[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.
|
|
50
|
+
|
|
51
|
+
## Exact final artifact (2026-09-13)
|
|
52
|
+
|
|
53
|
+
- Source: `24a909b2e1293e46683960b7b127e17f29fbf74a`.
|
|
54
|
+
- [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.
|
|
55
|
+
- [Fullstack CI](https://github.com/montassarkhalloufi/DevMethod/actions/runs/34749164119): Next.js/NestJS/PostgreSQL checks succeeded on the same revision.
|
|
56
|
+
- `devmethod-ai-0.1.0.tgz`: 174 files; SHA-256 `2962fab73686f54ebbaa6b084cc6f1ef2f11db26a61feb85c633174247149d05`.
|
|
57
|
+
- npm SHA-1: `810337a9da52d711ae2465c57480879aadbf2d0a`.
|
|
58
|
+
- npm integrity: `sha512-bNyJ4to76YUZNvV0xrCIKzBqqh8QqcmtvMVCOx6CsCav0w3h0L/DUHdDpx2VLl/zePa2Eyg7ho8SOvlQOOz/Qg==`.
|
|
59
|
+
|
|
60
|
+
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.
|
|
@@ -0,0 +1,48 @@
|
|
|
1
|
+
# DevMethod 0.2.0 — visual design through verified delivery
|
|
2
|
+
|
|
3
|
+
Status: published on npm as `devmethod-ai@0.2.0` under `latest`. The registry archive matches the reviewed candidate and passed package smoke after publication.
|
|
4
|
+
|
|
5
|
+
## Changes
|
|
6
|
+
|
|
7
|
+
- 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.
|
|
8
|
+
- 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.
|
|
9
|
+
- 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.
|
|
10
|
+
- 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.
|
|
11
|
+
- Documentation, narration, subtitles and the runnable prototype evidence cover framing, visual design, architecture, readiness, implementation, review, verification and local handoff.
|
|
12
|
+
|
|
13
|
+
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.
|
|
14
|
+
|
|
15
|
+
## Adopt without overwriting project work
|
|
16
|
+
|
|
17
|
+
To pin a reviewed GitHub revision:
|
|
18
|
+
|
|
19
|
+
```sh
|
|
20
|
+
npx --yes --package=github:montassarkhalloufi/DevMethod#<reviewed-commit> devmethod init --tool codex --dest ../devmethod-staging
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
Install the published version:
|
|
24
|
+
|
|
25
|
+
```sh
|
|
26
|
+
npx --yes devmethod-ai@0.2.0 init --tool codex --dest ../devmethod-staging
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
Stage and compare updates. Keep existing project decisions, customized skills, filled profiles and instructions. There is no automatic migration.
|
|
30
|
+
|
|
31
|
+
## Candidate verification
|
|
32
|
+
|
|
33
|
+
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.
|
|
34
|
+
|
|
35
|
+
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.
|
|
36
|
+
|
|
37
|
+
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.
|
|
38
|
+
|
|
39
|
+
## Exact published artifact — 2026-09-13
|
|
40
|
+
|
|
41
|
+
- Release preparation and review: [PR #17](https://github.com/montassarkhalloufi/DevMethod/pull/17), merged as `f374c5a02f2e339c47e126a8f8e5c2f28d785f9d`.
|
|
42
|
+
- [Platform CI](https://github.com/montassarkhalloufi/DevMethod/actions/runs/34767104314): Linux, macOS and Windows passed.
|
|
43
|
+
- [Fullstack CI](https://github.com/montassarkhalloufi/DevMethod/actions/runs/34767104287): passed.
|
|
44
|
+
- Archive: `devmethod-ai-0.2.0.tgz`, 230 files. SHA-256: `f8fa3ffe9c6d9cb0072dd3540a016dd8d36a582bde386a816eb5bd9bda0eca07`.
|
|
45
|
+
- npm SHA-1: `5e40705ce120987e3e3c271d1d00bca1a5be39a3`.
|
|
46
|
+
- npm integrity: `sha512-vV6DGt8v6xu6p42s7IaGKPPwcOMTBuUnH97E8W+FR809YFQtUw+n1hTZdoF3+5bq8tAvyslYMNGzAuBQ8bXVTg==`.
|
|
47
|
+
|
|
48
|
+
After browser authentication, npm confirmed publication. The fresh registry download matched the reviewed archive byte for byte and passed installation smoke for all host layouts, subset installation, preservation of customizations and context/planning checks. The `latest` tag is 0.2.0; 0.1.0 remains available. This post-publication record is not inside the immutable published archive.
|
|
@@ -0,0 +1,24 @@
|
|
|
1
|
+
# DevMethod 0.3.0 — research and decisions before commitment
|
|
2
|
+
|
|
3
|
+
Release scope: 0.3.0. Offline HTML was selected under explicit user delegation in [ADR 008](ADR-008-review-presentation.md). GitHub and npm provide publication status.
|
|
4
|
+
|
|
5
|
+
Open the packaged demo: `npx devmethod-ai@0.3.0 review --demo --output review-demo.html --open`.
|
|
6
|
+
|
|
7
|
+
This minor release extends the workflow and its distributed resources while retaining the public CLI contracts, six skills, fourteen stages, JSON schemas and existing mission compatibility. The exact publication and CI evidence is recorded in the release PR and GitHub release; package metadata alone is not proof of publication.
|
|
8
|
+
|
|
9
|
+
- explore researches existing solutions proportionately, traces dated sources, distinguishes claims and hypotheses, and discusses what to do next.
|
|
10
|
+
- architecture presents credible options and recommendations in conversation before dependent detail; explicit choice or scoped delegation is recorded. Open decisions keep plans conditional.
|
|
11
|
+
- plan discusses useful delivery scope, learning, trade-offs and uncertain effort before tickets; milestones carry demonstrations, exit criteria and authorized continuation.
|
|
12
|
+
- New optional research/product and PLAN/TICKET/REPRISE templates provide one owner per fact, progressive reading and ticket-owned verification. Existing single-file missions and trackers remain supported.
|
|
13
|
+
- Review adds official-source/version-aware inspection guidance, validated format-1 results, derived Markdown and a functional local browser viewer. Findings and checks remain distinct; the viewer covers search/filters, evidence, coverage, source provenance, exports, responsive keyboard navigation and historical/invalid states.
|
|
14
|
+
- The design module and approved visual workflow remain unchanged. Installer resource discovery and integrity manifest formats stay compatible; the new review CLI presents results without executing repository checks. See [review usage and limits](REVIEWS.md).
|
|
15
|
+
|
|
16
|
+
## Adoption and migration
|
|
17
|
+
|
|
18
|
+
Use `npx --yes devmethod-ai@0.3.0 init --tool codex --dest ../devmethod-staging` after registry publication; choose claude or cursor as needed. Compare staged files and update-preview results before adoption. Do not overwrite divergent skills, profiles or existing instructions. See [explicit migration steps](WORKFLOW-0.3.md#non-destructive-migration). No migration or empty project document creation runs automatically.
|
|
19
|
+
|
|
20
|
+
## Verification and limits
|
|
21
|
+
|
|
22
|
+
Required local checks: locked install, complete test suite/build, greenfield tests, local Markdown links, committed build drift, actual package inspection and smoke from its archive. Platform CI validates installation on Linux, macOS and Windows and runs the fullstack fixture. These do not certify coding-agent behavior.
|
|
23
|
+
|
|
24
|
+
The [scenario record](WORKFLOW-0.3-VALIDATION.md) is an authored workflow walkthrough plus manual inspection, not fresh native-host transcripts. No native-host parity or comparative improvement claim is made. Keep 0.2.0 available as a rollback reference. Publication uses the reviewed archive and explicit latest tag; no CI publishing workflow exists.
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
# Sources inspected for the review interface
|
|
2
|
+
|
|
3
|
+
Consulted 2026-09-13. Installed compiler: TypeScript 5.9.3; @types/node 22.20.2 (package-lock.json). Package baseline Node.js >=22, CI Node.js 22; local runtime Node.js 24.18.0. Keep NodeNext/ES2022 and existing strictness; no version migration is required.
|
|
4
|
+
|
|
5
|
+
| Source | Publisher / provenance | Applicable version and use | Limits |
|
|
6
|
+
|---|---|---|---|
|
|
7
|
+
| [Node filesystem documentation](https://nodejs.org/download/release/v22.17.0/docs/api/fs.html) | Node.js official site | Node 22 baseline, bounded regular-file reads and exclusive output creation | Path validation remains application responsibility; not a concurrency sandbox |
|
|
8
|
+
| [TypeScript 5.9 notes](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-9.html) | TypeScript official site | Installed 5.9.3; preserve project NodeNext configuration and DOM typing | Newer compiler documentation is not a migration requirement |
|
|
9
|
+
| [DOM textContent](https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent) | MDN Web Docs, web-platform documentation | Text rendering of untrusted report content | Setting safe text does not validate navigation destinations |
|
|
10
|
+
| [Tabs pattern](https://www.w3.org/WAI/ARIA/apg/patterns/tabs/) | W3C WAI | Keyboard focus, selection and panel association | Authoring guidance, not proof of an accessibility audit |
|
|
11
|
+
| [TypeScript maintainer skills](https://github.com/microsoft/TypeScript-Maintainer-Skills) | Microsoft-owned repository; inspected README and intended scope | Compiler-issue maintenance, not a general application review skill | Discovered, not installed or executed; not adopted for this app |
|
|
12
|
+
|
|
13
|
+
Searches included Node.js organization skill sources and Microsoft TypeScript maintainer skill sources. No suitable general Node.js/application review skill was verified in this search. That is a bounded search result, not proof no such skill exists. Use relevant official documentation directly. No third-party skill was automatically installed. A reference in an example fixture is labelled unverified unless that example actually records consultation.
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
# Review interface verification
|
|
2
|
+
|
|
3
|
+
This record distinguishes automated checks, browser interactions and authored workflow scenarios. Exact candidate revision, package digest and platform CI are recorded in PR #19 and the release after the complete expanded candidate is verified.
|
|
4
|
+
|
|
5
|
+
## Automated checks
|
|
6
|
+
|
|
7
|
+
The format tests cover required/versioned fields, unknown fields, duplicate/dangling IDs, consultation dates, resolution evidence, counts independent from filters, policy-derived conclusions, selective changed-target signalling, link protocols, text redaction, unsafe image types and derived Markdown. Renderer tests cover inert JSON embedding, script CSP and absent remote program/style loads. CLI tests cover generated reports, output preflight/conflict preservation, bounded explicit paths, symlink refusal, legacy reading, invalid JSON without source disclosure, empty and packaged demo modes.
|
|
8
|
+
|
|
9
|
+
These tests check code, not whether a reviewing model follows the workflow or whether author-supplied evidence is true.
|
|
10
|
+
|
|
11
|
+
## Browser inspection — 2026-09-13
|
|
12
|
+
|
|
13
|
+
Real Codex in-app browser at 1586×992 and 390×844: inspected the implemented rendering against the user-approved artistic reference, composed filters, selected findings, evidence/correction tabs, coverage, mobile list/detail return and absence of horizontal overflow. A real focus-loss defect was observed when selecting a finding updated the hash and rebuilt the page twice. The fix uses a single render and restores focus; verified focus on detail-title and keyboard ArrowRight to the Correction tab. Mobile back restores the selected result and retains query/confidence filters.
|
|
14
|
+
|
|
15
|
+
Imported an adversarial JSON fixture through the real file picker: HTML-like title displayed literally, no script dialog or console warning/error. Unit tests independently verify redaction and escaped report embedding. Inspected a changed-revision page with targeted C-01/R-01 reassessment and an empty-viewer page. Also verified invalid-format, legacy inert Markdown, partial and blocked states, missing-finding mobile recovery, and an embedded real JPEG screenshot. Chrome produced an actual HTML download: inspected the last downloaded file, validated its format-1 data, saved query/selected finding/detail section and CSP program hash. The browser download-event listener timed out despite the actual file being created. Direct file:// reopening was rejected by the browser tool policy and was not bypassed; no successful offline-browser reopen is claimed. Post-package checks belong to the final candidate evidence.
|
|
16
|
+
|
|
17
|
+
## Authored workflow scenarios
|
|
18
|
+
|
|
19
|
+
| Scenario | Expected response under the revised workflow |
|
|
20
|
+
|---|---|
|
|
21
|
+
| Official docs describe a newer incompatible version | Keep installed version and accepted conventions; find matching docs, record compatibility limits; no automatic migration |
|
|
22
|
+
| “Official” skill lacks reliable publisher provenance | Mark unverified, do not install/execute; use verified documentation independently |
|
|
23
|
+
| No suitable official skill found | Record the bounded search limitation and consult official docs directly |
|
|
24
|
+
| Suspected issue cannot be reproduced | Keep suspected confidence and verification next step; no demonstrated vulnerability claim |
|
|
25
|
+
| Automated tests pass but visual defect is observed | Record the actual screenshot/interaction finding and its impact; automated success does not override it |
|
|
26
|
+
| A check cannot run | Record blocked or not-run with reason; preserve unrelated executed results |
|
|
27
|
+
| A correction is applied | Retain original evidence and require fresh relevant verification before resolved |
|
|
28
|
+
| No findings with limited coverage | State verified scope and uncovered surfaces; no completeness inference |
|
|
29
|
+
|
|
30
|
+
These are authored scenario walkthroughs, not transcripts of new authenticated model executions.
|
|
31
|
+
|
|
32
|
+
The [actual structured review](missions/workflow-0.3-reviews/interface/review.json) records the observed focus defect, original and post-fix evidence, and the blocked offline-browser check. Its [Markdown report](missions/workflow-0.3-reviews/interface/REVIEW.md) is generated from that source. This is separate from the fictional interface demo.
|
|
33
|
+
|
|
34
|
+
Actual rendering (fictional demo data): [desktop capture](images/review-interface-desktop.jpg), [mobile capture](images/review-interface-mobile.jpg). The user reference image is a design source, not an execution result.
|
package/docs/REVIEWS.md
ADDED
|
@@ -0,0 +1,75 @@
|
|
|
1
|
+
# Review results, reports and browser consultation
|
|
2
|
+
|
|
3
|
+
The agent's `project-foundation review` stage performs project-aware inspection under [the review workflow](../.agents/skills/scoped-delivery/references/review-workflow.md). The CLI `devmethod review` only validates and presents recorded results. It never runs repository commands, discovers evidence on disk, or performs the review itself.
|
|
4
|
+
|
|
5
|
+
## Use the installed package
|
|
6
|
+
|
|
7
|
+
After 0.3.0 publication, from a temporary or project directory:
|
|
8
|
+
|
|
9
|
+
```sh
|
|
10
|
+
npx --yes devmethod-ai@0.3.0 review --demo --output review.html
|
|
11
|
+
```
|
|
12
|
+
|
|
13
|
+
Open the generated `review.html` in a browser. It includes the browser program, styles and explicitly included data, independent of the DevMethod checkout. The demo is fictional, with different findings from the artistic reference. It is not evidence of a real product review.
|
|
14
|
+
|
|
15
|
+
For a real review, paths are relative to `--dest` (current directory by default):
|
|
16
|
+
|
|
17
|
+
```sh
|
|
18
|
+
npx --yes devmethod-ai@0.3.0 review --review docs/missions/my-mission/reviews/review-1/review.json --output review.html --markdown REVIEW.md
|
|
19
|
+
npx --yes devmethod-ai@0.3.0 review --review review.json --json
|
|
20
|
+
npx --yes devmethod-ai@0.3.0 review --review review.json --current-revision inspected-new-revision --changed-targets save-status --output recheck.html
|
|
21
|
+
npx --yes devmethod-ai@0.3.0 review --legacy old-review.md --output historical.html
|
|
22
|
+
npx --yes devmethod-ai@0.3.0 review --output empty-viewer.html
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
Existing outputs are never overwritten. Choose a fresh path for a newer snapshot. `--json` validates/reports without writing unless output flags are also explicitly given. Exit 0 means valid presentation/inspection, **not** a passed review; inspect `status`/`summary`. Exit 2 means invalid invocation, result schema or filesystem input/output. Missing revisions remain unknown. `--changed-targets` compares exact logical target names; it does not infer all semantic dependencies. Independent historical checks are preserved.
|
|
26
|
+
|
|
27
|
+
## One versioned source
|
|
28
|
+
|
|
29
|
+
Use existing conventions, or `docs/missions/<mission-id>/reviews/<review-id>/review.json`, with generated `REVIEW.md` and deliberately included `preuves/`. Tickets link stable finding IDs; the report and UI derive results from the JSON. Do not maintain another independent score or status table.
|
|
30
|
+
|
|
31
|
+
Format 1 is validated by the same pure model in the CLI and browser. See the [complete fictional example](../examples/review/review.json) and [compiled validator](../dist/review-model.js). Unknown formats, unknown/missing fields, duplicate IDs, invalid destinations and dangling references are rejected with errors that omit source contents. Arrays are bounded to 256 items, text fields to 16,384 characters, and input to 4 MiB. Image data has a separate limit of approximately 1 MiB per PNG/JPEG.
|
|
32
|
+
|
|
33
|
+
| Object | Required fields and ownership |
|
|
34
|
+
|---|---|
|
|
35
|
+
| Review | format, id, title, project, mission, tickets, date, scope, exclusions, revision, technologies, sources, checks, findings, evidence, limits, policy, summary |
|
|
36
|
+
| revision | commit (recorded revision label), dirty (explicit uncommitted changes); no automatic Git execution |
|
|
37
|
+
| technologies | name, version, detectedFrom (actual manifest/lockfile/source evidence) |
|
|
38
|
+
| ticket | id, title, url (HTTPS or null; local/unpublished destinations remain unavailable) |
|
|
39
|
+
| source | id, title, kind (documentation/skill/project), publisher, technology, version, url, consultedAt, access (consulted/unavailable/unverified), usage, compatibility, provenance; consulted requires a date |
|
|
40
|
+
| check | id, title, domain, kind (automated/manual), status (passed/failed/not-run/blocked/out-of-scope), result, reason, evidenceIds, revision, targets; unexecuted/excluded checks need a reason |
|
|
41
|
+
| finding | id, title, domain, severity (critical/major/moderate/minor), severityReason, confidence (confirmed/suspected), resolution (open/in-progress/resolved/accepted-risk), location, trigger, expected, observed, impact, reproduction, evidenceIds, correction, tradeoffs, sourceIds, ticketIds, verification, resolutionEvidenceIds, targets |
|
|
42
|
+
| location | path or component description, line (positive integer or null), component (text or null); display metadata, never arbitrary file access |
|
|
43
|
+
| evidence | id, title, kind (text/log/screenshot/diagram), content (text alternative or excerpt), url (HTTPS or null), image (null or explicit PNG/JPEG object) |
|
|
44
|
+
| image | mime=image/png or image/jpeg, base64, alt, origin=captured/explanatory, privacyReviewed=true; only deliberately included reviewed images, not filesystem paths or remote images |
|
|
45
|
+
| policy | blockingSeverities, requireAllChecks, rationale; project-owned explicit policy, no numeric risk score |
|
|
46
|
+
|
|
47
|
+
A confirmed finding still needs evidence or reproduction. A resolved finding requires resolution evidence IDs; schema validation checks the references, **not the truth of execution or whether the fix really works**. Authors must retain the original evidence and supply fresh verification. Closing a panel never changes resolution. Finding counts include all resolution states and stay independent from filtered results; uncertain unresolved findings have a separate count. Failed-check counts are separate from finding counts.
|
|
48
|
+
|
|
49
|
+
A blocking confirmed open finding or a failed check requires corrections. Otherwise a blocked check yields blocked; no passed checks, an unresolved suspected finding, or required unrun checks yields incomplete. Otherwise the conclusion is ready **on the verified scope**, with exclusions and limits still visible. This conclusion does not authorize integration/deployment or replace repository policy.
|
|
50
|
+
|
|
51
|
+
## Browser journey
|
|
52
|
+
|
|
53
|
+
Use Constats to search and combine domain/severity/confidence/resolution filters. Select a finding with keyboard or pointer; its header shows severity, confidence, resolution, impact and location. Preuve shows reproduction, expected/observed behavior, text logs, PNG/JPEG images or explanatory flow text. Correction shows proposed action/trade-offs/verification and a ticket link only when supplied. Références shows provenance, actual consultation and compatibility.
|
|
54
|
+
|
|
55
|
+
Couverture groups controls by domain, with kind, result, revision, reason and evidence. Sources distinguishes consulted, inaccessible and unverified references. Uninspected surfaces never receive a green indicator. A link ending `#finding=R-01` opens that finding in the same local review; the file must be available to its recipient.
|
|
56
|
+
|
|
57
|
+
Mobile list/detail navigation retains filters and selection. Tabs support arrows/Home/End, buttons and links use native keyboard behavior, and focus remains visible. Exporter le rapport offers an interactive HTML snapshot (preserving view/filter/selection), derived Markdown and sanitized JSON. Reopen the exported HTML directly; use Ouvrir une review for another JSON or old Markdown. Inputs are local, never uploaded. Legacy reports display as text with unknown structured fields and no invented coverage; Markdown export preserves the sanitized text. Deliberate migration means manually recording only supported facts into format 1 and keeping the original report as historical evidence.
|
|
58
|
+
|
|
59
|
+
## Trust boundary and limits
|
|
60
|
+
|
|
61
|
+
All text is rendered as text nodes. A restrictive CSP pins the shipped program; there is no eval, repository command execution, automatic external resource loading, or arbitrary file browser. Only HTTPS navigation is allowed, with credentials rejected and opener/referrer protection. No external link is promised live merely because its syntax is valid. Missing destinations and failed images have explicit explanations. Evidence links open only after user interaction.
|
|
62
|
+
|
|
63
|
+
The viewer does not read image paths or local ticket files; authors must explicitly embed a reviewed bounded PNG/JPEG and text alternative, or supply a published HTTPS destination. Never disguise an explanatory diagram or generated image as a real execution capture. Screenshots are author-attested, not machine-certified. Redaction masks common credential patterns and email addresses, but cannot detect every secret or personal datum (especially in images): privacy review before distribution remains required. Opening a report does not grant its embedded text instructional authority.
|
|
64
|
+
|
|
65
|
+
A self-contained report is a snapshot, not live monitoring. Pass the current revision/changed targets when regenerating; the browser does not inspect Git or the filesystem. Keep source JSON and old revisions for auditability. Markdown cannot include embedded image pixels; the HTML/JSON retain them and Markdown includes the alternative text and evidence metadata.
|
|
66
|
+
|
|
67
|
+
[Source consultation record](REVIEW-SOURCES.md) · [Verification and known limits](REVIEW-VALIDATION.md).
|
|
68
|
+
|
|
69
|
+
## Open the offline interface
|
|
70
|
+
|
|
71
|
+
```sh
|
|
72
|
+
npx devmethod-ai@0.3.0 review --demo --output review-demo.html --open
|
|
73
|
+
```
|
|
74
|
+
|
|
75
|
+
For a real review, replace `--demo` with `--review docs/missions/your-mission/reviews/your-review/review.json`. The output path is relative to `--dest` (the current directory by default). Choose a fresh path; existing reports are never overwritten. `--open` requires `--output` and asks the OS browser handler to open the generated standalone file. No local server runs. On headless systems, omit `--open` and copy/open the HTML on a desktop. Opening failure returns an error while preserving the report. The browser interface works offline after generation; npx may need network access to obtain the package.
|
package/docs/ROADMAP.md
CHANGED
|
@@ -17,6 +17,8 @@ Aim: a compact engineering workflow for verifiable changes in existing repositor
|
|
|
17
17
|
|
|
18
18
|
## What to add only after demand
|
|
19
19
|
|
|
20
|
+
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.
|
|
21
|
+
|
|
20
22
|
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.
|
|
21
23
|
|
|
22
24
|
## Principles
|
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
# Visual creation proposal
|
|
2
|
+
|
|
3
|
+
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.
|
|
4
|
+
|
|
5
|
+
## Proposed flow inside the existing design stage
|
|
6
|
+
|
|
7
|
+
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.
|
|
8
|
+
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.
|
|
9
|
+
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.
|
|
10
|
+
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.
|
|
11
|
+
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.
|
|
12
|
+
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.
|
|
13
|
+
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.
|
|
14
|
+
|
|
15
|
+
## Bounded evaluation before adoption
|
|
16
|
+
|
|
17
|
+
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.
|
|
18
|
+
|
|
19
|
+
## Relationship to BMad
|
|
20
|
+
|
|
21
|
+
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.
|
|
@@ -0,0 +1,75 @@
|
|
|
1
|
+
# Create a direction, then build it
|
|
2
|
+
|
|
3
|
+
DevMethod 0.2.0 and the 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.
|
|
4
|
+
|
|
5
|
+
## Start
|
|
6
|
+
|
|
7
|
+
From the target repository, install the current reviewed GitHub source into a staging directory:
|
|
8
|
+
|
|
9
|
+
```sh
|
|
10
|
+
npx --yes --package=github:montassarkhalloufi/DevMethod devmethod init --tool codex --dest ../devmethod-staging
|
|
11
|
+
```
|
|
12
|
+
|
|
13
|
+
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`.
|
|
14
|
+
|
|
15
|
+
In the agent conversation, not the terminal:
|
|
16
|
+
|
|
17
|
+
```text
|
|
18
|
+
$project-foundation design
|
|
19
|
+
Create a visual direction for [product and audience].
|
|
20
|
+
Show me alternatives, let me choose, then prepare the key screen mockups.
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
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.
|
|
24
|
+
|
|
25
|
+
## What the procedure delivers
|
|
26
|
+
|
|
27
|
+
1. A brief grounded in the product, audience and supplied references.
|
|
28
|
+
2. Two or three comparable visible directions when the choice is open.
|
|
29
|
+
3. A recorded user choice, or an explicitly delegated selection.
|
|
30
|
+
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.
|
|
31
|
+
5. An interactive prototype for the behavior that needs checking. The prototype may become the implementation.
|
|
32
|
+
6. Browser captures and interaction evidence compared with the approved reference, with mismatches and limitations recorded.
|
|
33
|
+
|
|
34
|
+
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.
|
|
35
|
+
|
|
36
|
+
## Recorded examples
|
|
37
|
+
|
|
38
|
+
- [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.
|
|
39
|
+
- [Mission and evidence](missions/visual-workflow.md): scope, checks and known typography/spacing differences.
|
|
40
|
+
|
|
41
|
+
Source adoption is separate from npm publication. No new npm version is announced by this guide.
|
|
42
|
+
|
|
43
|
+
## Full filmed chain
|
|
44
|
+
|
|
45
|
+
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.
|
|
46
|
+
|
|
47
|
+
## Master screen → images des écrans → application
|
|
48
|
+
|
|
49
|
+
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.
|
|
50
|
+
|
|
51
|
+
Dans la conversation Codex, on peut envoyer successivement :
|
|
52
|
+
|
|
53
|
+
```text
|
|
54
|
+
$project-foundation design
|
|
55
|
+
Propose trois directions comparables sur le même écran principal.
|
|
56
|
+
```
|
|
57
|
+
|
|
58
|
+
```text
|
|
59
|
+
$project-foundation design
|
|
60
|
+
Je choisis A. Finalise le master screen de cette direction.
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
Après examen et approbation du master :
|
|
64
|
+
|
|
65
|
+
```text
|
|
66
|
+
$project-foundation design
|
|
67
|
+
Décline ce master approuvé en images des écrans demandés.
|
|
68
|
+
Utilise le fichier du master comme référence visuelle.
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
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.
|
|
72
|
+
|
|
73
|
+
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.
|
|
74
|
+
|
|
75
|
+
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.
|
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
# 0.3 workflow verification
|
|
2
|
+
|
|
3
|
+
## Scope of evidence
|
|
4
|
+
|
|
5
|
+
This record separates automated regression checks, an authored scenario walkthrough and manual inspection. A textual assertion or the walkthrough below does not prove conversational compliance by a model. No fresh authenticated Codex, Claude Code or Cursor behavior run is claimed for 0.3.0. Prior native evidence remains historical for its recorded revisions.
|
|
6
|
+
|
|
7
|
+
## Scenario walkthrough — 2026-09-13
|
|
8
|
+
|
|
9
|
+
Method: inspect the revised stage contracts, trace the input through its responsible stage and check the expected next action against templates and the fictional linked fixture. These are authored simulations, not captured user/model executions.
|
|
10
|
+
|
|
11
|
+
| Input / scenario | Expected route and inspected outcome |
|
|
12
|
+
|---|---|
|
|
13
|
+
| New product with unclear alternatives | explore opens research guidance; compares direct, adjacent and informal alternatives, dates claims and presents a synthesis before framing |
|
|
14
|
+
| Isolated technical correction | work-sizing Quick keeps inline readiness and focused checks; no market research or mission scaffold |
|
|
15
|
+
| Research tools unavailable | disclose access limit, distinguish supplied evidence from hypotheses, propose research; no invented results |
|
|
16
|
+
| Sources contradict | retain both dated claims and their scope; state uncertainty and resolution experiment; missing feature stays unverified |
|
|
17
|
+
| User refuses architecture recommendation | return to objection and viable options; no dependent architecture built around the rejected option |
|
|
18
|
+
| User proposes alternative | evaluate it on the same cost, operating, durability and user criteria; revise recommendation if warranted |
|
|
19
|
+
| User explicitly delegates storage choice | record delegation scope/source and chosen rationale; detail dependent architecture without reconfirmation |
|
|
20
|
+
| Ambiguous “ok” after several options | clarify only if needed to select dependent work; no inferred adoption |
|
|
21
|
+
| plan invoked with open storage | fictional PLAN remains conditional and SAVE-1 points directly to architecture; no correct-course detour |
|
|
22
|
+
| Accepted decision changes | link replacement and impacted contracts/tickets; reassess readiness and invalidate dependent evidence/review only |
|
|
23
|
+
| Resume multi-file mission | profile → PLAN → SAVE-1 → linked rule and decision; REPRISE is a dated pointer, ticket owns blocker/evidence |
|
|
24
|
+
| Resume legacy single file | legacy-copy retains scope, task, criterion and handoff inline; no move required |
|
|
25
|
+
| First useful delivery / scope edit | delivery-planning requests useful outcome/learning, real scope choices and effort uncertainty; milestones carry demos, exits and authorized continuation |
|
|
26
|
+
| Existing approved design | design-to-code files unchanged; foundation only links product and decision owners |
|
|
27
|
+
|
|
28
|
+
## Automated and manual checks
|
|
29
|
+
|
|
30
|
+
Automated tests exercise the installer across three host profiles, actual resource/manifest/link completeness, subset installation, all-or-nothing divergence preservation, and unchanged legacy/multi-file mission bytes. Package smoke checks the archive, help and resources, three host layouts and optional upgrade from an actual prior tarball. The existing JSON and resumption suites still apply without schema changes.
|
|
31
|
+
|
|
32
|
+
Manual inspection covers the downstream skill diff, generic intent without project content, owner uniqueness, migration instructions, design-module diff and final change review. Exact test counts, revisions, platform CI results and package integrity belong in the release PR/release evidence, not in an independently maintained ticket-status table.
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
# Research, decisions and mission ownership
|
|
2
|
+
|
|
3
|
+
DevMethod 0.3.0 keeps six skills, fourteen workflow stages and the existing JSON inspector schemas. The `design-to-code` module is unchanged. This update changes model guidance, not a deterministic conversational engine.
|
|
4
|
+
|
|
5
|
+
## Before committing to a solution
|
|
6
|
+
|
|
7
|
+
`explore` researches direct, adjacent and informal alternatives when product uncertainty warrants it. Use dated traceable sources, distinguish facts, interpretations and hypotheses, and separate testimonials from demonstrated trends. Not finding a feature is not proof of absence or opportunity. Discuss a synthesis and whether to continue, reposition, reduce, deepen or abandon. Unavailable research must be disclosed; a technical fix does not inherit a competitive-study requirement. See [exploration guidance](../.agents/skills/project-foundation/references/exploration.md).
|
|
8
|
+
|
|
9
|
+
`frame` owns the resulting need, scope, success criteria and business rules. Preserve approved design and its existing workflow.
|
|
10
|
+
|
|
11
|
+
`architecture` collects constraints and compares credible options in the conversation before detailing dependent architecture. The user may challenge, supply alternatives, choose or explicitly delegate. Record the choice/delegation and rationale in the decision owner. Silence, an ambiguous “ok”, invoking `plan` or a PROPOSED label does not replace this exchange. Preserve accepted decisions, scoped delegations and autonomy for routine reversible details.
|
|
12
|
+
|
|
13
|
+
`plan` discusses the first useful outcome and learning, actual scope alternatives, benefits, exclusions, risks, dependencies and uncertain effort. Record priorities, milestone demonstrations, exit and continuation conditions under current authorization. Detail near-term vertical slices. With open architecture, make the plan conditional and resume the discussion directly in architecture. Changed decisions require reassessing dependent tickets and evidence. See [delivery planning](../.agents/skills/project-foundation/references/delivery-planning.md).
|
|
14
|
+
|
|
15
|
+
## Proposed storage, only without an existing convention
|
|
16
|
+
|
|
17
|
+
For substantial work, [mission context](../.agents/skills/project-foundation/references/mission-context.md) defines the full proposed tree: compact PROJECT_PROFILE; docs/exploration/{EXISTANT,OPPORTUNITES}; docs/produit/{CADRAGE,REGLES}; docs/missions/<mission-id>/{PLAN,REPRISE,tickets/,preuves/}; design/; architecture/decisions/.
|
|
18
|
+
|
|
19
|
+
Each fact has one current owner. The profile links context; research owns sources and hypotheses; product owns need and rules; PLAN owns mission outcome, milestones/order and ticket links; tickets own scope, dependencies, status, acceptance and revision-labelled verification. REPRISE is the latest dated handoff, not a second status register. Bulky artifacts go in preuves when needed. Any status table is generated from tickets and labelled with its revision/time, never maintained independently. Do not create empty documents by ritual.
|
|
20
|
+
|
|
21
|
+
Read progressively: profile, active mission, active ticket, necessary references. Compare actual code and changed dependencies with evidence before resuming. A plan, ready ticket, verified implementation, integration and deployment are distinct states.
|
|
22
|
+
|
|
23
|
+
## Non-destructive migration
|
|
24
|
+
|
|
25
|
+
Existing `docs/missions/<mission-id>.md` records, inline Quick work and existing trackers remain valid. No automatic move, rewrite or JSON schema migration occurs.
|
|
26
|
+
|
|
27
|
+
1. Install the new kit into a fresh staging directory and compare using `update-preview` and a content diff. Keep customized skills, filled profiles and existing instructions; divergent files still block init before writes.
|
|
28
|
+
2. Keep the legacy mission as the active entry until extraction is useful. Inspect candidate target paths for existing content. Reconcile divergence intentionally; never overwrite it.
|
|
29
|
+
3. Extract outcome/milestones into PLAN, executable task fields and evidence into tickets, and the dated handoff into REPRISE only as needed. Keep stable criterion IDs, exact source links and historical revisions. Replace extracted live fields in the old location with links so ownership stays unique.
|
|
30
|
+
4. Verify links, criteria and the active ticket from the new entry. Update the profile's entry link after the comparison. Git retains history; avoid a duplicate live status table.
|
|
31
|
+
|
|
32
|
+
Installed resources live under each selected skill's assets/references. They are templates, not files automatically scaffolded into docs. Foundation includes the research/product resources even when delivery is not selected; resolve scoped-delivery by name when its templates are needed. The three host profiles transform skill paths and generate integrity manifests from the full selected payload. No manifest format change is needed.
|
|
33
|
+
|
|
34
|
+
The CLI `mission`, `context`, `context-check`, `resume` and `plan` still take explicit JSON paths. They do not parse Markdown mission directories, accept decisions or execute tickets. See the [fictional linked mission](../examples/mission-dialogue/PROJECT_PROFILE.md) and [verification scenarios](WORKFLOW-0.3-VALIDATION.md).
|
|
@@ -0,0 +1,10 @@
|
|
|
1
|
+
<svg xmlns="http://www.w3.org/2000/svg" width="1200" height="650" viewBox="0 0 1200 650" role="img" aria-labelledby="title desc">
|
|
2
|
+
<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>
|
|
3
|
+
<defs><marker id="arrow" markerWidth="8" markerHeight="8" refX="6" refY="3" orient="auto"><path d="M0 0L6 3L0 6" fill="#ddac86"/></marker></defs>
|
|
4
|
+
<rect width="1200" height="650" rx="28" fill="#10272b"/><g font-family="Arial, sans-serif">
|
|
5
|
+
<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>
|
|
6
|
+
<text x="52" y="154" fill="#b9ccc4" font-size="20">Design approval guides the work. Tests and browser checks verify the result.</text>
|
|
7
|
+
<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>
|
|
8
|
+
<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>
|
|
9
|
+
<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>
|
|
10
|
+
<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>
|
|
@@ -1,26 +1,13 @@
|
|
|
1
|
-
<svg xmlns="http://www.w3.org/2000/svg" width="1200" height="
|
|
2
|
-
|
|
3
|
-
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
<rect x="512" y="190" width="290" height="144" rx="20" fill="#182347" stroke="#4dd6ad" stroke-width="2"/>
|
|
15
|
-
<circle cx="556" cy="234" r="20" fill="#4dd6ad"/><text x="548" y="241" fill="#0b1020" font-size="18" font-weight="700">2</text>
|
|
16
|
-
<text x="594" y="240" fill="#fff" font-size="25" font-weight="700">Build the slice</text>
|
|
17
|
-
<text x="544" y="286" fill="#c8d2ef" font-size="18">Implement · test · review</text>
|
|
18
|
-
<text x="544" y="314" fill="#c8d2ef" font-size="18">Correct when evidence fails</text>
|
|
19
|
-
<path d="M830 262h88" stroke="#4dd6ad" stroke-width="5" stroke-linecap="round"/><path d="M908 250l22 12-22 12" fill="#4dd6ad"/>
|
|
20
|
-
<rect x="952" y="190" width="176" height="144" rx="20" fill="#182347" stroke="#ffcf5b" stroke-width="2"/>
|
|
21
|
-
<circle cx="996" cy="234" r="20" fill="#ffcf5b"/><text x="988" y="241" fill="#0b1020" font-size="18" font-weight="700">3</text>
|
|
22
|
-
<text x="984" y="240" fill="#fff" font-size="23" font-weight="700">Prove it</text>
|
|
23
|
-
<text x="984" y="286" fill="#c8d2ef" font-size="17">Verify · integrate</text>
|
|
24
|
-
<text x="984" y="314" fill="#c8d2ef" font-size="17">Handoff · next</text>
|
|
25
|
-
</g>
|
|
26
|
-
</svg>
|
|
1
|
+
<svg xmlns="http://www.w3.org/2000/svg" width="1200" height="720" viewBox="0 0 1200 720" role="img" aria-labelledby="title desc">
|
|
2
|
+
<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>
|
|
3
|
+
<rect width="1200" height="720" rx="28" fill="#10272b"/>
|
|
4
|
+
<g font-family="Arial, sans-serif"><text x="52" y="64" fill="#eeb88e" font-size="16" letter-spacing="3">DEVMETHOD / THE COMPLETE WORKFLOW</text>
|
|
5
|
+
<text x="52" y="119" fill="#fff9ef" font-size="38" font-weight="700">From an idea to a verified product</text>
|
|
6
|
+
<text x="52" y="157" fill="#b9ccc4" font-size="20">Make the decisions visible. Build a useful slice. Check the result.</text>
|
|
7
|
+
<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>
|
|
8
|
+
<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>
|
|
9
|
+
<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>
|
|
10
|
+
<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>
|
|
11
|
+
<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>
|
|
12
|
+
<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>
|
|
13
|
+
<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>
|
|
Binary file
|
|
Binary file
|