@cassiomc1/forgeloop 0.1.6 → 0.1.8
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/AGENT_COMPATIBILITY.md +28 -16
- package/ENG/taste-frontend-eng.md +139 -0
- package/EXECUTION_STATE.md +12 -5
- package/GUIDE_ROUTER.md +24 -1
- package/LOOP_ENGINEERING.md +43 -0
- package/LOOP_SYSTEM_DESIGN.md +50 -49
- package/PROJECT_PROFILE.md +27 -12
- package/QUALITY_SCORECARD.md +7 -0
- package/README.md +141 -75
- package/THIRD_PARTY_NOTICES.md +11 -0
- package/conformance/README.md +7 -1
- package/conformance/blind-premium-website/EXPECTED_ROUTE.json +1 -1
- package/conformance/complete-website/EXPECTED_ROUTE.json +1 -1
- package/conformance/runs/2026-08-13-codex-sixth-live.md +412 -0
- package/package.json +1 -1
- package/src/cli.js +2 -1
- package/src/commands/doctor.js +110 -13
- package/src/commands/init.js +12 -5
- package/src/commands/update.js +215 -2
- package/src/commands/validate-protocol.js +19 -2
- package/src/core/audit.js +16 -1
- package/src/core/events.js +8 -0
- package/src/core/guide-metadata.js +1 -0
- package/src/core/inspect.js +16 -7
- package/src/core/manifest.js +6 -0
- package/src/core/native-adapters.js +74 -0
- package/src/core/next-action.js +42 -1
- package/src/core/preflight.js +220 -46
- package/src/core/profile.js +12 -4
- package/src/core/protocol.js +8 -0
- package/src/core/report.js +4 -1
- package/src/core/resumability.js +61 -0
- package/src/core/route-artifact.js +9 -2
- package/src/core/router.js +2 -1
- package/src/core/target-layout.js +38 -0
- package/src/core/templates.js +14 -2
package/AGENT_COMPATIBILITY.md
CHANGED
|
@@ -174,29 +174,41 @@ provider, remote service, or successful check.
|
|
|
174
174
|
|
|
175
175
|
## Installed files
|
|
176
176
|
|
|
177
|
-
Every initialized project receives
|
|
177
|
+
Every initialized project receives small native adapters at the project root
|
|
178
|
+
and the canonical documents in the package-managed hidden kit. This keeps the
|
|
179
|
+
root readable while preserving the standard instruction entry points:
|
|
178
180
|
|
|
179
181
|
```text
|
|
180
182
|
AGENTS.md
|
|
181
183
|
CLAUDE.md
|
|
182
|
-
AGENT_COMPATIBILITY.md
|
|
183
|
-
LOOP_ENGINEERING.md
|
|
184
|
-
GUIDE_ROUTER.md
|
|
185
|
-
PROJECT_PROFILE.md
|
|
186
|
-
LOOP_SYSTEM_DESIGN.md
|
|
187
|
-
QUALITY_SCORECARD.md
|
|
188
|
-
TERMINOLOGY.md
|
|
189
|
-
EXECUTION_STATE.md
|
|
190
|
-
DELEGATION_PROTOCOL.md
|
|
191
|
-
ORCHESTRATOR_INTEGRATION.md
|
|
192
|
-
THIRD_PARTY_NOTICES.md
|
|
193
|
-
LICENSE
|
|
194
|
-
LICENSE-DOCS.md
|
|
195
184
|
.cursor/rules/project-loop.mdc
|
|
196
185
|
.github/copilot-instructions.md
|
|
197
|
-
|
|
198
|
-
|
|
186
|
+
.forgeloop/manifest.json
|
|
187
|
+
.forgeloop/current-contract.json
|
|
188
|
+
.forgeloop/routing-result.json
|
|
189
|
+
.forgeloop/work-state.json
|
|
190
|
+
.forgeloop/kit/AGENT_COMPATIBILITY.md
|
|
191
|
+
.forgeloop/kit/LOOP_ENGINEERING.md
|
|
192
|
+
.forgeloop/kit/GUIDE_ROUTER.md
|
|
193
|
+
.forgeloop/kit/PROJECT_PROFILE.md
|
|
194
|
+
.forgeloop/kit/LOOP_SYSTEM_DESIGN.md
|
|
195
|
+
.forgeloop/kit/QUALITY_SCORECARD.md
|
|
196
|
+
.forgeloop/kit/TERMINOLOGY.md
|
|
197
|
+
.forgeloop/kit/EXECUTION_STATE.md
|
|
198
|
+
.forgeloop/kit/DELEGATION_PROTOCOL.md
|
|
199
|
+
.forgeloop/kit/ORCHESTRATOR_INTEGRATION.md
|
|
200
|
+
.forgeloop/kit/THIRD_PARTY_NOTICES.md
|
|
201
|
+
.forgeloop/kit/LICENSE
|
|
202
|
+
.forgeloop/kit/LICENSE-DOCS.md
|
|
203
|
+
.forgeloop/kit/ENG/
|
|
204
|
+
.forgeloop/kit/schemas/
|
|
199
205
|
```
|
|
200
206
|
|
|
207
|
+
The package source retains the canonical root files so npm can ship and
|
|
208
|
+
validate them; initialized targets use the hidden destination above. Existing
|
|
209
|
+
legacy root files are not deleted when they are modified or unowned. Run
|
|
210
|
+
`forgeloop update` to migrate unchanged managed files and review any reported
|
|
211
|
+
conflict.
|
|
212
|
+
|
|
201
213
|
See the main [README](https://github.com/cassiomc1/forgeloop#readme) for the complete `npx` installation,
|
|
202
214
|
diagnostic, first-run, and update workflow.
|
|
@@ -0,0 +1,139 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: taste-frontend-eng
|
|
3
|
+
language: en
|
|
4
|
+
description: "Contextual visual-taste review for premium frontend and brand-heavy work."
|
|
5
|
+
version: "2026.09"
|
|
6
|
+
last-reviewed: "2026-08-10"
|
|
7
|
+
guide-id: taste
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
# Taste Skill for ForgeLoop Frontend Work
|
|
11
|
+
|
|
12
|
+
This is a contextual review guide for premium marketing sites, landing pages,
|
|
13
|
+
portfolios, brand surfaces, and high-finish redesigns. It is selected by the
|
|
14
|
+
ForgeLoop router only when the work has that visual context. It is advisory: it
|
|
15
|
+
does not create an approval gate, block an autonomous task, or require a
|
|
16
|
+
specific framework, font, layout, animation library, or visual tool.
|
|
17
|
+
|
|
18
|
+
The upstream inspiration is Taste Skill's design-read and anti-default
|
|
19
|
+
approach. ForgeLoop keeps the useful review vocabulary while applying its own
|
|
20
|
+
protocol boundaries: user evidence, accessibility, performance, security, and
|
|
21
|
+
the active product constraints have priority over aesthetic preference.
|
|
22
|
+
|
|
23
|
+
## Design Read
|
|
24
|
+
|
|
25
|
+
Before editing, describe the existing or proposed system in observable terms:
|
|
26
|
+
|
|
27
|
+
- What is the product promise, audience, and primary action?
|
|
28
|
+
- Which visual idea creates recognition, and which elements are merely
|
|
29
|
+
decoration?
|
|
30
|
+
- What are the current typography roles, color roles, spacing rhythm, grid,
|
|
31
|
+
image treatment, component shapes, and motion cues?
|
|
32
|
+
- Where does the hierarchy break at the first viewport, on a narrow viewport,
|
|
33
|
+
or in a dense interaction state?
|
|
34
|
+
|
|
35
|
+
Separate observed evidence from inference. If the implementation is not yet
|
|
36
|
+
available, record the read as a hypothesis and keep it reversible.
|
|
37
|
+
|
|
38
|
+
## Design Dials
|
|
39
|
+
|
|
40
|
+
Use three lightweight dials to make an intentional decision rather than a
|
|
41
|
+
generic default:
|
|
42
|
+
|
|
43
|
+
- **Design variance:** familiar, distinctive, or experimental relative to the
|
|
44
|
+
product category.
|
|
45
|
+
- **Motion intensity:** static, restrained, or expressive, limited by user
|
|
46
|
+
preference and runtime budget.
|
|
47
|
+
- **Visual density:** quiet, balanced, or information-rich, tuned to the task
|
|
48
|
+
and reading conditions.
|
|
49
|
+
|
|
50
|
+
Record the chosen direction in the design gate or contract assumptions when it
|
|
51
|
+
materially changes implementation. Do not randomize values to manufacture
|
|
52
|
+
novelty; deliberate variation should have a product or communication reason.
|
|
53
|
+
|
|
54
|
+
## Anti-Slop Checks
|
|
55
|
+
|
|
56
|
+
Review the whole page, not only the hero:
|
|
57
|
+
|
|
58
|
+
- The first viewport states what the product is, for whom, and what to do.
|
|
59
|
+
- Repeated sections have a reason and do not reuse one composition by habit.
|
|
60
|
+
- The strongest contrast, scale, and whitespace support the intended hierarchy.
|
|
61
|
+
- Decorative effects do not compete with content, controls, or error states.
|
|
62
|
+
- Images, icons, testimonials, logos, metrics, and claims are real or clearly
|
|
63
|
+
marked as representative; never fabricate proof.
|
|
64
|
+
- Framework, component, and template defaults are changed only when the
|
|
65
|
+
resulting system is more coherent and the change is justified.
|
|
66
|
+
- Empty, loading, error, focus, hover, pressed, disabled, consent, and form
|
|
67
|
+
states belong to the same visual system.
|
|
68
|
+
|
|
69
|
+
## Typography Quality
|
|
70
|
+
|
|
71
|
+
Choose typography by role and reading need. Limit the number of families and
|
|
72
|
+
weights to what the product needs, keep running text at a comfortable measure,
|
|
73
|
+
and establish a clear display/body/metadata hierarchy. Verify the exact font
|
|
74
|
+
source, license, loading cost, fallback, and language coverage before adding an
|
|
75
|
+
external font. A distinctive type choice is optional; legibility and product
|
|
76
|
+
evidence are not.
|
|
77
|
+
|
|
78
|
+
## Layout Composition
|
|
79
|
+
|
|
80
|
+
Build hierarchy from relationships: container, grid, alignment, rhythm,
|
|
81
|
+
contrast, grouping, and breathing room. Vary section composition when that
|
|
82
|
+
clarifies a narrative, but preserve predictable navigation and interaction.
|
|
83
|
+
Use the smallest set of tokens that explains the system. Treat a deliberate
|
|
84
|
+
asymmetry, quiet section, oversized statement, or dense data region as a
|
|
85
|
+
decision to validate, not a rule to apply everywhere.
|
|
86
|
+
|
|
87
|
+
## Motion Restraint
|
|
88
|
+
|
|
89
|
+
Motion should explain change, guide attention, or provide feedback. Prefer
|
|
90
|
+
short, interruptible, seek-safe transitions and respect
|
|
91
|
+
`prefers-reduced-motion`, reduced-transparency preferences, focus, and input
|
|
92
|
+
latency. A static implementation is valid when it communicates better or
|
|
93
|
+
meets the performance budget. GSAP, scroll effects, canvas, WebGL, and shader
|
|
94
|
+
effects are optional implementation choices, never universal requirements.
|
|
95
|
+
|
|
96
|
+
## Responsive Composition
|
|
97
|
+
|
|
98
|
+
Design narrow and wide compositions as related states, not as a desktop page
|
|
99
|
+
scaled down. Re-check hierarchy, line length, touch targets, safe areas,
|
|
100
|
+
navigation, image crops, overflow, and the primary action at the smallest
|
|
101
|
+
supported viewport. Test intermediate widths when layout changes are likely;
|
|
102
|
+
do not invent a breakpoint merely to match a visual convention.
|
|
103
|
+
|
|
104
|
+
## Design-System Selection
|
|
105
|
+
|
|
106
|
+
Use the existing product system when one is present. If the target has no
|
|
107
|
+
system, choose a small coherent set of semantic tokens, components, states,
|
|
108
|
+
and usage rules that the team can maintain. A vendor guide, gallery, template,
|
|
109
|
+
or AI output can inform a direction, but it is not evidence of product fit,
|
|
110
|
+
license, accessibility, or performance. Keep any external reference in the
|
|
111
|
+
task's source and attribution records; do not add a network dependency to
|
|
112
|
+
ForgeLoop runtime.
|
|
113
|
+
|
|
114
|
+
## Visual Pre-Flight
|
|
115
|
+
|
|
116
|
+
Before calling a visual task ready, check the smallest useful evidence set:
|
|
117
|
+
|
|
118
|
+
- hierarchy and primary action at wide and narrow viewports;
|
|
119
|
+
- keyboard focus, contrast, zoom, reduced motion, and semantic controls;
|
|
120
|
+
- loading/error/empty/form states that are in scope;
|
|
121
|
+
- image and font loading, console/runtime errors, and performance budget;
|
|
122
|
+
- consistency of tokens, spacing, type roles, component states, and content
|
|
123
|
+
claims.
|
|
124
|
+
|
|
125
|
+
If visual evidence is unavailable, record `NOT_VERIFIED` or a bounded
|
|
126
|
+
limitation. Never turn an imagined screenshot or an unrun browser check into
|
|
127
|
+
an observed result.
|
|
128
|
+
|
|
129
|
+
## Redesign Audit
|
|
130
|
+
|
|
131
|
+
For an existing interface, scan first and classify each issue as hierarchy,
|
|
132
|
+
typography, color/contrast, composition, content, interaction, responsive
|
|
133
|
+
behavior, accessibility, performance, or evidence. Fix the highest-leverage
|
|
134
|
+
issues in small coherent batches. Re-read the whole system after each batch so
|
|
135
|
+
local polish does not create a new inconsistency elsewhere.
|
|
136
|
+
|
|
137
|
+
The final decision remains protocol-owned: this guide can recommend a visual
|
|
138
|
+
change, but the contract, routing, gates, evidence, completion rules, and
|
|
139
|
+
user-authorized constraints decide whether the task may proceed or close.
|
package/EXECUTION_STATE.md
CHANGED
|
@@ -7,8 +7,9 @@ Compatible agents may persist a handoff checkpoint at:
|
|
|
7
7
|
```
|
|
8
8
|
|
|
9
9
|
The file is local, ignored by Git, schema-versioned, and never a replacement
|
|
10
|
-
for the manifest or
|
|
11
|
-
|
|
10
|
+
for the manifest or the target project profile (installed as
|
|
11
|
+
`.forgeloop/kit/PROJECT_PROFILE.md`). It contains no secrets and is untrusted
|
|
12
|
+
on read.
|
|
12
13
|
|
|
13
14
|
## Shape
|
|
14
15
|
|
|
@@ -69,17 +70,23 @@ An optional age threshold may recommend cheap verification with
|
|
|
69
70
|
`CHECKPOINT_OLD` without changing a fresh result.
|
|
70
71
|
|
|
71
72
|
`inspect`, `status`, and `validate-protocol` use the same derived freshness
|
|
72
|
-
classifier. Protocol validation can be run against the
|
|
73
|
+
classifier. Protocol validation can be run against the current route, state,
|
|
74
|
+
receipt, and contract artifacts:
|
|
73
75
|
|
|
74
76
|
```bash
|
|
75
77
|
forgeloop validate-protocol \
|
|
76
|
-
--route-file
|
|
78
|
+
--route-file .forgeloop/routing-result.json \
|
|
77
79
|
--state-file .forgeloop/work-state.json \
|
|
78
|
-
--receipt-file
|
|
80
|
+
--receipt-file .forgeloop/execution-receipt.json \
|
|
79
81
|
--contract-file .forgeloop/current-contract.json \
|
|
80
82
|
--json
|
|
81
83
|
```
|
|
82
84
|
|
|
85
|
+
When delegation is in scope, repeat `--task-brief <path>` and
|
|
86
|
+
`--delegated-result <path>` for the matching handoff artifacts. If those inputs
|
|
87
|
+
are omitted, `validate-protocol` reports `INCOMPLETE` because delegation
|
|
88
|
+
conformance was not supplied; this is distinct from a local `complete` result.
|
|
89
|
+
|
|
83
90
|
`validate-protocol` reports `STALE` when the current repository fingerprint,
|
|
84
91
|
contract, or required-artifact fingerprints require revalidation. Its JSON
|
|
85
92
|
result exposes the comparison values, reasons, and warnings; the human output
|
package/GUIDE_ROUTER.md
CHANGED
|
@@ -47,6 +47,7 @@ project commands.
|
|
|
47
47
|
| `test` | [Testing](./ENG/test-code-eng.md) | Risk-driven verification strategy and tooling |
|
|
48
48
|
| `security` | [Security](./ENG/sec-code-eng.md) | Web, API, mobile, desktop, data, and supply-chain security |
|
|
49
49
|
| `design` | [Design](./ENG/design-code-eng.md) | Visual direction, UX, motion, and perceived performance |
|
|
50
|
+
| `taste` | [Taste frontend](./ENG/taste-frontend-eng.md) | Contextual design-read, anti-slop, and visual pre-flight for premium frontend work |
|
|
50
51
|
| `performance` | [Performance](./ENG/perf-code-eng.md) | Measurement, diagnosis, budgets, and optimization |
|
|
51
52
|
| `accessibility` | [Accessibility](./ENG/accessibility-eng.md) | WCAG, keyboard access, focus, semantics, and assistive technology |
|
|
52
53
|
| `games` | [Web games](./ENG/games-code-design-web-eng.md) | Architecture and operation of 2D, 3D, and procedural web games |
|
|
@@ -153,6 +154,28 @@ rg -n '^## [0-9]+\.|brief|content|direction|design system|implementation|quality
|
|
|
153
154
|
|
|
154
155
|
**Expected evidence:** approved strategy, content, direction, production, quality, launch, and operation gates.
|
|
155
156
|
|
|
157
|
+
### `taste` — contextual frontend taste review
|
|
158
|
+
|
|
159
|
+
**Activate when:** the router selects a premium marketing site, landing page,
|
|
160
|
+
portfolio, brand-heavy surface, or high-finish redesign with a meaningful
|
|
161
|
+
visual composition.
|
|
162
|
+
|
|
163
|
+
**Do not activate when:** the task is backend, infrastructure, data, CLI,
|
|
164
|
+
documentation, or a nonvisual bug. A UI word in a technical description is not
|
|
165
|
+
enough context.
|
|
166
|
+
|
|
167
|
+
Use this guide as an advisory review. It does not add a user-approval gate,
|
|
168
|
+
require GSAP or a static-site approach, prescribe fonts/layouts, or override
|
|
169
|
+
accessibility, performance, security, or product evidence.
|
|
170
|
+
|
|
171
|
+
```bash
|
|
172
|
+
rg -n '^## (Design Read|Design Dials|Anti-Slop Checks|Typography Quality|Layout Composition|Motion Restraint|Responsive Composition|Design-System Selection|Visual Pre-Flight|Redesign Audit)' ENG/taste-frontend-eng.md
|
|
173
|
+
```
|
|
174
|
+
|
|
175
|
+
**Expected evidence:** a contextual design read, intentional dials, bounded
|
|
176
|
+
anti-slop review, and only the visual/accessibility/performance checks that are
|
|
177
|
+
in scope. Mark unavailable visual evidence `NOT_VERIFIED`.
|
|
178
|
+
|
|
156
179
|
### `games` — web game architecture and operation
|
|
157
180
|
|
|
158
181
|
**Activate when:** designing, implementing, testing, or operating a 2D or 3D web game, procedural generation, game loops, assets, input, multiplayer, or game distribution.
|
|
@@ -249,7 +272,7 @@ Route comments are stable contracts for the validator. They contain IDs, not loa
|
|
|
249
272
|
|
|
250
273
|
### Premium landing page
|
|
251
274
|
|
|
252
|
-
<!-- route:landing-page-premium=premium,design,accessibility,clean,test,security,performance -->
|
|
275
|
+
<!-- route:landing-page-premium=premium,design,taste,accessibility,clean,test,security,performance -->
|
|
253
276
|
|
|
254
277
|
Verify the brief, content, responsive UI, states, WCAG coverage, build, tests, Web Vitals, forms, analytics, launch, and operation.
|
|
255
278
|
|
package/LOOP_ENGINEERING.md
CHANGED
|
@@ -286,6 +286,45 @@ forgeloop preflight
|
|
|
286
286
|
|
|
287
287
|
`preflight` validates local ForgeLoop artifacts only. It does not invoke the model, run project commands, or treat a prose declaration as evidence. A `READY` result is required before `EXECUTING` in standard and strict workflows. A non-empty `current-contract.unresolvedDecisions[]` causes `forgeloop preflight` to return `BLOCKED` with `E_CONTRACT_UNRESOLVED_DECISION`; a valid `current-contract.assumptions[]` list does not block preparation.
|
|
288
288
|
|
|
289
|
+
### Resumable activation and artifact reconciliation
|
|
290
|
+
|
|
291
|
+
`PREFLIGHT_READY` is a durable checkpoint, not only a status value. A persisted
|
|
292
|
+
READY result is valid only when the same target also contains:
|
|
293
|
+
|
|
294
|
+
```text
|
|
295
|
+
current-contract.json
|
|
296
|
+
routing-result.json
|
|
297
|
+
gates required by the route
|
|
298
|
+
work-state.json
|
|
299
|
+
events.ndjson with the activation chronology
|
|
300
|
+
preflight.json with status READY
|
|
301
|
+
```
|
|
302
|
+
|
|
303
|
+
The activation event matrix is explicit:
|
|
304
|
+
|
|
305
|
+
| Stage | Event | Requirement |
|
|
306
|
+
| --- | --- | --- |
|
|
307
|
+
| Task received | `TASK_RECEIVED` | New activation; one first event when the ledger is empty |
|
|
308
|
+
| Contract validated | `CONTRACT_VALIDATED` | Before READY |
|
|
309
|
+
| Route validated | `ROUTE_VALIDATED` | Before READY |
|
|
310
|
+
| Gate satisfied | `GATE_SATISFIED` | One event for each satisfied required gate |
|
|
311
|
+
| Preflight blocked | `PREFLIGHT_BLOCKED` | Persisted when activation is blocked |
|
|
312
|
+
| Preflight ready | `PREFLIGHT_READY` | Exactly the matching READY fingerprints and gate sets |
|
|
313
|
+
|
|
314
|
+
The ledger is append-only and hash-linked. A `BLOCKED → READY` recovery keeps
|
|
315
|
+
the original `PREFLIGHT_BLOCKED` event, appends only newly satisfied gate and
|
|
316
|
+
readiness events, and never deletes or rewrites history. `forgeloop next` is a
|
|
317
|
+
read-only query: if READY remains but `work-state.json` is missing, it returns
|
|
318
|
+
`RESOLVE_BLOCKER` with `E_STATE_MISSING_AFTER_PREFLIGHT_READY` instead of
|
|
319
|
+
silently returning to discovery.
|
|
320
|
+
|
|
321
|
+
`PROJECT_PROFILE.md` distinguishes planned template locations from files
|
|
322
|
+
observed in the target. New targets receive canonical documents under
|
|
323
|
+
`.forgeloop/kit/`; root `AGENTS.md`, `CLAUDE.md`, Cursor, and Copilot files are
|
|
324
|
+
minimal native shims. `forgeloop update` migrates unchanged managed legacy root
|
|
325
|
+
files, preserves modified or unowned files, and reports conflicts without
|
|
326
|
+
following symlinks or escaping the selected target.
|
|
327
|
+
|
|
289
328
|
## Completion validation and chronology
|
|
290
329
|
|
|
291
330
|
`COMPLETE` is a validator result, not a string an agent may assign by itself.
|
|
@@ -446,6 +485,7 @@ AUTHORITY_FAILURE
|
|
|
446
485
|
ENVIRONMENT_FAILURE
|
|
447
486
|
EXTERNAL_SERVICE_FAILURE
|
|
448
487
|
STALE_STATE_FAILURE
|
|
488
|
+
OPERATOR_INTERRUPTION
|
|
449
489
|
```
|
|
450
490
|
|
|
451
491
|
For every failure, record the class, hypothesis, evidence, and next safe
|
|
@@ -479,6 +519,9 @@ The loop invariants are:
|
|
|
479
519
|
21. protocol chronology must not permit execution before mandatory preflight events.
|
|
480
520
|
22. publication status and production readiness must remain independent from local task completion.
|
|
481
521
|
23. a task with implemented deliverables must not terminate in EXECUTING.
|
|
522
|
+
24. a persisted PREFLIGHT_READY result must reconcile with a resumable state and
|
|
523
|
+
its matching append-only activation chronology.
|
|
524
|
+
25. planned profile fields must not be reported as present target evidence.
|
|
482
525
|
|
|
483
526
|
The serializable phase and transition contract is maintained in
|
|
484
527
|
[`ORCHESTRATOR_INTEGRATION.md`](./ORCHESTRATOR_INTEGRATION.md). It is a host
|
package/LOOP_SYSTEM_DESIGN.md
CHANGED
|
@@ -22,6 +22,8 @@ The system should use every guide that materially helps the task without loading
|
|
|
22
22
|
- The loop continues while safe progress is possible. Repetition without new evidence triggers hypothesis reassessment or a blocked result, not infinite retries.
|
|
23
23
|
- Third-party provenance and reuse boundaries remain part of every portable copy.
|
|
24
24
|
- Qwen-MM-Plugins is an optional, task-scoped capability extension: the agent checks native support first, installs the smallest missing capability when needed, and verifies it before use; it is not a package or runtime dependency.
|
|
25
|
+
- Canonical documents are installed under `.forgeloop/kit/`; root native adapters remain small shims and mutable protocol artifacts remain directly under `.forgeloop/`.
|
|
26
|
+
- `PREFLIGHT_READY` is a resumable protocol checkpoint reconciled with work state, activation events, fingerprints, and the append-only hash chain.
|
|
25
27
|
|
|
26
28
|
## Alternatives considered
|
|
27
29
|
|
|
@@ -46,33 +48,35 @@ the compatible harness.
|
|
|
46
48
|
```text
|
|
47
49
|
FORGELOOP
|
|
48
50
|
│
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
│
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
|
|
51
|
+
┌──────────────┼──────────────┐
|
|
52
|
+
│ │ │
|
|
53
|
+
CONTRACT ROUTE EVIDENCE
|
|
54
|
+
│ │ │
|
|
55
|
+
└──────┬───────┴──────┬───────┘
|
|
56
|
+
│ │
|
|
57
|
+
required current
|
|
58
|
+
gates fingerprints
|
|
59
|
+
│ │
|
|
60
|
+
▼ │
|
|
61
|
+
PREFLIGHT_READY │
|
|
62
|
+
│ │
|
|
63
|
+
┌──────┴──────┐ │
|
|
64
|
+
│ │ │
|
|
65
|
+
work-state event ledger │
|
|
66
|
+
│ │ │
|
|
67
|
+
└──────┬──────┘ │
|
|
68
|
+
│ │
|
|
69
|
+
plan → execute → verify → review
|
|
70
|
+
│ │
|
|
71
|
+
└──────┬───────┘
|
|
72
|
+
▼
|
|
73
|
+
AUDIT / COMPLETE / VALIDATE-PROTOCOL
|
|
74
|
+
│
|
|
75
|
+
▼
|
|
76
|
+
VALID / INCOMPLETE / STALE / INCONSISTENT / INVALID
|
|
77
|
+
│
|
|
78
|
+
▼
|
|
79
|
+
compatible harness
|
|
76
80
|
```
|
|
77
81
|
|
|
78
82
|
```text
|
|
@@ -81,12 +85,14 @@ User request
|
|
|
81
85
|
v
|
|
82
86
|
Nearest agent adapter
|
|
83
87
|
|
|
|
84
|
-
+-->
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
88
|
+
+--> root native shim
|
|
89
|
+
|
|
|
90
|
+
+--> .forgeloop/kit/LOOP_ENGINEERING.md
|
|
91
|
+
| |
|
|
92
|
+
| +--> .forgeloop/kit/PROJECT_PROFILE.md
|
|
93
|
+
| +--> .forgeloop/kit/GUIDE_ROUTER.md
|
|
94
|
+
| |
|
|
95
|
+
| +--> .forgeloop/kit/ENG/*.md
|
|
90
96
|
|
|
|
91
97
|
+--> repository-specific instructions
|
|
92
98
|
|
|
|
@@ -188,7 +194,7 @@ Durable context for a destination project. The template captures:
|
|
|
188
194
|
- constraints, decisions, and unverified items;
|
|
189
195
|
- a source for every durable fact.
|
|
190
196
|
|
|
191
|
-
The profile changes only when discovery reveals a real project change; it is not a task diary. In this source repository, `profile-mode: template` keeps it as a reusable template. After
|
|
197
|
+
The profile changes only when discovery reveals a real project change; it is not a task diary. In this source repository, `profile-mode: template` keeps it as a reusable template. After `forgeloop init` installs it under `.forgeloop/kit/` in a target, the first cycle may change the mode to `project` and fill only confirmed facts.
|
|
192
198
|
|
|
193
199
|
### `DELEGATION_PROTOCOL.md`
|
|
194
200
|
|
|
@@ -212,7 +218,7 @@ mitigations, residual limitations, and executable evidence.
|
|
|
212
218
|
|
|
213
219
|
### `ENG/*.md`
|
|
214
220
|
|
|
215
|
-
|
|
221
|
+
Nine canonical guides cover:
|
|
216
222
|
|
|
217
223
|
- clean code;
|
|
218
224
|
- testing;
|
|
@@ -221,7 +227,8 @@ Eight canonical guides cover:
|
|
|
221
227
|
- design;
|
|
222
228
|
- accessibility;
|
|
223
229
|
- premium website production;
|
|
224
|
-
- web games
|
|
230
|
+
- web games;
|
|
231
|
+
- contextual frontend taste.
|
|
225
232
|
|
|
226
233
|
Each guide has exact English frontmatter and a stable guide ID.
|
|
227
234
|
|
|
@@ -328,7 +335,7 @@ The documentation workflow verifies:
|
|
|
328
335
|
|
|
329
336
|
- every file referenced by an adapter exists;
|
|
330
337
|
- repository-relative links resolve;
|
|
331
|
-
- exactly
|
|
338
|
+
- exactly nine canonical English guides exist;
|
|
332
339
|
- guide IDs, filenames, frontmatter keys, and `language: en` match the catalog;
|
|
333
340
|
- no legacy language tree or bilingual metadata remains;
|
|
334
341
|
- all route contracts contain valid guide IDs;
|
|
@@ -352,18 +359,12 @@ The validator also exercises six routing scenarios:
|
|
|
352
359
|
The npm CLI installs the kit into the current directory or an existing
|
|
353
360
|
directory selected with `--path` when the package is available in the npm
|
|
354
361
|
registry. If it is not available yet, the same commands can run as
|
|
355
|
-
`node src/cli.js ...` from a repository checkout.
|
|
356
|
-
|
|
357
|
-
|
|
358
|
-
|
|
359
|
-
-
|
|
360
|
-
|
|
361
|
-
- `LOOP_ENGINEERING.md`;
|
|
362
|
-
- `GUIDE_ROUTER.md`;
|
|
363
|
-
- `PROJECT_PROFILE.md`;
|
|
364
|
-
- `THIRD_PARTY_NOTICES.md`;
|
|
365
|
-
- `LICENSE` and `LICENSE-DOCS.md`;
|
|
366
|
-
- the `ENG/` guide directory.
|
|
362
|
+
`node src/cli.js ...` from a repository checkout. The CLI maps canonical
|
|
363
|
+
documents into `.forgeloop/kit/`, keeps only native instruction shims at the
|
|
364
|
+
target root, and leaves mutable contract, route, gate, state, event, preflight,
|
|
365
|
+
and receipt artifacts under `.forgeloop/`. Manual copying must preserve that
|
|
366
|
+
target layout; copying package-source root files directly is not equivalent to
|
|
367
|
+
`forgeloop init`.
|
|
367
368
|
|
|
368
369
|
The README explains the file set, activation behavior, current/relative/absolute
|
|
369
370
|
target installation, first-run profile flow, local validation commands, and safe
|
package/PROJECT_PROFILE.md
CHANGED
|
@@ -10,6 +10,19 @@ last-confirmed: unknown
|
|
|
10
10
|
> Durable context for [Loop Engineering](./LOOP_ENGINEERING.md). Fill it only
|
|
11
11
|
> with evidence from the target project.
|
|
12
12
|
|
|
13
|
+
This source profile is a template. Its planned fields describe what a target
|
|
14
|
+
may confirm after bootstrap; they do not assert that the corresponding product
|
|
15
|
+
files, services, commands, or directories are present in the source kit.
|
|
16
|
+
|
|
17
|
+
Use these terms precisely:
|
|
18
|
+
|
|
19
|
+
- **Planned**: an expected discovery field or protocol location, not observed
|
|
20
|
+
product evidence.
|
|
21
|
+
- **Present**: observed in the target with a file, command, manifest, or other
|
|
22
|
+
authoritative source.
|
|
23
|
+
- **Absent**: checked and not found; record the check and scope.
|
|
24
|
+
- **Unverified**: not checked yet; do not infer presence from this template.
|
|
25
|
+
|
|
13
26
|
## Maintenance rules
|
|
14
27
|
|
|
15
28
|
- Update a fact only after inspecting authoritative files, commands, or sources.
|
|
@@ -21,18 +34,18 @@ last-confirmed: unknown
|
|
|
21
34
|
- Keep `language: en`; this kit has no alternate language variant.
|
|
22
35
|
- Do not use this file as a task diary.
|
|
23
36
|
|
|
24
|
-
## Product and objective
|
|
37
|
+
## Product and objective (planned vs observed)
|
|
25
38
|
|
|
26
|
-
| Field |
|
|
39
|
+
| Field | Planned baseline or observed state | Source |
|
|
27
40
|
| --- | --- | --- |
|
|
28
41
|
| Product | Not identified — confirm from the stated source | Source not identified |
|
|
29
42
|
| Users | Not identified — confirm from the stated source | Source not identified |
|
|
30
43
|
| Primary outcome | Not identified — confirm from the stated source | Source not identified |
|
|
31
44
|
| Durable exclusions | Not identified — confirm from the stated source | Source not identified |
|
|
32
45
|
|
|
33
|
-
## Confirmed stack
|
|
46
|
+
## Confirmed stack (planned vs observed)
|
|
34
47
|
|
|
35
|
-
| Layer |
|
|
48
|
+
| Layer | Planned baseline or observed technology and version | Source |
|
|
36
49
|
| --- | --- | --- |
|
|
37
50
|
| Frontend | Not identified — confirm from the stated source | Source not identified |
|
|
38
51
|
| Backend | Not identified — confirm from the stated source | Source not identified |
|
|
@@ -44,9 +57,9 @@ last-confirmed: unknown
|
|
|
44
57
|
Record a missing manifest or configuration as verified absence. Do not infer a
|
|
45
58
|
stack from technology names found only in documentation or examples.
|
|
46
59
|
|
|
47
|
-
## Official commands
|
|
60
|
+
## Official commands (planned vs observed)
|
|
48
61
|
|
|
49
|
-
| Purpose |
|
|
62
|
+
| Purpose | Planned baseline or observed command | Source |
|
|
50
63
|
| --- | --- | --- |
|
|
51
64
|
| Installation | Not identified — confirm from the stated source | Source not identified |
|
|
52
65
|
| Development | Not identified — confirm from the stated source | Source not identified |
|
|
@@ -60,9 +73,9 @@ stack from technology names found only in documentation or examples.
|
|
|
60
73
|
Never invent a command when the project already declares official scripts or
|
|
61
74
|
automation.
|
|
62
75
|
|
|
63
|
-
## Architecture and directories
|
|
76
|
+
## Architecture and directories (planned vs observed)
|
|
64
77
|
|
|
65
|
-
| Area |
|
|
78
|
+
| Area | Planned location or observed responsibility | Source |
|
|
66
79
|
| --- | --- | --- |
|
|
67
80
|
| Primary entry point | Not identified — confirm from the stated source | Source not identified |
|
|
68
81
|
| Domain | Not identified — confirm from the stated source | Source not identified |
|
|
@@ -72,7 +85,7 @@ automation.
|
|
|
72
85
|
| Documentation | Not identified — confirm from the stated source | Source not identified |
|
|
73
86
|
| CI/CD | Not identified — confirm from the stated source | Source not identified |
|
|
74
87
|
|
|
75
|
-
## Supported platforms
|
|
88
|
+
## Supported platforms (planned vs observed)
|
|
76
89
|
|
|
77
90
|
| Surface | Confirmed targets | Evidence |
|
|
78
91
|
| --- | --- | --- |
|
|
@@ -82,7 +95,7 @@ automation.
|
|
|
82
95
|
| Browsers and devices | Not identified — confirm from the stated source | Source not identified |
|
|
83
96
|
| Accessibility requirements | Not identified — confirm from the stated source | Source not identified |
|
|
84
97
|
|
|
85
|
-
## Services and risk surfaces
|
|
98
|
+
## Services and risk surfaces (planned vs observed)
|
|
86
99
|
|
|
87
100
|
| Item | Use and risk | Safe source |
|
|
88
101
|
| --- | --- | --- |
|
|
@@ -97,7 +110,7 @@ automation.
|
|
|
97
110
|
Record only the mechanism and safe configuration location. Never copy credential
|
|
98
111
|
values.
|
|
99
112
|
|
|
100
|
-
## Constraints and decisions
|
|
113
|
+
## Constraints and decisions (planned vs observed)
|
|
101
114
|
|
|
102
115
|
| Decision or constraint | State | Source |
|
|
103
116
|
| --- | --- | --- |
|
|
@@ -121,4 +134,6 @@ appropriate section.
|
|
|
121
134
|
| Not identified | Not identified — confirm from the stated source | Source not identified | Not identified |
|
|
122
135
|
|
|
123
136
|
Keep evidence concise. Long outputs, temporary logs, and per-task history do not
|
|
124
|
-
belong in this file.
|
|
137
|
+
belong in this file. A planned row becomes present only after the target check;
|
|
138
|
+
an absent row must include the scope of the check rather than being silently
|
|
139
|
+
treated as a missing product feature.
|
package/QUALITY_SCORECARD.md
CHANGED
|
@@ -23,6 +23,10 @@ policy are all present.
|
|
|
23
23
|
| Autonomous-mode precedence — structural | Explicit `autonomousMode=true` boundary, explicit interactive opt-in, preservation of `NON_BLOCKING`, and no silent workflow-induced mode switch. |
|
|
24
24
|
| Pre-contract autonomy — cross-agent live robustness | Independent live-agent behavior across fresh package installs, exact blind prompts, one-process/no-subagent topology, and separate evidence for non-blocking continuation versus blocking clarification. Structural coverage does not imply live cross-agent robustness. |
|
|
25
25
|
| Resume/checkpoint | Atomic local state, contract/HEAD/artifact freshness, age warning, schema/secret validation, status, safe validation, and bounded clearing without persisting derived freshness fields. |
|
|
26
|
+
| Protocol activation resumability | `PREFLIGHT_READY` durably creates or reconciles `work-state.json`, preserves blocked history, and exposes a dedicated repair code when the checkpoint is missing. |
|
|
27
|
+
| Artifact ↔ lifecycle reconciliation | Contract, route, gates, state, preflight, activation events, fingerprints, and append-only hash chronology agree at READY; audit and validate-protocol detect divergence. |
|
|
28
|
+
| Planned vs present profile truth | `PROJECT_PROFILE.md` distinguishes planned template fields from observed target facts, with hidden-kit bootstrap and legacy migration checks. |
|
|
29
|
+
| Contextual frontend taste | Taste is routed only to applicable premium frontend work, remains advisory, respects accessibility/performance/evidence, and has attribution without runtime dependency. |
|
|
26
30
|
| Multi-agent coordination | Self-contained briefs, write/write and write/read ownership checks, dependency-set validation, reviewer independence, normalized results, and inline fallback. |
|
|
27
31
|
| Security boundaries | Realpath containment, bounded untrusted JSON, threat model, nested secret scanning, publication evidence, and explicit authority rules. |
|
|
28
32
|
| Maintenance quality | Small modules, built-in runtime, deterministic JSON contracts, malformed/version fixtures, package gates, and backward-compatible protocol versions. |
|
|
@@ -72,6 +76,9 @@ are both present:
|
|
|
72
76
|
| Security boundary | realpath containment, bounded JSON, `THREAT_MODEL.md`, secret-free artifacts, authority and no-runtime rules | `tests/security-limits.test.js`, Markdown/loop validators, and `scripts/scan_secrets.py` |
|
|
73
77
|
| Cross-artifact conformance | `src/core/conformance.js`, `classifyLoadedWorkState`, and `forgeloop validate-protocol --contract-file` | `tests/conformance.test.js`, `tests/validate-protocol-cli.test.js`, and protocol fixtures covering precedence and stale evidence |
|
|
74
78
|
| Protocol preparation and completion | `src/core/preflight.js`, `src/core/completion.js`, `src/core/events.js`, policy packs, and portable bundles | `tests/preflight.test.js`, `tests/completion.test.js`, `tests/lifecycle.test.js`, `tests/policy.test.js`, and `tests/bundle.test.js` |
|
|
79
|
+
| Protocol activation resumability | `src/core/resumability.js`, READY consistency checks, event matrix, and `next` repair semantics | `tests/resumable-protocol.test.js` |
|
|
80
|
+
| Hidden kit layout | `src/core/target-layout.js`, safe init/update migration, manifest layout version, native shims, and profile resolver | `tests/hidden-layout.test.js`, package and compatibility tests |
|
|
81
|
+
| Contextual frontend taste | `ENG/taste-frontend-eng.md`, router metadata, attribution, and design/accessibility precedence | `tests/taste-guide.test.js`, route fixtures |
|
|
75
82
|
| Pre-contract autonomy — structural | `LOOP_ENGINEERING.md`, `src/core/decision-classification.js`, `src/core/workflow-compatibility.js`, `CLAUDE.md`, `AGENTS.md`, `.github/copilot-instructions.md`, `.cursor/rules/project-loop.mdc` | `tests/decision-classification.test.js`, `tests/workflow-compatibility.test.js`, `tests/autonomy-policy.test.js`, `tests/preflight.test.js` |
|
|
76
83
|
| External workflow compatibility — structural | `LOOP_ENGINEERING.md`, `AGENT_COMPATIBILITY.md`, `src/core/workflow-compatibility.js`, and sixth-run harness metadata rule | `tests/workflow-compatibility.test.js`, `conformance/README.md` |
|
|
77
84
|
| Instruction-conflict handling — structural | Canonical source-attribution and `WORKFLOW_CONFLICT` policy in `LOOP_ENGINEERING.md` plus adapter references | `tests/autonomy-policy.test.js`, `tests/workflow-compatibility.test.js` |
|