@chinhae/atw-cli 0.2.8 → 0.2.10
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/README.md +5 -2
- package/dist/configurators/workflow.d.ts.map +1 -1
- package/dist/configurators/workflow.js +2 -1
- package/dist/configurators/workflow.js.map +1 -1
- package/dist/migrations/manifests/0.2.10.json +9 -0
- package/dist/migrations/manifests/0.2.9.json +9 -0
- package/dist/templates/atw/workflow.md +8 -6
- package/dist/templates/common/bundled-skills/atw-code-review/SKILL.md +22 -5
- package/dist/templates/common/bundled-skills/atw-implement/SKILL.md +3 -1
- package/dist/templates/common/bundled-skills/atw-prototype/LOGIC.md +41 -41
- package/dist/templates/common/bundled-skills/atw-prototype/SKILL.md +16 -14
- package/dist/templates/common/bundled-skills/atw-prototype/UI.md +120 -58
- package/dist/templates/common/bundled-skills/atw-prototype/assets/style-explorer.html +333 -0
- package/dist/templates/common/bundled-skills/atw-prototype/references/design-direction.md +170 -0
- package/dist/templates/common/bundled-skills/atw-prototype/references/style-explorer.md +92 -0
- package/dist/templates/common/bundled-skills/atw-prototype/references/visual-language.md +88 -0
- package/dist/templates/common/bundled-skills/atw-prototype/references/visual-review.md +63 -0
- package/dist/templates/common/bundled-skills/atw-prototype/scripts/build_explorer.py +334 -0
- package/dist/templates/common/bundled-skills/atw-spec/SKILL.md +10 -0
- package/dist/templates/common/bundled-skills/atw-spec-bootstrap/references/spec-writing.md +4 -0
- package/dist/templates/common/bundled-skills/atw-tickets/SKILL.md +6 -0
- package/dist/templates/common/bundled-skills/atw-ui/SKILL.md +126 -0
- package/dist/templates/common/bundled-skills/atw-ui/agents/openai.yaml +3 -0
- package/dist/templates/common/bundled-skills/atw-ui/references/imagery.md +69 -0
- package/dist/templates/common/bundled-skills/atw-ui/references/layout-and-viewport.md +15 -0
- package/dist/templates/common/bundled-skills/atw-ui/references/media.md +45 -0
- package/dist/templates/common/bundled-skills/atw-ui/references/motion.md +101 -0
- package/dist/templates/common/bundled-skills/atw-ui/references/visual-language.md +88 -0
- package/dist/templates/common/bundled-skills/atw-ui/references/visual-review.md +94 -0
- package/dist/templates/common/bundled-skills/oxy-learning-hub/scripts/validate_html.py +2 -0
- package/dist/templates/common/skills/update-spec.md +1 -0
- package/dist/templates/markdown/index.d.ts +1 -0
- package/dist/templates/markdown/index.d.ts.map +1 -1
- package/dist/templates/markdown/index.js +1 -0
- package/dist/templates/markdown/index.js.map +1 -1
- package/dist/templates/markdown/spec/frontend/design-system.md.txt +68 -0
- package/dist/templates/markdown/spec/frontend/index.md.txt +1 -0
- package/package.json +2 -2
package/README.md
CHANGED
|
@@ -91,7 +91,8 @@ Phase 3: Finish accept → completed
|
|
|
91
91
|
a time. When the work is large and the route is unclear, `/atw-map` scans the
|
|
92
92
|
territory first and files decision tickets; `/atw-research` handles external
|
|
93
93
|
unknowns and `/atw-prototype` handles design questions that need a throwaway
|
|
94
|
-
build
|
|
94
|
+
build — including comparing several visual directions side by side before one
|
|
95
|
+
is chosen. `/atw-spec` turns the findings into `prd.md` — the requirements,
|
|
95
96
|
constraints, and acceptance criteria everything downstream is checked against.
|
|
96
97
|
When the work won't fit one session, `/atw-tickets` slices the confirmed spec
|
|
97
98
|
into `issues/NN-*.md`.
|
|
@@ -101,7 +102,9 @@ Each ticket runs a closed chain that must not be broken up from the outside:
|
|
|
101
102
|
implement → run tests → review → handle findings → write learnings back to spec
|
|
102
103
|
→ commit. Review is an `atw-review` sub-agent reading two axes, project
|
|
103
104
|
standards and the task's own spec, and both of its reports reach you verbatim —
|
|
104
|
-
including when the verdict is "nothing found".
|
|
105
|
+
including when the verdict is "nothing found". When a ticket changes what a user
|
|
106
|
+
sees, `/atw-ui` builds that part on real screens and a third, Visual axis
|
|
107
|
+
reviews the screenshots.
|
|
105
108
|
|
|
106
109
|
**Phase 3 — Finish.** Read-only. The acceptance criteria in `prd.md` get walked
|
|
107
110
|
one by one with evidence, and nothing new gets opened — things you notice become
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"workflow.d.ts","sourceRoot":"","sources":["../../src/configurators/workflow.ts"],"names":[],"mappings":"
|
|
1
|
+
{"version":3,"file":"workflow.d.ts","sourceRoot":"","sources":["../../src/configurators/workflow.ts"],"names":[],"mappings":"AA0CA,OAAO,EAEL,KAAK,WAAW,EAChB,KAAK,eAAe,EACrB,MAAM,8BAA8B,CAAC;AAOtC;;GAEG;AACH,MAAM,WAAW,eAAe;IAC9B,yCAAyC;IACzC,WAAW,EAAE,WAAW,CAAC;IACzB,yFAAyF;IACzF,iBAAiB,CAAC,EAAE,OAAO,CAAC;IAC5B,kEAAkE;IAClE,QAAQ,CAAC,EAAE,eAAe,EAAE,CAAC;IAC7B,0EAA0E;IAC1E,kBAAkB,CAAC,EAAE,GAAG,CAAC,MAAM,CAAC,CAAC;IACjC;;;;;;OAMG;IACH,kBAAkB,CAAC,EAAE,MAAM,CAAC;CAC7B;AASD;;;;;;;;;;;;GAYG;AACH,wBAAgB,mBAAmB,CAAC,GAAG,EAAE,MAAM,GAAG,IAAI,CAerD;AAED;;;;;;;;;;;;GAYG;AACH,wBAAsB,uBAAuB,CAC3C,GAAG,EAAE,MAAM,EACX,OAAO,CAAC,EAAE,eAAe,GACxB,OAAO,CAAC,IAAI,CAAC,CAmEf"}
|
|
@@ -9,7 +9,7 @@ import { agentProgressIndexContent,
|
|
|
9
9
|
// Backend structure (multi-doc)
|
|
10
10
|
backendIndexContent, backendDirectoryStructureContent, backendDatabaseGuidelinesContent, backendLoggingGuidelinesContent, backendQualityGuidelinesContent, backendErrorHandlingContent,
|
|
11
11
|
// Frontend structure (multi-doc)
|
|
12
|
-
frontendIndexContent, frontendDirectoryStructureContent, frontendTypeSafetyContent, frontendHookGuidelinesContent, frontendComponentGuidelinesContent, frontendQualityGuidelinesContent, frontendStateManagementContent,
|
|
12
|
+
frontendIndexContent, frontendDirectoryStructureContent, frontendTypeSafetyContent, frontendHookGuidelinesContent, frontendComponentGuidelinesContent, frontendQualityGuidelinesContent, frontendStateManagementContent, frontendDesignSystemContent,
|
|
13
13
|
// Guides structure
|
|
14
14
|
guidesIndexContent, guidesCrossLayerThinkingGuideContent, guidesCodeReuseThinkingGuideContent, } from "../templates/markdown/index.js";
|
|
15
15
|
import { writeFile, ensureDir } from "../utils/file-writer.js";
|
|
@@ -154,6 +154,7 @@ async function writeFrontendDocs(specBase) {
|
|
|
154
154
|
content: frontendQualityGuidelinesContent,
|
|
155
155
|
},
|
|
156
156
|
{ name: "state-management.md", content: frontendStateManagementContent },
|
|
157
|
+
{ name: "design-system.md", content: frontendDesignSystemContent },
|
|
157
158
|
];
|
|
158
159
|
for (const doc of docs) {
|
|
159
160
|
await writeFile(path.join(frontendDir, doc.name), doc.content);
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"workflow.js","sourceRoot":"","sources":["../../src/configurators/workflow.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,MAAM,SAAS,CAAC;AACzB,OAAO,IAAI,MAAM,WAAW,CAAC;AAE7B,OAAO,EAAE,SAAS,EAAE,KAAK,EAAE,MAAM,uBAAuB,CAAC;AACzD,OAAO,EAAE,UAAU,EAAE,MAAM,yBAAyB,CAAC;AAErD,uDAAuD;AACvD,OAAO,EACL,kBAAkB,EAClB,kBAAkB,EAClB,iBAAiB,EACjB,qBAAqB,EACrB,YAAY,GACb,MAAM,2BAA2B,CAAC;AAEnC,4BAA4B;AAC5B,OAAO,EACL,yBAAyB;AACzB,gCAAgC;AAChC,mBAAmB,EACnB,gCAAgC,EAChC,gCAAgC,EAChC,+BAA+B,EAC/B,+BAA+B,EAC/B,2BAA2B;AAC3B,iCAAiC;AACjC,oBAAoB,EACpB,iCAAiC,EACjC,yBAAyB,EACzB,6BAA6B,EAC7B,kCAAkC,EAClC,gCAAgC,EAChC,8BAA8B;
|
|
1
|
+
{"version":3,"file":"workflow.js","sourceRoot":"","sources":["../../src/configurators/workflow.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,MAAM,SAAS,CAAC;AACzB,OAAO,IAAI,MAAM,WAAW,CAAC;AAE7B,OAAO,EAAE,SAAS,EAAE,KAAK,EAAE,MAAM,uBAAuB,CAAC;AACzD,OAAO,EAAE,UAAU,EAAE,MAAM,yBAAyB,CAAC;AAErD,uDAAuD;AACvD,OAAO,EACL,kBAAkB,EAClB,kBAAkB,EAClB,iBAAiB,EACjB,qBAAqB,EACrB,YAAY,GACb,MAAM,2BAA2B,CAAC;AAEnC,4BAA4B;AAC5B,OAAO,EACL,yBAAyB;AACzB,gCAAgC;AAChC,mBAAmB,EACnB,gCAAgC,EAChC,gCAAgC,EAChC,+BAA+B,EAC/B,+BAA+B,EAC/B,2BAA2B;AAC3B,iCAAiC;AACjC,oBAAoB,EACpB,iCAAiC,EACjC,yBAAyB,EACzB,6BAA6B,EAC7B,kCAAkC,EAClC,gCAAgC,EAChC,8BAA8B,EAC9B,2BAA2B;AAC3B,mBAAmB;AACnB,kBAAkB,EAClB,oCAAoC,EACpC,mCAAmC,GACpC,MAAM,gCAAgC,CAAC;AAExC,OAAO,EAAE,SAAS,EAAE,SAAS,EAAE,MAAM,yBAAyB,CAAC;AAC/D,OAAO,EAAE,4BAA4B,EAAE,MAAM,aAAa,CAAC;AAC3D,OAAO,EACL,eAAe,GAGhB,MAAM,8BAA8B,CAAC;AA6BtC;;;;GAIG;AACH,MAAM,2BAA2B,GAAG,8BAA8B,CAAC;AAEnE;;;;;;;;;;;;GAYG;AACH,MAAM,UAAU,mBAAmB,CAAC,GAAW;IAC7C,MAAM,UAAU,GAAG,IAAI,CAAC,IAAI,CAAC,GAAG,EAAE,gBAAgB,CAAC,CAAC;IAEpD,IAAI,CAAC,EAAE,CAAC,UAAU,CAAC,UAAU,CAAC,EAAE,CAAC;QAC/B,EAAE,CAAC,aAAa,CAAC,UAAU,EAAE,qBAAqB,CAAC,CAAC;QACpD,OAAO;IACT,CAAC;IAED,MAAM,QAAQ,GAAG,EAAE,CAAC,YAAY,CAAC,UAAU,EAAE,OAAO,CAAC,CAAC;IACtD,IAAI,2BAA2B,CAAC,IAAI,CAAC,QAAQ,CAAC,EAAE,CAAC;QAC/C,OAAO;IACT,CAAC;IAED,MAAM,SAAS,GAAG,QAAQ,CAAC,QAAQ,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC,CAAC,MAAM,CAAC;IAC1D,EAAE,CAAC,aAAa,CAAC,UAAU,EAAE,QAAQ,GAAG,SAAS,GAAG,qBAAqB,CAAC,CAAC;AAC7E,CAAC;AAED;;;;;;;;;;;;GAYG;AACH,MAAM,CAAC,KAAK,UAAU,uBAAuB,CAC3C,GAAW,EACX,OAAyB;IAEzB,MAAM,WAAW,GAAG,OAAO,EAAE,WAAW,IAAI,WAAW,CAAC;IACxD,MAAM,iBAAiB,GAAG,OAAO,EAAE,iBAAiB,IAAI,KAAK,CAAC;IAC9D,MAAM,QAAQ,GAAG,OAAO,EAAE,QAAQ,CAAC;IACnC,MAAM,kBAAkB,GAAG,OAAO,EAAE,kBAAkB,CAAC;IACvD,MAAM,UAAU,GAAG,OAAO,EAAE,kBAAkB,IAAI,kBAAkB,CAAC;IAErE,6BAA6B;IAC7B,SAAS,CAAC,IAAI,CAAC,IAAI,CAAC,GAAG,EAAE,SAAS,CAAC,QAAQ,CAAC,CAAC,CAAC;IAE9C,yCAAyC;IACzC,MAAM,UAAU,CAAC,SAAS,EAAE,IAAI,CAAC,IAAI,CAAC,GAAG,EAAE,KAAK,CAAC,OAAO,CAAC,EAAE;QACzD,UAAU,EAAE,IAAI;KACjB,CAAC,CAAC;IAEH,6EAA6E;IAC7E,MAAM,SAAS,CACb,IAAI,CAAC,IAAI,CAAC,GAAG,EAAE,KAAK,CAAC,mBAAmB,CAAC,EACzC,4BAA4B,CAAC,UAAU,CAAC,CACzC,CAAC;IAEF,iCAAiC;IACjC,MAAM,SAAS,CACb,IAAI,CAAC,IAAI,CAAC,GAAG,EAAE,SAAS,CAAC,QAAQ,EAAE,YAAY,CAAC,EAChD,iBAAiB,CAClB,CAAC;IAEF,kCAAkC;IAClC,MAAM,SAAS,CACb,IAAI,CAAC,IAAI,CAAC,GAAG,EAAE,SAAS,CAAC,QAAQ,EAAE,aAAa,CAAC,EACjD,kBAAkB,CACnB,CAAC;IAEF,0EAA0E;IAC1E,uEAAuE;IACvE,mBAAmB,CAAC,GAAG,CAAC,CAAC;IAEzB,0EAA0E;IAC1E,mEAAmE;IACnE,wEAAwE;IACxE,4EAA4E;IAC5E,wEAAwE;IACxE,eAAe;IACf,SAAS,CAAC,IAAI,CAAC,IAAI,CAAC,GAAG,EAAE,KAAK,CAAC,MAAM,CAAC,CAAC,CAAC;IACxC,KAAK,MAAM,CAAC,SAAS,EAAE,OAAO,CAAC,IAAI,YAAY,EAAE,EAAE,CAAC;QAClD,MAAM,SAAS,CAAC,IAAI,CAAC,IAAI,CAAC,GAAG,EAAE,KAAK,CAAC,MAAM,EAAE,SAAS,CAAC,EAAE,OAAO,CAAC,CAAC;IACpE,CAAC;IAED,kCAAkC;IAClC,SAAS,CAAC,IAAI,CAAC,IAAI,CAAC,GAAG,EAAE,KAAK,CAAC,SAAS,CAAC,CAAC,CAAC;IAC3C,MAAM,SAAS,CACb,IAAI,CAAC,IAAI,CAAC,GAAG,EAAE,KAAK,CAAC,SAAS,EAAE,UAAU,CAAC,EAC3C,4BAA4B,CAAC,yBAAyB,CAAC,CACxD,CAAC;IAEF,0BAA0B;IAC1B,SAAS,CAAC,IAAI,CAAC,IAAI,CAAC,GAAG,EAAE,KAAK,CAAC,KAAK,CAAC,CAAC,CAAC;IAEvC,8CAA8C;IAC9C,wEAAwE;IACxE,IAAI,QAAQ,IAAI,QAAQ,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;QACpC,qDAAqD;QACrD,MAAM,mBAAmB,CAAC,GAAG,EAAE,WAAW,EAAE,QAAQ,EAAE,kBAAkB,CAAC,CAAC;IAC5E,CAAC;SAAM,IAAI,CAAC,iBAAiB,EAAE,CAAC;QAC9B,uEAAuE;QACvE,MAAM,mBAAmB,CAAC,GAAG,EAAE,WAAW,CAAC,CAAC;IAC9C,CAAC;AACH,CAAC;AAED;;GAEG;AACH,KAAK,UAAU,gBAAgB,CAAC,QAAgB;IAC9C,MAAM,UAAU,GAAG,IAAI,CAAC,IAAI,CAAC,QAAQ,EAAE,SAAS,CAAC,CAAC;IAClD,SAAS,CAAC,UAAU,CAAC,CAAC;IACtB,MAAM,IAAI,GAAoB;QAC5B,EAAE,IAAI,EAAE,UAAU,EAAE,OAAO,EAAE,mBAAmB,EAAE;QAClD;YACE,IAAI,EAAE,wBAAwB;YAC9B,OAAO,EAAE,gCAAgC;SAC1C;QACD;YACE,IAAI,EAAE,wBAAwB;YAC9B,OAAO,EAAE,gCAAgC;SAC1C;QACD,EAAE,IAAI,EAAE,uBAAuB,EAAE,OAAO,EAAE,+BAA+B,EAAE;QAC3E,EAAE,IAAI,EAAE,uBAAuB,EAAE,OAAO,EAAE,+BAA+B,EAAE;QAC3E,EAAE,IAAI,EAAE,mBAAmB,EAAE,OAAO,EAAE,2BAA2B,EAAE;KACpE,CAAC;IACF,KAAK,MAAM,GAAG,IAAI,IAAI,EAAE,CAAC;QACvB,MAAM,SAAS,CAAC,IAAI,CAAC,IAAI,CAAC,UAAU,EAAE,GAAG,CAAC,IAAI,CAAC,EAAE,GAAG,CAAC,OAAO,CAAC,CAAC;IAChE,CAAC;AACH,CAAC;AAED;;GAEG;AACH,KAAK,UAAU,iBAAiB,CAAC,QAAgB;IAC/C,MAAM,WAAW,GAAG,IAAI,CAAC,IAAI,CAAC,QAAQ,EAAE,UAAU,CAAC,CAAC;IACpD,SAAS,CAAC,WAAW,CAAC,CAAC;IACvB,MAAM,IAAI,GAAoB;QAC5B,EAAE,IAAI,EAAE,UAAU,EAAE,OAAO,EAAE,oBAAoB,EAAE;QACnD;YACE,IAAI,EAAE,wBAAwB;YAC9B,OAAO,EAAE,iCAAiC;SAC3C;QACD,EAAE,IAAI,EAAE,gBAAgB,EAAE,OAAO,EAAE,yBAAyB,EAAE;QAC9D,EAAE,IAAI,EAAE,oBAAoB,EAAE,OAAO,EAAE,6BAA6B,EAAE;QACtE;YACE,IAAI,EAAE,yBAAyB;YAC/B,OAAO,EAAE,kCAAkC;SAC5C;QACD;YACE,IAAI,EAAE,uBAAuB;YAC7B,OAAO,EAAE,gCAAgC;SAC1C;QACD,EAAE,IAAI,EAAE,qBAAqB,EAAE,OAAO,EAAE,8BAA8B,EAAE;QACxE,EAAE,IAAI,EAAE,kBAAkB,EAAE,OAAO,EAAE,2BAA2B,EAAE;KACnE,CAAC;IACF,KAAK,MAAM,GAAG,IAAI,IAAI,EAAE,CAAC;QACvB,MAAM,SAAS,CAAC,IAAI,CAAC,IAAI,CAAC,WAAW,EAAE,GAAG,CAAC,IAAI,CAAC,EAAE,GAAG,CAAC,OAAO,CAAC,CAAC;IACjE,CAAC;AACH,CAAC;AAED;;GAEG;AACH,KAAK,UAAU,gBAAgB,CAC7B,QAAgB,EAChB,WAAwB;IAExB,IAAI,WAAW,KAAK,UAAU,EAAE,CAAC;QAC/B,MAAM,gBAAgB,CAAC,QAAQ,CAAC,CAAC;IACnC,CAAC;IACD,IAAI,WAAW,KAAK,SAAS,EAAE,CAAC;QAC9B,MAAM,iBAAiB,CAAC,QAAQ,CAAC,CAAC;IACpC,CAAC;AACH,CAAC;AAED,KAAK,UAAU,mBAAmB,CAChC,GAAW,EACX,WAAwB,EACxB,QAA4B,EAC5B,kBAAgC;IAEhC,+BAA+B;IAC/B,SAAS,CAAC,IAAI,CAAC,IAAI,CAAC,GAAG,EAAE,KAAK,CAAC,IAAI,CAAC,CAAC,CAAC;IAEtC,6CAA6C;IAC7C,MAAM,SAAS,GAAG,IAAI,CAAC,IAAI,CAAC,GAAG,EAAE,GAAG,KAAK,CAAC,IAAI,SAAS,CAAC,CAAC;IACzD,SAAS,CAAC,SAAS,CAAC,CAAC;IACrB,MAAM,UAAU,GAAoB;QAClC,EAAE,IAAI,EAAE,UAAU,EAAE,OAAO,EAAE,kBAAkB,EAAE;QACjD;YACE,IAAI,EAAE,+BAA+B;YACrC,OAAO,EAAE,oCAAoC;SAC9C;QACD;YACE,IAAI,EAAE,8BAA8B;YACpC,OAAO,EAAE,mCAAmC;SAC7C;KACF,CAAC;IACF,KAAK,MAAM,GAAG,IAAI,UAAU,EAAE,CAAC;QAC7B,MAAM,SAAS,CAAC,IAAI,CAAC,IAAI,CAAC,SAAS,EAAE,GAAG,CAAC,IAAI,CAAC,EAAE,GAAG,CAAC,OAAO,CAAC,CAAC;IAC/D,CAAC;IAED,IAAI,QAAQ,IAAI,QAAQ,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;QACpC,sDAAsD;QACtD,KAAK,MAAM,GAAG,IAAI,QAAQ,EAAE,CAAC;YAC3B,MAAM,OAAO,GAAG,eAAe,CAAC,GAAG,CAAC,IAAI,CAAC,CAAC;YAC1C,IAAI,kBAAkB,EAAE,GAAG,CAAC,OAAO,CAAC;gBAAE,SAAS;YAC/C,MAAM,WAAW,GAAG,IAAI,CAAC,IAAI,CAAC,GAAG,EAAE,GAAG,KAAK,CAAC,IAAI,IAAI,OAAO,EAAE,CAAC,CAAC;YAC/D,SAAS,CAAC,WAAW,CAAC,CAAC;YACvB,MAAM,OAAO,GAAG,GAAG,CAAC,IAAI,KAAK,SAAS,CAAC,CAAC,CAAC,WAAW,CAAC,CAAC,CAAC,GAAG,CAAC,IAAI,CAAC;YAChE,MAAM,gBAAgB,CAAC,WAAW,EAAE,OAAO,CAAC,CAAC;QAC/C,CAAC;IACH,CAAC;SAAM,CAAC;QACN,mBAAmB;QACnB,MAAM,gBAAgB,CAAC,IAAI,CAAC,IAAI,CAAC,GAAG,EAAE,KAAK,CAAC,IAAI,CAAC,EAAE,WAAW,CAAC,CAAC;IAClE,CAAC;AACH,CAAC"}
|
|
@@ -0,0 +1,9 @@
|
|
|
1
|
+
{
|
|
2
|
+
"version": "0.2.10",
|
|
3
|
+
"description": "Python typecheck fixes for two bundled skill scripts; validate_html.py runs on Python 3.9 again.",
|
|
4
|
+
"breaking": false,
|
|
5
|
+
"recommendMigrate": false,
|
|
6
|
+
"changelog": "atw-prototype's comparison-page generator (build_explorer.py) now passes the Python typecheck; its behaviour is unchanged and it still needs Python 3.10+. oxy-learning-hub's validate_html.py adds from __future__ import annotations, which fixes a crash on import under Python 3.9 and its typecheck error.",
|
|
7
|
+
"migrations": [],
|
|
8
|
+
"notes": "No migration required. Two bundled skill scripts changed; no files were added, deleted or renamed. They update as Template updated where the project left them untouched; where a project edited them locally, atw update asks before replacing."
|
|
9
|
+
}
|
|
@@ -0,0 +1,9 @@
|
|
|
1
|
+
{
|
|
2
|
+
"version": "0.2.9",
|
|
3
|
+
"description": "atw-ui ships for building and reviewing screens, atw-prototype can compare visual directions side by side, and UI work gets a place in the ticket chain.",
|
|
4
|
+
"breaking": false,
|
|
5
|
+
"recommendMigrate": false,
|
|
6
|
+
"changelog": "New bundled skill atw-ui: implements, polishes and reviews screens once a visual direction is chosen; inside a task it runs only from /atw-implement, and read-only at acceptance. atw-prototype keeps its logic branch and rebuilds its UI branch in two stages: several radically different mockups compared in an offline comparison page (generator included, Python 3.10+), then, when the question is whether a page works, the chosen direction deepened into an interactive prototype over a pure logic module. The chosen direction is recorded in the task as ui-direction.md. The method and the comparison page are adapted from oil-ui (MIT). Both skills are written in Chinese. The ticket chain now covers UI: atw-spec has a UI and Design section, atw-tickets adds UI acceptance items inside vertical slices plus optional design-foundation and visual-pass tickets, atw-implement builds UI parts with /atw-ui and keeps screenshots in the task, and atw-code-review gains a Visual axis that reviews screenshots without code, still dispatched as atw-review and skipped when no screenshots are passed. workflow.md reflects the third review, relays every report, asks for screenshot evidence on UI criteria at acceptance, and routes UI work to /atw-ui. New projects get .atw/spec/frontend/design-system.md for the project's visual rules.",
|
|
7
|
+
"migrations": [],
|
|
8
|
+
"notes": "No migration required. Since v0.2.8, templates gained 15 files and changed 12; none were deleted or renamed. The new atw-ui and atw-prototype files land through the standard missing-file branch of atw update. Changed skills (atw-prototype, atw-spec, atw-tickets, atw-implement, atw-code-review, atw-update-spec, atw-spec-bootstrap) and .atw/workflow.md update as Template updated where the project left them untouched; where a project edited them locally, atw update asks before replacing. .atw/spec/ is user content and atw update never writes it, so existing projects do not receive design-system.md — copy the template or let atw-ui read the current theme and shared components instead."
|
|
9
|
+
}
|
|
@@ -317,9 +317,9 @@ One ticket at a time. Run `tickets.py frontier`, pick one, `tickets.py claim NN`
|
|
|
317
317
|
Stop ③: tell the user to run `/atw-implement` for the claimed ticket. You may not invoke it yourself, and you may not do the implementation inline instead. One user invocation per ticket.
|
|
318
318
|
That one run is a closed chain and must not be broken up from the outside: implement (test-first where it fits) → run tests, full suite on the last pass → review → handle findings → write spec updates back → commit. Never instruct it to skip the review or the commit.
|
|
319
319
|
Findings triage: spec-axis findings and anything the standards axis calls a hard violation get fixed first, then a full re-review, then the commit. Judgement calls ship and get reported.
|
|
320
|
-
Relay
|
|
320
|
+
Relay every review report to the user verbatim — Standards and Spec, plus Visual when the ticket changed UI — even when the verdict is "nothing found". No report reaching you is not a passing review.
|
|
321
321
|
Any sub-agent dispatched from here starts its prompt with `Active task: <task path from task.py current>` — the role files read that line to find the task, and it is the context hooks' fallback when session resolution misses.
|
|
322
|
-
Main-session default: run the process; the implementation itself is written inside `/atw-implement`, never by a dispatched `atw-implement-agent` — that role file is reserved and is not a step in this flow. The only sub-agent this phase raises is `atw-review` (twice, from inside `/atw-implement`). Sub-agent self-exemption: this breadcrumb reaches sub-agent turns on some hosts, so if you are already running as `atw-review`, do NOT spawn another `atw-review` — do the review you were dispatched for. Dispatch is main session only.
|
|
322
|
+
Main-session default: run the process; the implementation itself is written inside `/atw-implement`, never by a dispatched `atw-implement-agent` — that role file is reserved and is not a step in this flow. The only sub-agent this phase raises is `atw-review` (twice, from inside `/atw-implement` — three times when the ticket changes UI and a Visual review runs). Sub-agent self-exemption: this breadcrumb reaches sub-agent turns on some hosts, so if you are already running as `atw-review`, do NOT spawn another `atw-review` — do the review you were dispatched for. Dispatch is main session only.
|
|
323
323
|
Then `tickets.py done NN` and back to the frontier. When the frontier is empty, run `task.py set-status <task> accept`.
|
|
324
324
|
[/workflow-state:implement]
|
|
325
325
|
|
|
@@ -332,7 +332,7 @@ Then `tickets.py done NN` and back to the frontier. When the frontier is empty,
|
|
|
332
332
|
|
|
333
333
|
[workflow-state:accept]
|
|
334
334
|
Read-only from here. Do not open new work, do not fix things you notice — file them as tickets or a follow-up task instead.
|
|
335
|
-
Walk the acceptance criteria in `prd.md` one by one and report which are met, with evidence. Confirm `tickets.py summary` shows every ticket `done` and `git status --porcelain` is clean.
|
|
335
|
+
Walk the acceptance criteria in `prd.md` one by one and report which are met, with evidence; for UI criteria the evidence is a screenshot of the named screen, state and viewport (`/atw-ui` can review read-only). Confirm `tickets.py summary` shows every ticket `done` and `git status --porcelain` is clean.
|
|
336
336
|
Stop ④: present that and wait for the user to accept. Acceptance is the user's judgement, not yours.
|
|
337
337
|
Once accepted, run `task.py archive <task>` — status goes to `completed` and the task moves to `archive/`.
|
|
338
338
|
[/workflow-state:accept]
|
|
@@ -363,6 +363,7 @@ When a user request matches one of these intents inside an active task, route fi
|
|
|
363
363
|
- Writing or revising the spec → `/atw-spec`
|
|
364
364
|
- Slicing a confirmed spec into tickets → `/atw-tickets`
|
|
365
365
|
- Starting a claimed ticket → `/atw-implement` (the user runs it; stop ③)
|
|
366
|
+
- Building or polishing a screen for a claimed ticket → `/atw-ui`, used from inside `/atw-implement`
|
|
366
367
|
- Same bug fixed more than once → `/atw-diagnosing-bugs`
|
|
367
368
|
- Knowledge worth keeping outside a ticket → `/atw-update-spec`
|
|
368
369
|
|
|
@@ -462,6 +463,7 @@ Curate `check.jsonl` so the review sub-agents dispatched during Phase 2 get the
|
|
|
462
463
|
|
|
463
464
|
- **Spec files** — `.atw/spec/<package>/<layer>/index.md` and any specific guideline files (`error-handling.md`, `conventions.md`, etc.) relevant to this task
|
|
464
465
|
- **Research files** — `{TASK_DIR}/research/*.md` the review axes will need to consult
|
|
466
|
+
- **UI design files**, when the task changes what a user sees — the UI layer's `design-system.md` and `{TASK_DIR}/ui-direction.md` if `/atw-prototype` left one
|
|
465
467
|
|
|
466
468
|
**What NOT to put in**:
|
|
467
469
|
|
|
@@ -616,7 +618,7 @@ That single run is a closed chain:
|
|
|
616
618
|
|
|
617
619
|
1. Implement, test-first where the change suits it
|
|
618
620
|
2. Run tests periodically; a full-suite run on the last pass
|
|
619
|
-
3. Review the change on both axes — spec compliance and coding standards
|
|
621
|
+
3. Review the change on both axes — spec compliance and coding standards — plus a Visual axis on screenshots when the ticket changes UI (built with `/atw-ui`)
|
|
620
622
|
4. Handle the findings (see triage below)
|
|
621
623
|
5. Write new knowledge back into `.atw/spec/`
|
|
622
624
|
6. Commit to the current branch
|
|
@@ -637,7 +639,7 @@ Spec updates belong in the same chain, before the commit — knowledge that land
|
|
|
637
639
|
|
|
638
640
|
#### 2.3 Relay the review reports `[required · repeatable]`
|
|
639
641
|
|
|
640
|
-
Pass
|
|
642
|
+
Pass every review report back to the user **as written**. Do not merge them, do not re-rank them, do not pick a winner, and do not summarize a clean report away — "checked, nothing found" is still a report the user is entitled to see.
|
|
641
643
|
|
|
642
644
|
Not receiving a report is not the same as a review that passed. If no report came back, the review did not run; say so and re-run it rather than proceeding.
|
|
643
645
|
|
|
@@ -674,7 +676,7 @@ Goal: confirm with the user that the work is actually done, then archive it.
|
|
|
674
676
|
|
|
675
677
|
**Read-only.** Do not start new work here and do not fix problems you notice in passing — file them as tickets or a follow-up task. A "quick fix" at this point is unreviewed, uncommitted work sitting between the user's acceptance and the archive.
|
|
676
678
|
|
|
677
|
-
Walk `prd.md`'s acceptance criteria one at a time and report, per criterion, whether it is met and what the evidence is. Also confirm:
|
|
679
|
+
Walk `prd.md`'s acceptance criteria one at a time and report, per criterion, whether it is met and what the evidence is. For UI criteria the evidence is a screenshot of the named screen, state and viewport; `/atw-ui` can review the screens read-only against the spec and the project's `design-system.md`. Problems it finds become tickets, not fixes. Also confirm:
|
|
678
680
|
|
|
679
681
|
```bash
|
|
680
682
|
python3 ./.atw/scripts/tickets.py summary # every ticket done
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: atw-code-review
|
|
3
|
-
description: "
|
|
3
|
+
description: "沿两个维度审查自某个固定点（提交、分支、标签或合并基点）以来的变更——标准（代码是否遵循了该仓库的文档化编码标准？）和规格（代码是否符合原始问题/规格的要求?）。在并行子代理中同时运行这两项审查；变更涉及界面且调用方提供了截图时，再加第三个维度——视觉（渲染出来的画面是否满足界面验收标准和项目设计规范）。各维度结果并排显示。当用户希望审查某个分支、拉取请求、进行中的更改，或要求“审查自 X 以来”的变更时，请使用此功能。"
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
Two-axis review of the diff between `HEAD` and a fixed point the user supplies:
|
|
@@ -10,6 +10,12 @@ Two-axis review of the diff between `HEAD` and a fixed point the user supplies:
|
|
|
10
10
|
|
|
11
11
|
Both axes run as **parallel sub-agents** so they don't pollute each other's context, then this skill aggregates their findings.
|
|
12
12
|
|
|
13
|
+
When the change touches what a user sees and the caller passed screenshots, a third axis runs alongside them:
|
|
14
|
+
|
|
15
|
+
- **Visual** — does the screen, as rendered, meet the UI acceptance criteria and the project's design rules?
|
|
16
|
+
|
|
17
|
+
It is skipped when no screenshots were passed, and the final report says so.
|
|
18
|
+
|
|
13
19
|
**This skill only reports — it edits nothing.** Neither this skill nor either sub-agent writes to a source file: not to fix a finding, not to tidy something noticed in passing. They read the frozen patch and produce findings. Hand every finding back to whoever called the review — the user, or `/atw-implement` — and let the caller decide what changes. A reviewer that fixes what it found leaves no independent record of what was wrong, and the next review reads its own edits as the baseline.
|
|
14
20
|
|
|
15
21
|
The issue tracker should have been provided to you. If `docs/agents/issue-tracker.md` is missing, tell the user to call the Skill tool for `atw-init-repo`, which asks which tracker this repo uses and writes that file.
|
|
@@ -41,7 +47,7 @@ git ls-files --others --exclude-standard -z |
|
|
|
41
47
|
- `git ls-files --others` lists **files**, so no directory expansion is needed. (`git status --porcelain` reports a new directory as a single `?? newdir/` entry — that is why it isn't used here.)
|
|
42
48
|
- `git diff --no-index` **exits 1 when it finds a difference**. That is the normal result, not a failure — hence the `|| true`.
|
|
43
49
|
- Nothing writes to the index, so review stays read-only and never contends for `index.lock`.
|
|
44
|
-
- Cap the size of any single untracked file you inline. `--binary` base64-encodes content, so one image or build artifact can swamp the patch and both sub-agents' context. Over the cap, record the path and skip the body, and leave a line in the patch saying so.
|
|
50
|
+
- Cap the size of any single untracked file you inline. `--binary` base64-encodes content, so one image or build artifact can swamp the patch and both sub-agents' context. Over the cap, record the path and skip the body, and leave a line in the patch saying so. Screenshots in the task's `screenshots/` are evidence for the Visual axis, not code: always record their paths and skip their bodies.
|
|
45
51
|
|
|
46
52
|
Check that `$patch` is non-empty — this replaces the old "diff is non-empty" check. Also note the commit list via `git log <fixed-point>..HEAD --oneline`. If the patch is large, check its total size before spawning: both sub-agents receive it, so the token cost is doubled.
|
|
47
53
|
|
|
@@ -79,9 +85,9 @@ Each smell reads *what it is* → *how to fix*; match it against the diff:
|
|
|
79
85
|
- **Middle Man** — a class or function that mostly just delegates onward. → cut it, call the real target direct.
|
|
80
86
|
- **Refused Bequest** — a subclass or implementer that ignores or overrides most of what it inherits. → drop the inheritance, use composition.
|
|
81
87
|
|
|
82
|
-
### 4. Spawn
|
|
88
|
+
### 4. Spawn the sub-agents in parallel
|
|
83
89
|
|
|
84
|
-
|
|
90
|
+
The Standards and Spec sub-agents read the **frozen patch from step 1** and run **no git commands of their own** — same input, no chance of one axis seeing a file the other missed, and no re-deriving the untracked list from memory.
|
|
85
91
|
|
|
86
92
|
**Standards sub-agent prompt** — include:
|
|
87
93
|
|
|
@@ -97,9 +103,18 @@ Both sub-agents read the **frozen patch from step 1** and run **no git commands
|
|
|
97
103
|
|
|
98
104
|
If the spec is missing, skip the Spec sub-agent and note this in the final report.
|
|
99
105
|
|
|
106
|
+
**Visual sub-agent prompt** (only when screenshots were passed) — the Visual sub-agent judges what it sees, so it gets **no patch, no code, and no build history**. Include:
|
|
107
|
+
|
|
108
|
+
- The screenshot paths, each labelled with screen, state and logical viewport.
|
|
109
|
+
- The spec's UI and Design section and the ticket's UI acceptance criteria.
|
|
110
|
+
- The path to the UI layer's `design-system.md` in `.atw/spec/`, if the project has one.
|
|
111
|
+
- The brief: "Look at every screenshot before judging. Report: (a) UI acceptance criteria not met, citing the screenshot; (b) departures from the project's design rules — colours, type sizes, spacing or components outside them; (c) the one to three biggest visual problems — hierarchy, alignment, crowding, overflow, unreadable text — each with location, observation and a concrete fix. Distinguish observable defects from taste. Do not open source files. If you cannot view images, say so and stop. Under 400 words."
|
|
112
|
+
|
|
113
|
+
This sub-agent needs a model that can view images. If none is available, skip it and say in the final report that the Visual axis did not run.
|
|
114
|
+
|
|
100
115
|
### 5. Aggregate
|
|
101
116
|
|
|
102
|
-
Present the
|
|
117
|
+
Present the reports under `## Standards` and `## Spec` headings — plus `## Visual` when that axis ran — verbatim or lightly cleaned. Do **not** merge or rerank findings — the axes are deliberately separate (see _Why two axes_).
|
|
103
118
|
|
|
104
119
|
End with a one-line summary: total findings per axis, and the worst issue _within each axis_ (if any). Don't pick a single winner across axes — that's the reranking the separation exists to prevent.
|
|
105
120
|
|
|
@@ -111,3 +126,5 @@ A change can pass one axis and fail the other:
|
|
|
111
126
|
- Code that does exactly what the issue asked but breaks the project's conventions → **Spec pass, Standards fail.**
|
|
112
127
|
|
|
113
128
|
Reporting them separately stops one axis from masking the other.
|
|
129
|
+
|
|
130
|
+
The Visual axis exists for the same reason: code can match the spec and every standard and still render as an unreadable, overflowing screen. Neither code-reading axis can see that.
|
|
@@ -10,7 +10,9 @@ Use `/atw-tdd` where possible, at pre-agreed seams.
|
|
|
10
10
|
|
|
11
11
|
Run typechecking regularly, single test files regularly, and the full test suite once at the end.
|
|
12
12
|
|
|
13
|
-
|
|
13
|
+
If the work changes what a user sees, build that part with `/atw-ui` — logic stays test-first, the UI is verified on real screens. Capture screenshots into the task directory's `screenshots/` for each UI acceptance criterion (screen, state, viewport in the file name), and look at them before calling the work done.
|
|
14
|
+
|
|
15
|
+
Once done, use `/atw-code-review` to review the work. When screenshots were captured, pass their paths so the review runs its Visual axis.
|
|
14
16
|
|
|
15
17
|
Work the findings before committing. Fix what the review raised, then re-run the tests it touched.
|
|
16
18
|
|
|
@@ -1,67 +1,67 @@
|
|
|
1
|
-
#
|
|
1
|
+
# 逻辑原型
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
一个自包含的单文件 HTML——**可分享的演示**——任何人点按钮就能驱动一个状态模型。问题关于**业务逻辑、状态流转或数据形状**时用它：这类东西写在纸上看着合理，只有拿真实案例推一遍才会发现不对。
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
因为只有一个文件、什么都不用装，可以直接交给不写代码的人——设计师、产品经理、业务专家——让他们自己感受这个模型。所以它说的是他们的语言，不是代码的语言。
|
|
6
6
|
|
|
7
|
-
##
|
|
7
|
+
## 什么时候用这个形态
|
|
8
8
|
|
|
9
|
-
-
|
|
10
|
-
-
|
|
11
|
-
-
|
|
12
|
-
-
|
|
9
|
+
- “我不确定这个状态机能不能处理先 X 再 Y 的边界情况。”
|
|
10
|
+
- “这个数据模型到底能不能表示……这种情况？”
|
|
11
|
+
- “写接口之前，我想先感受一下它该长什么样。”
|
|
12
|
+
- 任何想要**按按钮、看状态变化**的场景。
|
|
13
13
|
|
|
14
|
-
|
|
14
|
+
如果问题是“这个界面应该长什么样”，分支选错了，改用 [UI.md](UI.md)。如果问题是“这个页面连同业务规则用起来对不对”，走 UI.md 的第二段：逻辑仍按本文件第 2 步写成纯模块，外面换成选定方向的设计界面。
|
|
15
15
|
|
|
16
|
-
##
|
|
16
|
+
## 流程
|
|
17
17
|
|
|
18
|
-
### 1.
|
|
18
|
+
### 1. 写下问题
|
|
19
19
|
|
|
20
|
-
|
|
20
|
+
写代码之前，先写清楚要原型化的状态模型和要回答的问题。一段话，放在演示页顶部（可见的介绍区，不只是代码注释）。回答错问题的逻辑原型纯属浪费——把问题写明，之后才能核对；无论用户此刻在场，还是之后回来再看。
|
|
21
21
|
|
|
22
|
-
### 2.
|
|
22
|
+
### 2. 把逻辑隔离成可移植的模块
|
|
23
23
|
|
|
24
|
-
|
|
24
|
+
真正回答问题的那部分逻辑，放在一个 `<script>` 块里，写成小而纯的模块，以后能整体搬进正式代码。外面的页面是一次性的，这个模块不是。
|
|
25
25
|
|
|
26
|
-
|
|
26
|
+
合适的形态取决于问题：
|
|
27
27
|
|
|
28
|
-
-
|
|
29
|
-
-
|
|
30
|
-
-
|
|
31
|
-
-
|
|
28
|
+
- **纯 reducer**——`(state, action) => state`，即“旧状态加一个动作，算出新状态”。适合动作是离散事件、状态是单个值的情况。
|
|
29
|
+
- **状态机**——显式列出状态和转移。适合“此刻哪些动作合法”本身就是问题一部分的情况。
|
|
30
|
+
- **一组纯函数**，作用在普通数据类型上。适合没有隐含的当前状态、只有数据变换的情况。
|
|
31
|
+
- **一个类或模块**，带清晰的方法接口。适合逻辑确实需要持有内部状态的情况。
|
|
32
32
|
|
|
33
|
-
|
|
33
|
+
按要回答的问题选最合适的形态，*而不是*按哪种最好接到页面上。保持纯净：不碰 DOM、不用 `document`、按钮事件不伸进模块内部。页面调用模块，反方向什么都不流动。这正是原型在完成使命后仍然有用的原因：问题回答完，验证过的 reducer / 状态机 / 函数集可以原样搬进正式模块。
|
|
34
34
|
|
|
35
|
-
### 3.
|
|
35
|
+
### 3. 做可分享的 HTML 文件
|
|
36
36
|
|
|
37
|
-
|
|
37
|
+
一个文件，纯 HTML/CSS/JS——不用框架、不用打包、不用服务器，全部内联，双击就能打开，转发多少次都能用。
|
|
38
38
|
|
|
39
|
-
|
|
39
|
+
写给不写代码的人看。所有标签都用**业务语言**，不用代码语言——按钮和状态读起来像业务，而不像 reducer。用大白话解释正在发生什么。
|
|
40
40
|
|
|
41
|
-
|
|
41
|
+
页面从上到下层次清楚：
|
|
42
42
|
|
|
43
|
-
1.
|
|
44
|
-
2.
|
|
45
|
-
3.
|
|
46
|
-
4.
|
|
43
|
+
1. **标题和一句话说明**：这个演示让你探索什么（即第 1 步的问题）。
|
|
44
|
+
2. **当前状态**：相关的完整状态，渲染成可读的面板（带标签的字段，不是原始 JSON），每次点击后重新渲染，让变化可见。能帮助非开发者理解时，标出刚刚变了什么。
|
|
45
|
+
3. **自由操作按钮**：每个动作一个按钮，始终可用，任何人都能按任意顺序试。每次点击派发对应动作并重新渲染状态。
|
|
46
|
+
4. **引导演练**：一组**场景**，每个场景一个标签页。每个标签页先用大白话描述场景——设定了什么情况、要留意什么——下面是这个场景**按顺序要按的按钮**。每一步都是真按钮：点它就执行该动作并进入下一步。开始演练时先重置到已知初始状态，保证每次跑出来一样。
|
|
47
47
|
|
|
48
|
-
|
|
48
|
+
场景要挑能暴露别扭情况的：正常路径、一个棘手的边界情况、一次本应被禁止的操作——就是那些在纸面上难以推演的。
|
|
49
49
|
|
|
50
|
-
|
|
50
|
+
好看但克制：干净的字体、宽松的间距、一种强调色。不要动画、不要花哨——不让任何东西和状态、按钮抢注意力。
|
|
51
51
|
|
|
52
|
-
### 4.
|
|
52
|
+
### 4. 交给对方
|
|
53
53
|
|
|
54
|
-
|
|
54
|
+
把文件发给对方，或直接替他们打开。他们有空时会点完演练、自由操作；最有价值的时刻是他们说“等等，这不应该能做到”或“咦，我以为 X 会不一样”——那些是*想法*里的缺陷，正是原型要找的。他们想要新动作或新场景，就加上。原型是会演进的。
|
|
55
55
|
|
|
56
|
-
### 5.
|
|
56
|
+
### 5. 记录结论，收起原型
|
|
57
57
|
|
|
58
|
-
|
|
58
|
+
原型回答完问题后，先记录结论，再按 [SKILL](SKILL.md) 的规则收起原型。逻辑原型的对应关系：验证过的 reducer / 状态机 / 函数集搬进正式模块（决定被吸收）；HTML 外壳跟着进入保存原型的一次性分支——它是自包含的单文件，在那里随时能重新打开。
|
|
59
59
|
|
|
60
|
-
##
|
|
60
|
+
## 反模式
|
|
61
61
|
|
|
62
|
-
-
|
|
63
|
-
-
|
|
64
|
-
-
|
|
65
|
-
-
|
|
66
|
-
-
|
|
67
|
-
-
|
|
62
|
+
- **不要写测试。** 需要测试的原型已经不是原型了。
|
|
63
|
+
- **不要接真实数据库。** 除非问题本身就是持久化，否则用内存状态。
|
|
64
|
+
- **不要泛化。** 不考虑“以后要支持 X 怎么办”。原型只回答一个问题。
|
|
65
|
+
- **不要把逻辑和页面搅在一起。** 纯模块一旦引用 DOM、`document` 或按钮事件，就没法搬走了。页面只是纯模块外面的一层薄壳。
|
|
66
|
+
- **不要用框架、打包工具或服务器。** 对方双击就能打开的一个文件；React 应用或开发服务器会破坏“可分享”。
|
|
67
|
+
- **不要把 HTML 外壳带进生产。** 页面是为手动点击优化的，值得保留的是它背后的逻辑模块。
|
|
@@ -1,26 +1,28 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: atw-prototype
|
|
3
|
-
description: "
|
|
3
|
+
description: "构建一次性原型来解答设计问题。用于验证状态模型或业务逻辑是否合理、探索界面应该长什么样（多个风格方向并排对比后由用户选定），或把选定方向做成能完整点一遍、带业务逻辑的可交互原型。原型只用于做决定，不是正式实现；按选定方向做正式界面、精修和评审交给 atw-ui。"
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Prototype
|
|
7
7
|
|
|
8
|
-
|
|
8
|
+
原型是**为回答一个问题而写、用完就扔的代码**。问题决定原型的形态。它属于 discover 阶段：产出是一个决定，不是可以上线的代码。
|
|
9
9
|
|
|
10
|
-
##
|
|
10
|
+
## 选分支
|
|
11
11
|
|
|
12
|
-
|
|
12
|
+
先从用户的请求、相关代码判断要回答的是哪个问题；用户在场时可以直接问：
|
|
13
13
|
|
|
14
|
-
-
|
|
15
|
-
-
|
|
14
|
+
- **“这套逻辑 / 状态模型对不对？”** → [LOGIC.md](LOGIC.md)。做一个可分享的单文件 HTML：自由操作的按钮加按标签页划分的引导演练，把纸面上难以推演的状态组合跑一遍，让不写代码的人也能自己操作。
|
|
15
|
+
- **“这个界面应该长什么样？”** 或 **“这个页面用起来对不对？”** → [UI.md](UI.md)。分两段：先做几个风格明显不同的方向放进对比页，由用户选定；需要时再把选定方向深化成带业务逻辑的可交互原型，业务逻辑按 LOGIC.md 的方式写成独立的纯模块。
|
|
16
16
|
|
|
17
|
-
|
|
17
|
+
两个分支的产物差别很大，选错等于白做。问题确实模糊且用户不在时，按周边代码选：后端模块走逻辑，页面或组件走界面；并在原型顶部写明这个假设。
|
|
18
18
|
|
|
19
|
-
|
|
19
|
+
请求的是按已定方向做正式界面、精修现有页面、截图还原或界面评审时，不属于原型，交给 atw-ui。
|
|
20
20
|
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
21
|
+
## 两个分支共用的规则
|
|
22
|
+
|
|
23
|
+
1. **从第一天起就是一次性的，并且一眼能看出来。** 原型放在它将来要用的位置旁边（所服务的模块或页面附近），让上下文一目了然；命名要让人一看就知道这是原型，不是正式代码。一次性的界面路由遵循项目现有的路由约定，不自创新的顶层结构。
|
|
24
|
+
2. **启动零门槛。** 应用内的界面原型用项目任务运行器的一条命令启动，例如 `pnpm <name>`、`python <path>`、`bun <path>`；逻辑演示和独立小样是双击就能打开的单个 HTML。无论哪种，都不需要动脑就能跑起来。
|
|
25
|
+
3. **默认不持久化。** 状态只放在内存里。持久化是原型要*检验*的对象，而不是它的依赖。问题明确涉及数据库时，用临时库或本地文件，并用“PROTOTYPE — 可删除”这类名字标明。
|
|
26
|
+
4. **不打磨工程质量。** 不写测试，错误处理只做到能跑，不做抽象。目的是尽快学到东西。界面方向的视觉质量另当别论：方向小样要做到足以代表这个方向，否则比较没有意义。
|
|
27
|
+
5. **把状态摆出来。** 每次操作后（逻辑）或每次切换方案时（界面），把相关的完整状态打印或渲染出来，让用户看见变化。
|
|
28
|
+
6. **用完就收。** 把验证过的决定写进正式代码或 ATW 任务的需求文档，再把原型本身作为**一手资料**保存：提交到一个一次性分支，不进主分支，并在对应任务或需求单上留下指向这个分支的说明。结论也要记下——它回答了什么问题、答案是什么——写进任务记录或提交信息。主分支只保留验证过的决定。
|