frontend-harness 0.1.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.
Files changed (77) hide show
  1. package/AGENTS.md +48 -0
  2. package/CLAUDE.md +48 -0
  3. package/README.md +262 -0
  4. package/dist/cli/index.d.ts +2 -0
  5. package/dist/cli/index.js +380 -0
  6. package/dist/cli/index.js.map +1 -0
  7. package/dist/runtime/builtin-skills.d.ts +6 -0
  8. package/dist/runtime/builtin-skills.js +269 -0
  9. package/dist/runtime/builtin-skills.js.map +1 -0
  10. package/dist/runtime/clean.d.ts +11 -0
  11. package/dist/runtime/clean.js +85 -0
  12. package/dist/runtime/clean.js.map +1 -0
  13. package/dist/runtime/command-taxonomy.d.ts +12 -0
  14. package/dist/runtime/command-taxonomy.js +72 -0
  15. package/dist/runtime/command-taxonomy.js.map +1 -0
  16. package/dist/runtime/context.d.ts +71 -0
  17. package/dist/runtime/context.js +153 -0
  18. package/dist/runtime/context.js.map +1 -0
  19. package/dist/runtime/graph.d.ts +12 -0
  20. package/dist/runtime/graph.js +211 -0
  21. package/dist/runtime/graph.js.map +1 -0
  22. package/dist/runtime/knowledge.d.ts +48 -0
  23. package/dist/runtime/knowledge.js +383 -0
  24. package/dist/runtime/knowledge.js.map +1 -0
  25. package/dist/runtime/plan.d.ts +18 -0
  26. package/dist/runtime/plan.js +571 -0
  27. package/dist/runtime/plan.js.map +1 -0
  28. package/dist/runtime/policy-provenance.d.ts +17 -0
  29. package/dist/runtime/policy-provenance.js +195 -0
  30. package/dist/runtime/policy-provenance.js.map +1 -0
  31. package/dist/runtime/project-discovery.d.ts +17 -0
  32. package/dist/runtime/project-discovery.js +166 -0
  33. package/dist/runtime/project-discovery.js.map +1 -0
  34. package/dist/runtime/project-paths.d.ts +6 -0
  35. package/dist/runtime/project-paths.js +47 -0
  36. package/dist/runtime/project-paths.js.map +1 -0
  37. package/dist/runtime/protocol-init.d.ts +50 -0
  38. package/dist/runtime/protocol-init.js +256 -0
  39. package/dist/runtime/protocol-init.js.map +1 -0
  40. package/dist/runtime/repair-decision.d.ts +3 -0
  41. package/dist/runtime/repair-decision.js +195 -0
  42. package/dist/runtime/repair-decision.js.map +1 -0
  43. package/dist/runtime/repair-packet.d.ts +7 -0
  44. package/dist/runtime/repair-packet.js +159 -0
  45. package/dist/runtime/repair-packet.js.map +1 -0
  46. package/dist/runtime/skills.d.ts +19 -0
  47. package/dist/runtime/skills.js +230 -0
  48. package/dist/runtime/skills.js.map +1 -0
  49. package/dist/runtime/state-explain.d.ts +2 -0
  50. package/dist/runtime/state-explain.js +106 -0
  51. package/dist/runtime/state-explain.js.map +1 -0
  52. package/dist/runtime/state.d.ts +10 -0
  53. package/dist/runtime/state.js +237 -0
  54. package/dist/runtime/state.js.map +1 -0
  55. package/dist/runtime/units.d.ts +10 -0
  56. package/dist/runtime/units.js +181 -0
  57. package/dist/runtime/units.js.map +1 -0
  58. package/dist/runtime/verification-commands.d.ts +11 -0
  59. package/dist/runtime/verification-commands.js +89 -0
  60. package/dist/runtime/verification-commands.js.map +1 -0
  61. package/dist/runtime/verify.d.ts +7 -0
  62. package/dist/runtime/verify.js +192 -0
  63. package/dist/runtime/verify.js.map +1 -0
  64. package/dist/schemas/types.d.ts +244 -0
  65. package/dist/schemas/types.js +2 -0
  66. package/dist/schemas/types.js.map +1 -0
  67. package/dist/schemas/validation.d.ts +2 -0
  68. package/dist/schemas/validation.js +21 -0
  69. package/dist/schemas/validation.js.map +1 -0
  70. package/dist/storage/json.d.ts +5 -0
  71. package/dist/storage/json.js +24 -0
  72. package/dist/storage/json.js.map +1 -0
  73. package/dist/storage/paths.d.ts +3 -0
  74. package/dist/storage/paths.js +9 -0
  75. package/dist/storage/paths.js.map +1 -0
  76. package/docs/DIRECTION.md +67 -0
  77. package/package.json +35 -0
