@agimon-ai/doompi-style-system 0.0.1-alpha.76
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/LICENSE +21 -0
- package/README.md +53 -0
- package/package.json +135 -0
- package/skills/design-workflow/SKILL.md +84 -0
package/LICENSE
ADDED
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 Vuong Ngo
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|
package/README.md
ADDED
|
@@ -0,0 +1,53 @@
|
|
|
1
|
+
# @agimon-ai/doompi-style-system
|
|
2
|
+
|
|
3
|
+
Optional DoomPi integration for building disposable interactive story previews with `@agimon-ai/style-system`.
|
|
4
|
+
|
|
5
|
+
When this package and `@agimon-ai/doompi-author` are both installed, Author shows an **Open story preview** action. The temporary tab reads the focused `.stories.js`, `.stories.jsx`, `.stories.ts`, or `.stories.tsx` source, discovers exact named exports, builds only after an explicit action, runs the compiled HTML in an isolated iframe, and retains the composer for source-targeted feedback.
|
|
6
|
+
|
|
7
|
+
The portable `doompi-design` binary also works without Pi, DoomPi, Author, or MCP. Discovery commands delegate to the published style-system CLI. Structured commands provide exact story metadata, bounded checks, stale-evidence verification, and explicit preview builds:
|
|
8
|
+
|
|
9
|
+
```bash
|
|
10
|
+
doompi-design metadata --story-path src/Button.stories.tsx
|
|
11
|
+
doompi-design check --target docs/specs/button/design-target.json --report docs/specs/button/design-check.json
|
|
12
|
+
doompi-design verify --report docs/specs/button/design-check.json
|
|
13
|
+
doompi-design preview --app-path . --story-path src/Button.stories.tsx --story-export Playground --output .tmp/button.html
|
|
14
|
+
```
|
|
15
|
+
|
|
16
|
+
Use `--workspace <path>` when the process working directory is not the admitted project root.
|
|
17
|
+
|
|
18
|
+
## Opt in
|
|
19
|
+
|
|
20
|
+
Install both packages, then add them to a layer used by your selected major mode:
|
|
21
|
+
|
|
22
|
+
```yaml
|
|
23
|
+
layers:
|
|
24
|
+
design:
|
|
25
|
+
packages:
|
|
26
|
+
- '@agimon-ai/doompi-author'
|
|
27
|
+
- '@agimon-ai/doompi-style-system'
|
|
28
|
+
majorMode:
|
|
29
|
+
design:
|
|
30
|
+
description: Interactive source-backed story design.
|
|
31
|
+
layers: [design]
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
The package is not added to DoomPi's default distribution mode.
|
|
35
|
+
|
|
36
|
+
Generated HTML is a preview artifact. AI changes must target the underlying story or component source. Refresh the preview after edits before treating it as visually verified.
|
|
37
|
+
|
|
38
|
+
## Image export
|
|
39
|
+
|
|
40
|
+
**Export PNG**, **Prepare annotation**, and **Send to AI** render a fresh image from current source through style-system. Users can mark one normalized region or comment on the whole frozen image. The image does not include transient interaction state inside the iframe, and the UI states this limitation instead of presenting it as an exact capture of iframe state.
|
|
41
|
+
|
|
42
|
+
## Security
|
|
43
|
+
|
|
44
|
+
Preview building executes trusted workspace source on the server. Project, story, and generated artifact paths are realpath-fenced to the admitted workspace. Browser previews use a script-only opaque-origin iframe and a restrictive content security policy. Remote assets are rejected by that policy, so preview assets must be included in the single-file bundle.
|
|
45
|
+
|
|
46
|
+
## Development
|
|
47
|
+
|
|
48
|
+
```bash
|
|
49
|
+
pnpm --filter @agimon-ai/doompi-style-system lint
|
|
50
|
+
pnpm --filter @agimon-ai/doompi-style-system typecheck
|
|
51
|
+
pnpm --filter @agimon-ai/doompi-style-system test
|
|
52
|
+
pnpm --filter @agimon-ai/doompi-style-system build
|
|
53
|
+
```
|
package/package.json
ADDED
|
@@ -0,0 +1,135 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "@agimon-ai/doompi-style-system",
|
|
3
|
+
"version": "0.0.1-alpha.76",
|
|
4
|
+
"description": "Optional DoomPi story preview integration for the style-system package.",
|
|
5
|
+
"keywords": [
|
|
6
|
+
"ai",
|
|
7
|
+
"coding-agent",
|
|
8
|
+
"developer-tools",
|
|
9
|
+
"doompi",
|
|
10
|
+
"pi-package",
|
|
11
|
+
"storybook",
|
|
12
|
+
"style-system",
|
|
13
|
+
"ui-preview"
|
|
14
|
+
],
|
|
15
|
+
"homepage": "https://agimon.ai",
|
|
16
|
+
"bugs": {
|
|
17
|
+
"url": "https://github.com/AgiFlow/doompi/issues"
|
|
18
|
+
},
|
|
19
|
+
"license": "MIT",
|
|
20
|
+
"author": "Vuong Ngo",
|
|
21
|
+
"repository": {
|
|
22
|
+
"type": "git",
|
|
23
|
+
"url": "git+https://github.com/AgiFlow/doompi.git",
|
|
24
|
+
"directory": "layers/design/doompi-style-system"
|
|
25
|
+
},
|
|
26
|
+
"bin": {
|
|
27
|
+
"doompi-design": "./dist/cli.mjs"
|
|
28
|
+
},
|
|
29
|
+
"files": [
|
|
30
|
+
"dist",
|
|
31
|
+
"skills",
|
|
32
|
+
"README.md"
|
|
33
|
+
],
|
|
34
|
+
"type": "module",
|
|
35
|
+
"main": "./dist/index.cjs",
|
|
36
|
+
"types": "./dist/index.d.mts",
|
|
37
|
+
"jsnext:main": "./dist/index.mjs",
|
|
38
|
+
"exports": {
|
|
39
|
+
".": {
|
|
40
|
+
"types": "./dist/index.d.mts",
|
|
41
|
+
"import": "./dist/index.mjs",
|
|
42
|
+
"require": "./dist/index.cjs"
|
|
43
|
+
},
|
|
44
|
+
"./api-contracts": {
|
|
45
|
+
"types": "./dist/api-contracts.d.mts",
|
|
46
|
+
"import": "./dist/api-contracts.mjs",
|
|
47
|
+
"require": "./dist/api-contracts.cjs"
|
|
48
|
+
},
|
|
49
|
+
"./cli": {
|
|
50
|
+
"types": "./dist/cli.d.mts",
|
|
51
|
+
"import": "./dist/cli.mjs",
|
|
52
|
+
"require": "./dist/cli.cjs"
|
|
53
|
+
},
|
|
54
|
+
"./extensions/pi": {
|
|
55
|
+
"types": "./dist/extensions/pi.d.mts",
|
|
56
|
+
"import": "./dist/extensions/pi.mjs",
|
|
57
|
+
"require": "./dist/extensions/pi.cjs"
|
|
58
|
+
},
|
|
59
|
+
"./extensions/server": {
|
|
60
|
+
"types": "./dist/extensions/server.d.mts",
|
|
61
|
+
"import": "./dist/extensions/server.mjs",
|
|
62
|
+
"require": "./dist/extensions/server.cjs"
|
|
63
|
+
},
|
|
64
|
+
"./extensions/web": {
|
|
65
|
+
"import": "./dist/extensions/web.mjs"
|
|
66
|
+
},
|
|
67
|
+
"./package.json": "./package.json"
|
|
68
|
+
},
|
|
69
|
+
"publishConfig": {
|
|
70
|
+
"access": "public"
|
|
71
|
+
},
|
|
72
|
+
"dependencies": {
|
|
73
|
+
"@agimon-ai/doompi-core": "0.0.1-alpha.75",
|
|
74
|
+
"@agimon-ai/doompi-web-components": "0.0.1-alpha.33",
|
|
75
|
+
"@agimon-ai/doompi-web-security": "0.0.1-alpha.35",
|
|
76
|
+
"@agimon-ai/style-system": "0.1.3",
|
|
77
|
+
"hono": "4.13.7",
|
|
78
|
+
"typebox": "1.3.30"
|
|
79
|
+
},
|
|
80
|
+
"devDependencies": {
|
|
81
|
+
"@agimon-ai/doompi-build": "0.0.1-alpha.4",
|
|
82
|
+
"@earendil-works/pi-coding-agent": "0.85.1",
|
|
83
|
+
"@types/node": "26.5.1",
|
|
84
|
+
"@types/react": "19.3.0",
|
|
85
|
+
"@types/react-dom": "19.3.0",
|
|
86
|
+
"@vitest/coverage-v8": "5.0.0",
|
|
87
|
+
"react": "19.3.0",
|
|
88
|
+
"react-dom": "19.3.0",
|
|
89
|
+
"tsdown": "0.23.0",
|
|
90
|
+
"typescript": "7.0.2",
|
|
91
|
+
"vitest": "5.0.0"
|
|
92
|
+
},
|
|
93
|
+
"peerDependencies": {
|
|
94
|
+
"@earendil-works/pi-coding-agent": "0.85.1"
|
|
95
|
+
},
|
|
96
|
+
"peerDependenciesMeta": {
|
|
97
|
+
"@earendil-works/pi-coding-agent": {
|
|
98
|
+
"optional": true
|
|
99
|
+
}
|
|
100
|
+
},
|
|
101
|
+
"engines": {
|
|
102
|
+
"node": ">=22.19.0"
|
|
103
|
+
},
|
|
104
|
+
"doompiServer": {
|
|
105
|
+
"entry": "./generated/server.ts",
|
|
106
|
+
"dist": "./dist/extensions/server.mjs",
|
|
107
|
+
"scopes": [
|
|
108
|
+
"session"
|
|
109
|
+
],
|
|
110
|
+
"contracts": {
|
|
111
|
+
"entry": "./src/exports/apiContracts.ts",
|
|
112
|
+
"dist": "./dist/api-contracts.mjs"
|
|
113
|
+
}
|
|
114
|
+
},
|
|
115
|
+
"doompiWeb": {
|
|
116
|
+
"pluginId": "style-system",
|
|
117
|
+
"channels": [],
|
|
118
|
+
"client": "./dist/extensions/web.mjs",
|
|
119
|
+
"scopes": [
|
|
120
|
+
"session"
|
|
121
|
+
]
|
|
122
|
+
},
|
|
123
|
+
"pi": {
|
|
124
|
+
"extensions": [
|
|
125
|
+
"./dist/extensions/pi.mjs"
|
|
126
|
+
]
|
|
127
|
+
},
|
|
128
|
+
"scripts": {
|
|
129
|
+
"build": "tsdown",
|
|
130
|
+
"test": "vitest --run",
|
|
131
|
+
"typecheck": "tsc --noEmit && tsc --noEmit -p tsconfig.web.json",
|
|
132
|
+
"lint": "oxlint . && oxfmt . --check",
|
|
133
|
+
"fixcode": "oxlint . --fix && oxfmt ."
|
|
134
|
+
}
|
|
135
|
+
}
|
|
@@ -0,0 +1,84 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: design-workflow
|
|
3
|
+
description: Use the DoomPi design workflow for source-backed interactive story design, component discovery, token guidance, validation, and an approved implementation specification.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Source-backed design workflow
|
|
7
|
+
|
|
8
|
+
Use this workflow when a feature needs an interactive UI target before production integration. The story is a target-state artifact, not a throwaway HTML mockup. Keep the target deterministic and source-backed so it can be reviewed and later connected to real APIs, hooks, stores, and routes.
|
|
9
|
+
|
|
10
|
+
## Keep context lean
|
|
11
|
+
|
|
12
|
+
Do not paste an entire component catalog, token list, or design-system manual into the conversation. Discover only what the current surface needs:
|
|
13
|
+
|
|
14
|
+
```bash
|
|
15
|
+
doompi-design list-shared-components
|
|
16
|
+
doompi-design list-app-components --app-path <project>
|
|
17
|
+
doompi-design get-css-classes --app-path <project> --category all
|
|
18
|
+
doompi-design list-themes --app-path <project>
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
If `doompi-design` is unavailable, use the published `@agimon-ai/style-system` CLI with the same commands. The workflow is portable and does not require Pi, DoomPi, Author, or MCP.
|
|
22
|
+
|
|
23
|
+
Use repository source as the authority for principles and managed tokens. In this repository, begin with:
|
|
24
|
+
|
|
25
|
+
- `packages/core/doompi-web-components/README.md`
|
|
26
|
+
- `packages/core/doompi-web-components/styles/tokens.css`
|
|
27
|
+
- the applicable project `style-system.config.yaml`
|
|
28
|
+
- applicable Vibe-Lint rule descriptions
|
|
29
|
+
|
|
30
|
+
The catalog is story-backed and may not include every exported component. Unknown components are unresolved, not proof that no component exists.
|
|
31
|
+
|
|
32
|
+
## Design
|
|
33
|
+
|
|
34
|
+
1. Identify the project, user journey, states, interactions, permissions, and responsive constraints.
|
|
35
|
+
2. Inspect and reuse an existing shared or application component before creating one.
|
|
36
|
+
3. Define deterministic fixtures for loading, empty, error, populated, and interaction states.
|
|
37
|
+
4. Build a Storybook story for a presentational View. Keep API hooks, stores, router calls, SDK calls, and side effects in a Container outside the story.
|
|
38
|
+
5. Use the configured semantic tokens and primitives. Do not invent raw palette values or arbitrary scale values to make a screenshot look right.
|
|
39
|
+
6. Build the interactive preview explicitly and inspect the actual interaction states. Generated HTML is a disposable artifact.
|
|
40
|
+
7. Edit the underlying story or component source, never generated preview HTML.
|
|
41
|
+
|
|
42
|
+
Rendering and component capture execute trusted workspace source. Do not run a file-polishing or mutating design command during review unless the user explicitly asks for that edit.
|
|
43
|
+
|
|
44
|
+
## Check
|
|
45
|
+
|
|
46
|
+
Run the explicit bounded check for the target after the story and relevant styles change:
|
|
47
|
+
|
|
48
|
+
```bash
|
|
49
|
+
doompi-design check --target <target-manifest.json>
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
The check is static and bounded. It reports separately:
|
|
53
|
+
|
|
54
|
+
- confirmed policy violations, such as raw theme colors or arbitrary scale values;
|
|
55
|
+
- recognized static classes and managed tokens;
|
|
56
|
+
- unresolved dynamic expressions, custom selectors, missing imports, or unsupported configuration;
|
|
57
|
+
- checked inputs, coverage limits, tool versions, and fingerprints.
|
|
58
|
+
|
|
59
|
+
A Tailwind class being recognized does not make it compliant. A missing generated class does not by itself make a class invalid because marker classes and ordinary custom CSS may be valid. Dynamic expressions and incomplete CSS context must not be reported as clean.
|
|
60
|
+
|
|
61
|
+
Resolve all required findings. A successful build, typecheck, or image render is not a design-compliance result.
|
|
62
|
+
|
|
63
|
+
## Approval and specification
|
|
64
|
+
|
|
65
|
+
After checks pass, inspect the preview and ask the user to explicitly approve the exact target snapshot, including story/export, fixtures, rendering options, and evidence revision. Do not infer approval from agent prose or a model-written field.
|
|
66
|
+
|
|
67
|
+
Only after explicit target approval, inspect the current implementation and write a repository Markdown bridge specification. Reuse the repository's existing Plan review and acceptance conventions when available. The spec should map each approved target component, state, action, and route to:
|
|
68
|
+
|
|
69
|
+
- current API, hook, store, and route source references;
|
|
70
|
+
- reused, adapted, or new components;
|
|
71
|
+
- data and permission contracts;
|
|
72
|
+
- loading, empty, error, and responsive behavior;
|
|
73
|
+
- mock-to-production integration work;
|
|
74
|
+
- executable acceptance checks, sequence, non-goals, and unresolved decisions.
|
|
75
|
+
|
|
76
|
+
Store the target and evidence with the project, for example:
|
|
77
|
+
|
|
78
|
+
```text
|
|
79
|
+
docs/specs/<feature>/target.md
|
|
80
|
+
docs/specs/<feature>/design-check.json
|
|
81
|
+
docs/specs/<feature>/spec.md
|
|
82
|
+
```
|
|
83
|
+
|
|
84
|
+
The target approval does not authorize implementation. Request separate implementation approval.
|