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.
- package/AGENTS.md +48 -0
- package/CLAUDE.md +48 -0
- package/README.md +262 -0
- package/dist/cli/index.d.ts +2 -0
- package/dist/cli/index.js +380 -0
- package/dist/cli/index.js.map +1 -0
- package/dist/runtime/builtin-skills.d.ts +6 -0
- package/dist/runtime/builtin-skills.js +269 -0
- package/dist/runtime/builtin-skills.js.map +1 -0
- package/dist/runtime/clean.d.ts +11 -0
- package/dist/runtime/clean.js +85 -0
- package/dist/runtime/clean.js.map +1 -0
- package/dist/runtime/command-taxonomy.d.ts +12 -0
- package/dist/runtime/command-taxonomy.js +72 -0
- package/dist/runtime/command-taxonomy.js.map +1 -0
- package/dist/runtime/context.d.ts +71 -0
- package/dist/runtime/context.js +153 -0
- package/dist/runtime/context.js.map +1 -0
- package/dist/runtime/graph.d.ts +12 -0
- package/dist/runtime/graph.js +211 -0
- package/dist/runtime/graph.js.map +1 -0
- package/dist/runtime/knowledge.d.ts +48 -0
- package/dist/runtime/knowledge.js +383 -0
- package/dist/runtime/knowledge.js.map +1 -0
- package/dist/runtime/plan.d.ts +18 -0
- package/dist/runtime/plan.js +571 -0
- package/dist/runtime/plan.js.map +1 -0
- package/dist/runtime/policy-provenance.d.ts +17 -0
- package/dist/runtime/policy-provenance.js +195 -0
- package/dist/runtime/policy-provenance.js.map +1 -0
- package/dist/runtime/project-discovery.d.ts +17 -0
- package/dist/runtime/project-discovery.js +166 -0
- package/dist/runtime/project-discovery.js.map +1 -0
- package/dist/runtime/project-paths.d.ts +6 -0
- package/dist/runtime/project-paths.js +47 -0
- package/dist/runtime/project-paths.js.map +1 -0
- package/dist/runtime/protocol-init.d.ts +50 -0
- package/dist/runtime/protocol-init.js +256 -0
- package/dist/runtime/protocol-init.js.map +1 -0
- package/dist/runtime/repair-decision.d.ts +3 -0
- package/dist/runtime/repair-decision.js +195 -0
- package/dist/runtime/repair-decision.js.map +1 -0
- package/dist/runtime/repair-packet.d.ts +7 -0
- package/dist/runtime/repair-packet.js +159 -0
- package/dist/runtime/repair-packet.js.map +1 -0
- package/dist/runtime/skills.d.ts +19 -0
- package/dist/runtime/skills.js +230 -0
- package/dist/runtime/skills.js.map +1 -0
- package/dist/runtime/state-explain.d.ts +2 -0
- package/dist/runtime/state-explain.js +106 -0
- package/dist/runtime/state-explain.js.map +1 -0
- package/dist/runtime/state.d.ts +10 -0
- package/dist/runtime/state.js +237 -0
- package/dist/runtime/state.js.map +1 -0
- package/dist/runtime/units.d.ts +10 -0
- package/dist/runtime/units.js +181 -0
- package/dist/runtime/units.js.map +1 -0
- package/dist/runtime/verification-commands.d.ts +11 -0
- package/dist/runtime/verification-commands.js +89 -0
- package/dist/runtime/verification-commands.js.map +1 -0
- package/dist/runtime/verify.d.ts +7 -0
- package/dist/runtime/verify.js +192 -0
- package/dist/runtime/verify.js.map +1 -0
- package/dist/schemas/types.d.ts +244 -0
- package/dist/schemas/types.js +2 -0
- package/dist/schemas/types.js.map +1 -0
- package/dist/schemas/validation.d.ts +2 -0
- package/dist/schemas/validation.js +21 -0
- package/dist/schemas/validation.js.map +1 -0
- package/dist/storage/json.d.ts +5 -0
- package/dist/storage/json.js +24 -0
- package/dist/storage/json.js.map +1 -0
- package/dist/storage/paths.d.ts +3 -0
- package/dist/storage/paths.js +9 -0
- package/dist/storage/paths.js.map +1 -0
- package/docs/DIRECTION.md +67 -0
- 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.
|