package/AGENTS.md ADDED
@@ -0,0 +1,48 @@
1
+ <!-- frontend-harness:managed:start -->
2
+ # Frontend Harness Execution Policy for Codex
3
+
4
+ This project uses `frontend-harness` as a project-level execution policy layer.
5
+ The coding agent runtime remains responsible for its own agent loop, tools, context management, permissions, retries, subagents, and skill loading.
6
+ `frontend-harness` owns only deterministic project facts, execution contracts, validation evidence, project-local knowledge, and repair artifacts.
7
+
8
+ Required loop:
9
+ 1. Run `frontend-harness context --json` before planning edits.
10
+ 2. If agent planning input is useful, write only bounded hints (`intentSuggestion`, `constraintHints`, `componentHints`) to an agent decision JSON file and validate it with `frontend-harness decision check --json --file <agent-decision.json>`.
11
+ 3. Run `frontend-harness plan --json "<task>"` with optional `--agent-decision <agent-decision.json>`, or consume the existing `.frontend-harness/plans/latest.json` before editing.
12
+ 4. Edit only project files required by the system-owned plan and current task.
13
+ 5. Record every changed project file with `frontend-harness state record-change <file>`.
14
+ 6. Run `frontend-harness verify --json` and inspect the JSON result.
15
+ 7. If verification fails, run `frontend-harness repair packet --json`, inspect `.frontend-harness/repair/latest.json`, patch the relevant project files, record changes, and verify again.
16
+ 8. Before committing, inspect relevant project-local skills under `.frontend-harness/skills/` and follow the repository commit protocol.
17
+ 9. Stop only when `frontend-harness state next --json` returns `done` for the unchanged task scope.
18
+
19
+ Commit protocol:
20
+ - Use commit header format: `<type>(<scope>): <short description>`.
21
+ - Allowed commit types: `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `chore`.
22
+ - Keep the header concise and include verification evidence in the commit body or trailers when available.
23
+
24
+ Boundaries:
25
+ - Do not treat `frontend-harness` as an agent launcher or runtime wrapper.
26
+ - Do not edit `.frontend-harness/` generated artifacts manually; let harness commands write them.
27
+ - Do not interpret planning or repair decision JSON as shell commands, patch content, scheduler directives, graph execution, skill routing, or RAG instructions.
28
+ - Do not put workflow type, execution units, file paths, dependency graph, execution order, or verification commands into agent planning input; the system plan always owns those structures.
29
+ - Keep durable project knowledge under `.frontend-harness/knowledge/` and project-local skills under `.frontend-harness/skills/` when intentionally authored.
30
+
31
+ Useful commands:
32
+ - `frontend-harness context --json`
33
+ - `frontend-harness plan --json "<task>"`
34
+ - `frontend-harness state record-change <file>`
35
+ - `frontend-harness state record-change --from-git`
36
+ - `frontend-harness verify --json`
37
+ - `frontend-harness repair packet --json`
38
+ - `frontend-harness state next --json`
39
+ - `frontend-harness state explain --json`
40
+ - `frontend-harness skills list --json`
41
+ - `frontend-harness skills check --json`
42
+ - `frontend-harness knowledge promote --json --title "<title>" --body "<body>"`
43
+ - `frontend-harness knowledge check --json`
44
+ - `frontend-harness decision check --json --file <agent-decision.json>`
45
+ - `frontend-harness units check --json`
46
+ - `frontend-harness graph check --json`
47
+ - `frontend-harness repair decision check --json --file <repair-decision.json>`
48
+ <!-- frontend-harness:managed:end -->
package/CLAUDE.md ADDED
@@ -0,0 +1,48 @@
1
+ <!-- frontend-harness:managed:start -->
2
+ # Frontend Harness Execution Policy for Claude Code
3
+
4
+ This project uses `frontend-harness` as a project-level execution policy layer.
5
+ The coding agent runtime remains responsible for its own agent loop, tools, context management, permissions, retries, subagents, and skill loading.
6
+ `frontend-harness` owns only deterministic project facts, execution contracts, validation evidence, project-local knowledge, and repair artifacts.
7
+
8
+ Required loop:
9
+ 1. Run `frontend-harness context --json` before planning edits.
10
+ 2. If agent planning input is useful, write only bounded hints (`intentSuggestion`, `constraintHints`, `componentHints`) to an agent decision JSON file and validate it with `frontend-harness decision check --json --file <agent-decision.json>`.
11
+ 3. Run `frontend-harness plan --json "<task>"` with optional `--agent-decision <agent-decision.json>`, or consume the existing `.frontend-harness/plans/latest.json` before editing.
12
+ 4. Edit only project files required by the system-owned plan and current task.
13
+ 5. Record every changed project file with `frontend-harness state record-change <file>`.
14
+ 6. Run `frontend-harness verify --json` and inspect the JSON result.
15
+ 7. If verification fails, run `frontend-harness repair packet --json`, inspect `.frontend-harness/repair/latest.json`, patch the relevant project files, record changes, and verify again.
16
+ 8. Before committing, inspect relevant project-local skills under `.frontend-harness/skills/` and follow the repository commit protocol.
17
+ 9. Stop only when `frontend-harness state next --json` returns `done` for the unchanged task scope.
18
+
19
+ Commit protocol:
20
+ - Use commit header format: `<type>(<scope>): <short description>`.
21
+ - Allowed commit types: `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `chore`.
22
+ - Keep the header concise and include verification evidence in the commit body or trailers when available.
23
+
24
+ Boundaries:
25
+ - Do not treat `frontend-harness` as an agent launcher or runtime wrapper.
26
+ - Do not edit `.frontend-harness/` generated artifacts manually; let harness commands write them.
27
+ - Do not interpret planning or repair decision JSON as shell commands, patch content, scheduler directives, graph execution, skill routing, or RAG instructions.
28
+ - Do not put workflow type, execution units, file paths, dependency graph, execution order, or verification commands into agent planning input; the system plan always owns those structures.
29
+ - Keep durable project knowledge under `.frontend-harness/knowledge/` and project-local skills under `.frontend-harness/skills/` when intentionally authored.
30
+
31
+ Useful commands:
32
+ - `frontend-harness context --json`
33
+ - `frontend-harness plan --json "<task>"`
34
+ - `frontend-harness state record-change <file>`
35
+ - `frontend-harness state record-change --from-git`
36
+ - `frontend-harness verify --json`
37
+ - `frontend-harness repair packet --json`
38
+ - `frontend-harness state next --json`
39
+ - `frontend-harness state explain --json`
40
+ - `frontend-harness skills list --json`
41
+ - `frontend-harness skills check --json`
42
+ - `frontend-harness knowledge promote --json --title "<title>" --body "<body>"`
43
+ - `frontend-harness knowledge check --json`
44
+ - `frontend-harness decision check --json --file <agent-decision.json>`
45
+ - `frontend-harness units check --json`
46
+ - `frontend-harness graph check --json`
47
+ - `frontend-harness repair decision check --json --file <repair-decision.json>`
48
+ <!-- frontend-harness:managed:end -->
package/README.md ADDED
@@ -0,0 +1,262 @@
1
+ # frontend-harness
2
+
3
+ `frontend-harness` is an Execution Policy Layer for frontend teams using Codex or Claude Code.
4
+
5
+ It does not replace the agent runtime. Codex and Claude Code already provide the loop, tool execution, context handling, permissions, retries, subagents, and skill loading. `frontend-harness` adds the project-level rules those agents should follow inside a frontend repository.
6
+
7
+ The product goal is simple:
8
+
9
+ ```text
10
+ install once -> inject AGENTS.md / CLAUDE.md -> work normally with AI
11
+ ```
12
+
13
+ After initialization, team members should not need to manually run the harness loop. They keep asking Codex or Claude Code for frontend work in plain language. The injected project protocol and built-in project skills tell the agent how to plan, edit, verify, and repair.
14
+
15
+ ## What It Does
16
+
17
+ `frontend-harness` gives a project a deterministic execution contract:
18
+
19
+ ```text
20
+ context -> plan -> implement -> record changes -> verify -> repair -> done
21
+ ```
22
+
23
+ The CLI exists mainly as a protocol API for AI agents. Humans use it to install, initialize, and occasionally check health.
24
+
25
+ ## What It Is Not
26
+
27
+ `frontend-harness` is not another agent platform.
28
+
29
+ It should not rebuild:
30
+
31
+ - agent loops
32
+ - generic tool execution
33
+ - permission systems
34
+ - subagent orchestration
35
+ - long-running runtime launchers or supervised agent wrappers
36
+ - replacement workflows for Codex or Claude Code
37
+
38
+ Those belong to the official agent runtimes. This package owns only the frontend project policy around them.
39
+
40
+ ## Install
41
+
42
+ ```bash
43
+ npm install frontend-harness --save-dev
44
+ npx frontend-harness init
45
+ ```
46
+
47
+ `init` injects managed protocol blocks into:
48
+
49
+ - `AGENTS.md`
50
+ - `CLAUDE.md`
51
+
52
+ It also scaffolds built-in project skills under `.frontend-harness/skills/`:
53
+
54
+ - `frontend-discovery.md`
55
+ - `architecture-boundary.md`
56
+ - `ui-implementation.md`
57
+ - `prd-knowledge.md`
58
+ - `api-integration.md`
59
+ - `form-workflow.md`
60
+ - `frontend-test.md`
61
+ - `bug-fix.md`
62
+ - `requirement-change.md`
63
+ - `frontend-change-review.md`
64
+ - `git-commit.md`
65
+
66
+ Existing project skill files are preserved. Rerun `init` after package upgrades to add newly introduced built-in skills.
67
+ The built-in git commit skill uses `<type>(<scope>): <short description>` with `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, or `chore`.
68
+
69
+ Once those files are present, the normal team workflow is:
70
+
71
+ ```text
72
+ Open Codex or Claude Code.
73
+ Ask for the frontend change.
74
+ Let the injected protocol drive planning, verification, and repair.
75
+ ```
76
+
77
+ ## Human Commands
78
+
79
+ Most team members only need these commands.
80
+
81
+ ```bash
82
+ npx frontend-harness init
83
+ npx frontend-harness init --json
84
+ npx frontend-harness init --dry-run --json
85
+ npx frontend-harness init --check --json
86
+ npx frontend-harness protocol check
87
+ npx frontend-harness protocol check --json
88
+ npx frontend-harness clean --json
89
+ ```
90
+
91
+ Use `init` after installation or package upgrades. Use `protocol check` when you want to verify that `AGENTS.md` and `CLAUDE.md` are current. Use `clean` to remove ignored runtime artifacts while preserving durable project skills, knowledge, and config.
92
+
93
+ ## Agent Protocol Commands
94
+
95
+ These commands are intended for Codex / Claude Code through the injected protocol:
96
+
97
+ ```bash
98
+ frontend-harness context --json
99
+ frontend-harness decision check --json --file <agent-decision.json>
100
+ frontend-harness plan --json "<task>"
101
+ frontend-harness plan --json "<task>" --agent-decision <agent-decision.json>
102
+ frontend-harness state record-change <file>
103
+ frontend-harness state record-change --from-git
104
+ frontend-harness verify --json
105
+ frontend-harness repair packet --json
106
+ frontend-harness state next --json
107
+ frontend-harness state explain --json
108
+ ```
109
+
110
+ The agent should call them automatically while doing work. They persist state under `.frontend-harness/` and provide deterministic evidence for each step.
111
+
112
+ `verify --json` discovers the default `typecheck`, `test`, and `build` scripts when present. Projects can also declare custom verification commands in `.frontend-harness/config.json`:
113
+
114
+ ```json
115
+ {
116
+ "verification": {
117
+ "commands": [
118
+ { "name": "lint", "command": "npm run lint" },
119
+ { "name": "e2e", "command": "npm run test:e2e" }
120
+ ]
121
+ }
122
+ }
123
+ ```
124
+
125
+ `plan --json` also classifies the frontend workflow and emits policy guidance for the agent. The current workflow classes are:
126
+
127
+ - `ui_implementation`
128
+ - `prd_knowledge`
129
+ - `api_integration`
130
+ - `frontend_test`
131
+ - `bug_fix`
132
+ - `requirement_change`
133
+
134
+ Each plan includes required knowledge actions, implementation constraints, and verification focus. This keeps generated UI imports, PRD digestion, Swagger/API work, tests, bug fixes, and requirement changes inside the same controlled policy loop without turning skills into executable runtime commands.
135
+
136
+ ### Agent Plan Hints
137
+
138
+ The plan is deterministic and system-owned. An agent may provide bounded hints before planning, but those hints cannot change workflow classification, execution units, file paths, dependency graph, scheduling, or verification commands.
139
+
140
+ Valid hint input:
141
+
142
+ ```json
143
+ {
144
+ "contractVersion": 1,
145
+ "decision": {
146
+ "intentSuggestion": "implement_page",
147
+ "constraintHints": ["Handle loading, empty, and error states."],
148
+ "componentHints": [
149
+ {
150
+ "name": "OrderSearchForm",
151
+ "responsibility": "query filters and submit behavior"
152
+ }
153
+ ]
154
+ }
155
+ }
156
+ ```
157
+
158
+ Validate the hint file before planning:
159
+
160
+ ```bash
161
+ frontend-harness decision check --json --file agent-decision.json
162
+ frontend-harness plan --json "<task>" --agent-decision agent-decision.json
163
+ ```
164
+
165
+ The final plan still owns components, units, file paths, dependency graph, and verification requirements.
166
+
167
+ ## Advisory Commands
168
+
169
+ These commands expose project-local knowledge and workflow guidance as provenance only. They do not launch agents, execute skills, or turn markdown into commands.
170
+
171
+ ```bash
172
+ frontend-harness skills list --json
173
+ frontend-harness skills check --json
174
+ frontend-harness knowledge promote --json --title "<title>" --body "<body>"
175
+ frontend-harness knowledge check --json
176
+ ```
177
+
178
+ ## Runtime Boundary
179
+
180
+ The boundary is strict:
181
+
182
+ - Codex / Claude Code owns execution.
183
+ - `frontend-harness` owns policy.
184
+ - The project owns durable state and knowledge.
185
+
186
+ Project skills under `.frontend-harness/skills/` are policy guidance and provenance for planning. They are intentionally separate from Codex or Claude runtime skills installed in the developer environment.
187
+
188
+ That means `frontend-harness` should stay small and focused. Its job is to make frontend work repeatable, not to become a second runtime.
189
+
190
+ ## Project State
191
+
192
+ The package writes project-local artifacts under `.frontend-harness/`:
193
+
194
+ ```text
195
+ .frontend-harness/
196
+ context/
197
+ plans/
198
+ execution-units/
199
+ component-graph/
200
+ guidance/
201
+ state.json
202
+ verification/
203
+ logs/
204
+ repair/
205
+ repair-decision/
206
+ state-explain/
207
+ protocol/
208
+ knowledge/
209
+ skills/
210
+ config.json
211
+ ```
212
+
213
+ Runtime artifacts such as `context/`, `plans/`, `state.json`, `verification/`, `logs/`, `repair/`, `state-explain/`, `execution-units/`, and `component-graph/` are generated continuity and evidence. They are ignored by git and can be removed with `frontend-harness clean --json`.
214
+
215
+ Durable project assets such as `knowledge/`, `skills/`, `config.json`, and protocol provenance are intentionally preserved by `clean` and may be committed when they represent project policy.
216
+
217
+ ## New Direction
218
+
219
+ The project is being recentered around the original idea:
220
+
221
+ 1. Keep `AGENTS.md` and `CLAUDE.md` injection as the primary product surface.
222
+ 2. Treat CLI commands as the agent-facing protocol API, not the daily human UI.
223
+ 3. Keep the public human workflow to install, initialize, and check protocol health.
224
+ 4. Preserve deterministic context, plan, verify, repair, and state primitives.
225
+ 5. Delete launcher/runtime features that duplicate Codex or Claude Code.
226
+ 6. Keep removed `agent *` and `run --agent` surfaces out of the product unless the direction is explicitly revisited.
227
+ 7. Ship a small built-in set of project skills for common frontend workflows, while preserving project-local overrides.
228
+ 8. Keep documentation short, current, and product-oriented.
229
+
230
+ The success criterion is not more commands. The success criterion is that a team member can install the package, initialize the protocol, and then use AI-assisted frontend development normally while the agent follows a controlled engineering loop.
231
+
232
+ ## Development
233
+
234
+ Build:
235
+
236
+ ```bash
237
+ npm run build
238
+ ```
239
+
240
+ Run the CLI from this source checkout without linking:
241
+
242
+ ```bash
243
+ npm run harness -- context --json
244
+ npm run harness -- plan --json "<task>"
245
+ npm run harness -- verify --json
246
+ ```
247
+
248
+ The bare `frontend-harness ...` command is the installed-package entry point for consumer projects. In this repository, use `npm run harness -- ...` unless you intentionally install or link the package.
249
+
250
+ Verify:
251
+
252
+ ```bash
253
+ npm run verify
254
+ ```
255
+
256
+ Package dry-run:
257
+
258
+ ```bash
259
+ npm_config_cache=/tmp/frontend-harness-npm-cache npm pack --dry-run
260
+ ```
261
+
262
+ The temporary npm cache avoids local global-cache permission issues on machines where `~/.npm` contains root-owned files.
@@ -0,0 +1,2 @@
1
+ #!/usr/bin/env node
2
+ export {};