@cassiomc1/forgeloop 0.1.0 → 0.1.2
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/.cursor/rules/project-loop.mdc +7 -1
- package/.github/copilot-instructions.md +6 -0
- package/AGENTS.md +9 -1
- package/AGENT_COMPATIBILITY.md +14 -1
- package/CLAUDE.md +7 -1
- package/ENG/accessibility-eng.md +5 -0
- package/ENG/clean-code-eng.md +1 -0
- package/ENG/design-code-eng.md +5 -0
- package/ENG/games-code-design-web-eng.md +6 -0
- package/ENG/perf-code-eng.md +3 -0
- package/ENG/premium-sites-studio-eng.md +9 -0
- package/ENG/sec-code-eng.md +5 -0
- package/ENG/test-code-eng.md +3 -0
- package/GUIDE_ROUTER.md +16 -0
- package/LOOP_ENGINEERING.md +139 -4
- package/ORCHESTRATOR_INTEGRATION.md +15 -0
- package/QUALITY_SCORECARD.md +4 -0
- package/README.md +43 -1
- package/THREAT_MODEL.md +6 -0
- package/conformance/README.md +42 -0
- package/conformance/backend-auth/EXPECTED_ROUTE.json +7 -0
- package/conformance/backend-auth/REQUEST.md +4 -0
- package/conformance/backend-auth/REQUIRED_EVIDENCE.json +3 -0
- package/conformance/backend-auth/REQUIRED_GATES.json +3 -0
- package/conformance/blind-premium-website/EXPECTED_ROUTE.json +7 -0
- package/conformance/blind-premium-website/REQUEST.md +6 -0
- package/conformance/blind-premium-website/REQUIRED_EVIDENCE.json +14 -0
- package/conformance/blind-premium-website/REQUIRED_GATES.json +3 -0
- package/conformance/complete-website/EXPECTED_ROUTE.json +7 -0
- package/conformance/complete-website/REQUEST.md +6 -0
- package/conformance/complete-website/REQUIRED_EVIDENCE.json +3 -0
- package/conformance/complete-website/REQUIRED_GATES.json +3 -0
- package/conformance/docs-only/EXPECTED_ROUTE.json +7 -0
- package/conformance/docs-only/REQUEST.md +4 -0
- package/conformance/docs-only/REQUIRED_EVIDENCE.json +3 -0
- package/conformance/docs-only/REQUIRED_GATES.json +3 -0
- package/conformance/runs/2026-08-11-codex-first-live.md +98 -0
- package/conformance/runs/2026-08-11-codex-second-live.md +87 -0
- package/conformance/simple-bug/EXPECTED_ROUTE.json +7 -0
- package/conformance/simple-bug/REQUEST.md +4 -0
- package/conformance/simple-bug/REQUIRED_EVIDENCE.json +3 -0
- package/conformance/simple-bug/REQUIRED_GATES.json +3 -0
- package/package.json +5 -4
- package/schemas/activation.schema.json +15 -0
- package/schemas/check.schema.json +23 -0
- package/schemas/config.schema.json +16 -0
- package/schemas/current-contract.schema.json +50 -0
- package/schemas/event.schema.json +20 -0
- package/schemas/evidence-coverage.schema.json +17 -0
- package/schemas/execution-receipt.schema.json +10 -0
- package/schemas/gate.schema.json +32 -0
- package/schemas/policy.schema.json +19 -0
- package/schemas/preflight.schema.json +23 -0
- package/schemas/routing-result.schema.json +1 -0
- package/schemas/source-registry.schema.json +29 -0
- package/schemas/task-bundle.schema.json +14 -0
- package/schemas/work-state.schema.json +7 -1
- package/src/cli.js +230 -9
- package/src/commands/activate.js +11 -0
- package/src/commands/advance.js +12 -0
- package/src/commands/audit.js +12 -0
- package/src/commands/bundle.js +10 -0
- package/src/commands/complete.js +18 -0
- package/src/commands/policy.js +19 -0
- package/src/commands/preflight.js +12 -0
- package/src/commands/prepare-completion.js +18 -0
- package/src/commands/record-check.js +20 -0
- package/src/commands/report.js +10 -0
- package/src/commands/route.js +14 -2
- package/src/commands/validate-receipt.js +7 -6
- package/src/core/activation.js +16 -0
- package/src/core/artifacts.js +132 -0
- package/src/core/audit.js +88 -0
- package/src/core/bundles.js +120 -0
- package/src/core/checks.js +115 -0
- package/src/core/completion-artifacts.js +281 -0
- package/src/core/completion.js +295 -0
- package/src/core/config.js +35 -0
- package/src/core/conformance.js +7 -0
- package/src/core/contract.js +141 -0
- package/src/core/coverage.js +89 -0
- package/src/core/events.js +124 -0
- package/src/core/gate-artifact.js +54 -0
- package/src/core/gates.js +55 -0
- package/src/core/guide-metadata.js +62 -0
- package/src/core/phase.js +88 -0
- package/src/core/policies.js +69 -0
- package/src/core/preflight.js +246 -0
- package/src/core/profile.js +48 -0
- package/src/core/protocol.js +34 -0
- package/src/core/receipt.js +40 -1
- package/src/core/report.js +49 -0
- package/src/core/repository.js +18 -0
- package/src/core/route-artifact.js +33 -0
- package/src/core/router.js +16 -8
- package/src/core/schema-validation.js +11 -0
- package/src/core/sources.js +86 -0
- package/src/core/templates.js +22 -4
- package/src/core/work-state.js +41 -13
- /package/.forgeloop/{.gitignore → forgeloop.gitignore} +0 -0
|
@@ -13,6 +13,12 @@ alwaysApply: true
|
|
|
13
13
|
6. Make the minimum change, run a specific check, and then run proportional regression checks.
|
|
14
14
|
7. Diagnose failures before fixing them and do not repeat an attempt without new evidence.
|
|
15
15
|
8. Request authority for unrelated external or destructive actions, installations, and publications. For a task-scoped missing Qwen-MM-Plugins capability, follow `LOOP_ENGINEERING.md`; API credentials and system dependencies remain separately gated.
|
|
16
|
-
9.
|
|
16
|
+
9. After implementation begins, do not return a final result in `EXECUTING`: follow `VERIFYING` → structured evidence → `REVIEWING` → execution receipt → validator-backed `COMPLETE`; otherwise report `BLOCKED` or `PARTIALLY VERIFIED` with exact findings.
|
|
17
|
+
10. Report only demonstrated results and checks.
|
|
18
|
+
|
|
19
|
+
Do not stop for non-blocking missing product details. When a safe, reversible
|
|
20
|
+
local default exists, record it as an agent assumption and follow the Blocking vs Non-Blocking Decisions policy in `LOOP_ENGINEERING.md`. Ask only for
|
|
21
|
+
load-bearing, irreversible, externally consequential, unsafe, or real
|
|
22
|
+
user/business decisions.
|
|
17
23
|
|
|
18
24
|
The loop and router are canonical sources; do not duplicate domain rules.
|
|
@@ -11,6 +11,12 @@ directory or file rules.
|
|
|
11
11
|
- Make the smallest coherent change and validate it with a specific check followed by proportional regression checks.
|
|
12
12
|
- Diagnose the cause before fixing a failure; do not make random attempts.
|
|
13
13
|
- Do not install unrelated software, publish, delete, migrate, or alter external state without authority. For a task-scoped missing Qwen-MM-Plugins capability, follow `LOOP_ENGINEERING.md`; API credentials and system dependencies remain separately gated.
|
|
14
|
+
- After implementation begins, do not return a final result in `EXECUTING`: follow `VERIFYING` → structured evidence → `REVIEWING` → execution receipt → validator-backed `COMPLETE`; otherwise report `BLOCKED` or `PARTIALLY VERIFIED` with exact findings.
|
|
14
15
|
- Report the result, checks actually run, limitations, and publication state.
|
|
15
16
|
|
|
17
|
+
Do not stop for non-blocking missing product details. When a safe, reversible
|
|
18
|
+
local default exists, record it as an agent assumption and follow the Blocking vs Non-Blocking Decisions policy in `LOOP_ENGINEERING.md`. Ask only for
|
|
19
|
+
load-bearing, irreversible, externally consequential, unsafe, or real
|
|
20
|
+
user/business decisions.
|
|
21
|
+
|
|
16
22
|
The loop and router are canonical; do not replicate domain rules here.
|
package/AGENTS.md
CHANGED
|
@@ -11,6 +11,14 @@ specific rule overrides them.
|
|
|
11
11
|
6. Make the smallest coherent change, run specific checks, and then run proportional regression checks.
|
|
12
12
|
7. Diagnose a failure before fixing it; do not repeat the same attempt without new evidence.
|
|
13
13
|
8. Do not install unrelated software, publish, delete, migrate data, or change external systems without applicable authority. For a task-scoped missing Qwen-MM-Plugins capability, follow the discovery protocol in `LOOP_ENGINEERING.md`; API credentials and system dependencies remain separately gated.
|
|
14
|
-
9.
|
|
14
|
+
9. Before implementation, create/validate `.forgeloop/current-contract.json`, persist deterministic routing, satisfy mandatory gates, and require `forgeloop preflight` to return `READY`.
|
|
15
|
+
10. Before claiming `COMPLETE`, require `forgeloop complete` to return `VALID`; otherwise report completion as not protocol-verified.
|
|
16
|
+
11. After implementation begins, do not return a final result in `EXECUTING`: advance through `VERIFYING`, record structured evidence, reach `REVIEWING`, prepare/update the execution receipt, and require `forgeloop complete` to return `VALID`. If closure cannot be reached, report `BLOCKED` or `PARTIALLY VERIFIED` with exact findings.
|
|
17
|
+
12. Finish with the result, checks actually run, limitations, and publication state.
|
|
18
|
+
|
|
19
|
+
Do not stop for non-blocking missing product details. When a safe, reversible
|
|
20
|
+
local default exists, record it as an agent assumption and follow the Blocking vs Non-Blocking Decisions policy in `LOOP_ENGINEERING.md`. Ask only for
|
|
21
|
+
load-bearing, irreversible, externally consequential, unsafe, or real
|
|
22
|
+
user/business decisions.
|
|
15
23
|
|
|
16
24
|
The guides provide technical defaults; explicit requirements and project evidence prevail.
|
package/AGENT_COMPATIBILITY.md
CHANGED
|
@@ -4,6 +4,19 @@
|
|
|
4
4
|
native entry point required by each supported agent. The package does not
|
|
5
5
|
install an agent, configure a provider, or run a live model session.
|
|
6
6
|
|
|
7
|
+
Compatibility has three distinct levels:
|
|
8
|
+
|
|
9
|
+
- `ADAPTER_COMPATIBLE`: the harness recognizes the installed instruction entry
|
|
10
|
+
file.
|
|
11
|
+
- `PROTOCOL_CAPABLE`: the harness can create the local contract, route, gates,
|
|
12
|
+
state, evidence, and receipt artifacts and run the validators.
|
|
13
|
+
- `CONFORMANCE_VERIFIED`: a live run passed one of the scenarios under
|
|
14
|
+
`conformance/` for that harness/model combination.
|
|
15
|
+
|
|
16
|
+
Reading `AGENTS.md` proves only instruction compatibility. It does not prove
|
|
17
|
+
that an active session followed preflight, legal phase chronology, or completion
|
|
18
|
+
validation.
|
|
19
|
+
|
|
7
20
|
## Optional capability extensions
|
|
8
21
|
|
|
9
22
|
The installed loop can direct the active agent to inspect its native model and
|
|
@@ -143,5 +156,5 @@ ENG/
|
|
|
143
156
|
schemas/
|
|
144
157
|
```
|
|
145
158
|
|
|
146
|
-
See the main [README](https://github.com/cassiomc1/
|
|
159
|
+
See the main [README](https://github.com/cassiomc1/forgeloop#readme) for the complete `npx` installation,
|
|
147
160
|
diagnostic, first-run, and update workflow.
|
package/CLAUDE.md
CHANGED
|
@@ -9,6 +9,12 @@ When working in this repository:
|
|
|
9
9
|
5. Make small changes, run a specific check, and then run proportional regression checks.
|
|
10
10
|
6. Investigate the root cause of a failure before fixing it.
|
|
11
11
|
7. Request authority for unrelated installation, publication, deletion, migration, or another external or destructive action. For a task-scoped missing Qwen-MM-Plugins capability, follow `LOOP_ENGINEERING.md`; API credentials and system dependencies remain separately gated.
|
|
12
|
-
8.
|
|
12
|
+
8. After implementation begins, do not return a final result in `EXECUTING`: follow `VERIFYING` → structured evidence → `REVIEWING` → execution receipt → validator-backed `COMPLETE`; otherwise report `BLOCKED` or `PARTIALLY VERIFIED` with exact findings.
|
|
13
|
+
9. Report current evidence, limitations, and publication state without claiming checks that were not run.
|
|
14
|
+
|
|
15
|
+
Do not stop for non-blocking missing product details. When a safe, reversible
|
|
16
|
+
local default exists, record it as an agent assumption and follow the Blocking vs Non-Blocking Decisions policy in `LOOP_ENGINEERING.md`. Ask only for
|
|
17
|
+
load-bearing, irreversible, externally consequential, unsafe, or real
|
|
18
|
+
user/business decisions.
|
|
13
19
|
|
|
14
20
|
Do not duplicate guide rules here; treat the loop and router as canonical sources.
|
package/ENG/accessibility-eng.md
CHANGED
|
@@ -4,6 +4,11 @@ language: en
|
|
|
4
4
|
description: "Practical WCAG 2.2-oriented accessibility protocol for web, mobile, and desktop."
|
|
5
5
|
version: "2026.09"
|
|
6
6
|
last-reviewed: "2026-08-10"
|
|
7
|
+
guide-id: accessibility
|
|
8
|
+
completion-evidence:
|
|
9
|
+
- keyboard-navigation
|
|
10
|
+
- focus-management
|
|
11
|
+
- mobile-viewport
|
|
7
12
|
---
|
|
8
13
|
|
|
9
14
|
# Accessibility as a Baseline (A11Y)
|
package/ENG/clean-code-eng.md
CHANGED
package/ENG/design-code-eng.md
CHANGED
|
@@ -4,6 +4,11 @@ language: en
|
|
|
4
4
|
description: "Visual direction, UX, motion, and perceived performance for premium digital experiences."
|
|
5
5
|
version: "2026.09"
|
|
6
6
|
last-reviewed: "2026-08-10"
|
|
7
|
+
guide-id: design
|
|
8
|
+
requires-gates:
|
|
9
|
+
- design
|
|
10
|
+
completion-evidence:
|
|
11
|
+
- visual-validation
|
|
7
12
|
---
|
|
8
13
|
|
|
9
14
|
# Web Design Premium v2 — Practical Guidelines
|
|
@@ -4,6 +4,12 @@ language: en
|
|
|
4
4
|
description: "Architecture, design, testing, and operation of 2D, 3D, and procedural web games."
|
|
5
5
|
version: "2026.09"
|
|
6
6
|
last-reviewed: "2026-08-10"
|
|
7
|
+
guide-id: games
|
|
8
|
+
requires-gates:
|
|
9
|
+
- simulation
|
|
10
|
+
completion-evidence:
|
|
11
|
+
- game-loop
|
|
12
|
+
- accessibility-validation
|
|
7
13
|
---
|
|
8
14
|
|
|
9
15
|
# Web Game Development Guide — 2D, 3D, and Procedural Systems
|
package/ENG/perf-code-eng.md
CHANGED
|
@@ -4,6 +4,9 @@ language: en
|
|
|
4
4
|
description: "Performance measurement, diagnosis, and improvement for web, mobile, desktop, APIs, and data."
|
|
5
5
|
version: "2026.09"
|
|
6
6
|
last-reviewed: "2026-08-10"
|
|
7
|
+
guide-id: performance
|
|
8
|
+
completion-evidence:
|
|
9
|
+
- performance-validation
|
|
7
10
|
---
|
|
8
11
|
|
|
9
12
|
# Performance Guide for Web, Mobile, Desktop, and Database Development
|
|
@@ -4,6 +4,15 @@ language: en
|
|
|
4
4
|
description: "Complete process for building premium websites at major design-studio quality."
|
|
5
5
|
version: "2026.09"
|
|
6
6
|
last-reviewed: "2026-08-10"
|
|
7
|
+
guide-id: premium
|
|
8
|
+
requires-gates:
|
|
9
|
+
- design
|
|
10
|
+
- quality
|
|
11
|
+
completion-evidence:
|
|
12
|
+
- responsive-validation
|
|
13
|
+
- accessibility-validation
|
|
14
|
+
- build
|
|
15
|
+
- visual-validation
|
|
7
16
|
---
|
|
8
17
|
|
|
9
18
|
# Premium Websites at Studio Level — Complete Process
|
package/ENG/sec-code-eng.md
CHANGED
|
@@ -4,6 +4,11 @@ language: en
|
|
|
4
4
|
description: "Verifiable security guidance for web, mobile, desktop, APIs, and the software supply chain."
|
|
5
5
|
version: "2026.09"
|
|
6
6
|
last-reviewed: "2026-08-10"
|
|
7
|
+
guide-id: security
|
|
8
|
+
requires-gates:
|
|
9
|
+
- threat-boundary
|
|
10
|
+
completion-evidence:
|
|
11
|
+
- security-validation
|
|
7
12
|
---
|
|
8
13
|
|
|
9
14
|
# Security Guide for Web, Mobile, and Desktop Development
|
package/ENG/test-code-eng.md
CHANGED
|
@@ -4,6 +4,9 @@ language: en
|
|
|
4
4
|
description: "Risk-based testing strategy and tools for modern languages and platforms."
|
|
5
5
|
version: "2026.09"
|
|
6
6
|
last-reviewed: "2026-08-10"
|
|
7
|
+
guide-id: test
|
|
8
|
+
completion-evidence:
|
|
9
|
+
- tests
|
|
7
10
|
---
|
|
8
11
|
|
|
9
12
|
# Risk-Based Testing Guide by Language and Technology
|
package/GUIDE_ROUTER.md
CHANGED
|
@@ -24,6 +24,22 @@ Useful questions:
|
|
|
24
24
|
|
|
25
25
|
## Canonical catalog
|
|
26
26
|
|
|
27
|
+
Guide frontmatter may declare protocol metadata in addition to its human
|
|
28
|
+
description:
|
|
29
|
+
|
|
30
|
+
```yaml
|
|
31
|
+
guide-id: premium
|
|
32
|
+
requires-gates:
|
|
33
|
+
- design
|
|
34
|
+
completion-evidence:
|
|
35
|
+
- build
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
`requires-gates` contributes to `forgeloop preflight`; each
|
|
39
|
+
`completion-evidence` identifier contributes to completion coverage. Metadata
|
|
40
|
+
is descriptive and local: it does not authorize tools, remote services, or
|
|
41
|
+
project commands.
|
|
42
|
+
|
|
27
43
|
| ID | Guide | Responsibility |
|
|
28
44
|
| --- | --- | --- |
|
|
29
45
|
| `premium` | [Premium websites](./ENG/premium-sites-studio-eng.md) | End-to-end delivery of high-quality websites and web experiences |
|
package/LOOP_ENGINEERING.md
CHANGED
|
@@ -4,6 +4,117 @@
|
|
|
4
4
|
> technical rules remain in the guides selected through
|
|
5
5
|
> [`GUIDE_ROUTER.md`](./GUIDE_ROUTER.md).
|
|
6
6
|
|
|
7
|
+
## Blocking vs Non-Blocking Decisions
|
|
8
|
+
|
|
9
|
+
Classify every unresolved decision before deciding whether to ask the user.
|
|
10
|
+
|
|
11
|
+
`NON_BLOCKING` applies when a safe local default exists, the choice is
|
|
12
|
+
reversible, it does not change external state, it is not sensitive or
|
|
13
|
+
authoritative, and it does not assert a real user or business fact. Examples
|
|
14
|
+
include fictional company name, demo phone number, placeholder copy, temporary logo text,
|
|
15
|
+
palette, typography, local-only fictional identity, fictional identity, demo
|
|
16
|
+
contacts, visual defaults, section ordering, and local-only form behavior.
|
|
17
|
+
|
|
18
|
+
`BLOCKING` applies when proceeding would require real legal business name,
|
|
19
|
+
real contact details, credentials, payment data, production endpoint,
|
|
20
|
+
deployment target, deployment or domain authority, destructive operation,
|
|
21
|
+
irreversible architectural decision, irreversible data choice, regulated/legal claim,
|
|
22
|
+
regulated claim, or another externally consequential/high-impact decision.
|
|
23
|
+
|
|
24
|
+
### Safe assumption rule
|
|
25
|
+
|
|
26
|
+
When a missing product detail is non-blocking, choose the smallest reasonable reversible default, explicitly classify it as an agent assumption, and record it in `current-contract.assumptions[]`. Each assumption must include `value`, `reason`, `scope`, `reversible=true`, and `source=agent-default`. Do not place resolved safe assumptions in unresolvedDecisions[]. Never present an assumption as a verified user or business fact.
|
|
27
|
+
|
|
28
|
+
The assumption boundary is:
|
|
29
|
+
|
|
30
|
+
```text
|
|
31
|
+
SAFE + REVERSIBLE + LOCAL + NON-SENSITIVE + NON-AUTHORITATIVE + NON-DESTRUCTIVE
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
Record the choice with an explicit `ASSUMPTION` marker. Unresolved blocking decisions must be recorded in `current-contract.unresolvedDecisions[]`; they prevent `preflight` from returning `READY` and block `EXECUTING` until resolved, but do not prevent contract serialization.
|
|
35
|
+
|
|
36
|
+
## Serialized protocol preparation
|
|
37
|
+
|
|
38
|
+
ForgeLoop keeps the agent responsible for implementation while making the
|
|
39
|
+
pre-implementation contract observable. Before executable changes, the target
|
|
40
|
+
should contain a schema-valid `.forgeloop/current-contract.json` and a persisted
|
|
41
|
+
`.forgeloop/routing-result.json`. Guide metadata can declare mandatory gates;
|
|
42
|
+
those gates are recorded under `.forgeloop/gates/` and are checked by:
|
|
43
|
+
|
|
44
|
+
```text
|
|
45
|
+
forgeloop preflight
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
`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.
|
|
49
|
+
|
|
50
|
+
## Completion validation and chronology
|
|
51
|
+
|
|
52
|
+
`COMPLETE` is a validator result, not a string an agent may assign by itself.
|
|
53
|
+
The local `events.ndjson` ledger records protocol milestones and hash links,
|
|
54
|
+
without prompts, hidden reasoning, credentials, or arbitrary command output.
|
|
55
|
+
The final validator checks the contract, route, state, gates, structured checks,
|
|
56
|
+
evidence coverage, receipt consistency, freshness, and chronology:
|
|
57
|
+
|
|
58
|
+
```text
|
|
59
|
+
forgeloop audit --strict
|
|
60
|
+
forgeloop complete
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
Every load-bearing success criterion must have `COVERED` evidence. A required
|
|
64
|
+
`OBSERVED` check cannot be satisfied by `INFERRED`, `NOT_VERIFIED`, or
|
|
65
|
+
`BLOCKED` evidence. If the validator cannot be run, use
|
|
66
|
+
`COMPLETE (FORGELOOP COMPLETION NOT VERIFIED)` rather than claiming protocol
|
|
67
|
+
validity.
|
|
68
|
+
|
|
69
|
+
## Post-implementation closure
|
|
70
|
+
|
|
71
|
+
Implementation finished is not task finished, and tests executed are not the
|
|
72
|
+
same as verification recorded. After implementation begins, do not stop or
|
|
73
|
+
return the final result while the ForgeLoop task remains in `EXECUTING`.
|
|
74
|
+
|
|
75
|
+
```text
|
|
76
|
+
POST-IMPLEMENTATION CLOSURE
|
|
77
|
+
|
|
78
|
+
EXECUTING
|
|
79
|
+
↓ advance
|
|
80
|
+
VERIFYING
|
|
81
|
+
↓ run checks and record structured evidence
|
|
82
|
+
REVIEWING
|
|
83
|
+
↓ prepare/update the execution receipt
|
|
84
|
+
forgeloop complete
|
|
85
|
+
↓ VALID
|
|
86
|
+
COMPLETE
|
|
87
|
+
```
|
|
88
|
+
|
|
89
|
+
Continue until the terminal outcome is either validator-backed `COMPLETE` or
|
|
90
|
+
an explicitly reported `BLOCKED` / `PARTIALLY VERIFIED` result with exact
|
|
91
|
+
unresolved findings. Record verification evidence before review. If a required
|
|
92
|
+
check fails, use `VERIFYING → DIAGNOSING → CORRECTING → VERIFYING`; do not skip
|
|
93
|
+
the evidence recording step or replace it with prose.
|
|
94
|
+
|
|
95
|
+
## Independent completion dimensions
|
|
96
|
+
|
|
97
|
+
Local task completion, verification, publication, and production readiness are
|
|
98
|
+
separate dimensions. A valid local result can therefore be reported as:
|
|
99
|
+
|
|
100
|
+
```text
|
|
101
|
+
TASK: COMPLETE
|
|
102
|
+
VERIFICATION: VALID
|
|
103
|
+
PUBLICATION: LOCAL_ONLY
|
|
104
|
+
PRODUCTION_READINESS: NOT_VERIFIED
|
|
105
|
+
```
|
|
106
|
+
|
|
107
|
+
ForgeLoop does not execute commands from profiles, contracts, receipts, state,
|
|
108
|
+
or policy artifacts. Publication and deployment require their own authority and
|
|
109
|
+
observed evidence.
|
|
110
|
+
|
|
111
|
+
Validators expose stable repair-oriented codes such as
|
|
112
|
+
`E_CONTRACT_MISSING`, `E_ROUTE_STALE`, `E_GATE_UNVERIFIED`,
|
|
113
|
+
`E_PHASE_CHRONOLOGY_INVALID`, `E_EVIDENCE_COVERAGE_PARTIAL`,
|
|
114
|
+
`E_PROFILE_SOURCE_UNKNOWN`, `E_RECEIPT_ROUTE_MISMATCH`, and
|
|
115
|
+
`E_PUBLICATION_CLAIM_UNVERIFIED`. Integrations should consume the code and
|
|
116
|
+
artifact paths rather than parse human-readable prose.
|
|
117
|
+
|
|
7
118
|
## Core principle
|
|
8
119
|
|
|
9
120
|
Never treat a request as an isolated instruction or the first plausible answer
|
|
@@ -92,6 +203,19 @@ The loop invariants are:
|
|
|
92
203
|
8. no unrelated refactor during uncertain diagnosis;
|
|
93
204
|
9. no secret in the profile, work state, receipt, or delegation artifacts;
|
|
94
205
|
10. no independent-agent claim when only self-review occurred.
|
|
206
|
+
11. no EXECUTING phase without a valid current contract.
|
|
207
|
+
12. no EXECUTING phase without a valid route when routing is required.
|
|
208
|
+
13. no EXECUTING phase while a mandatory pre-implementation gate is unsatisfied.
|
|
209
|
+
14. no COMPLETE phase without evidence coverage for every required success criterion.
|
|
210
|
+
15. no COMPLETE phase with stale contract, route, gate, state, or receipt fingerprints.
|
|
211
|
+
16. selected guides must match across route, work state, and receipt.
|
|
212
|
+
17. an agent decision cannot be recorded as a user fact.
|
|
213
|
+
18. a required OBSERVED check cannot be satisfied by INFERRED evidence.
|
|
214
|
+
19. BLOCKED evidence cannot be represented as PASSED.
|
|
215
|
+
20. completion must be validated by the protocol, not only declared by the agent.
|
|
216
|
+
21. protocol chronology must not permit execution before mandatory preflight events.
|
|
217
|
+
22. publication status and production readiness must remain independent from local task completion.
|
|
218
|
+
23. a task with implemented deliverables must not terminate in EXECUTING.
|
|
95
219
|
|
|
96
220
|
The serializable phase and transition contract is maintained in
|
|
97
221
|
[`ORCHESTRATOR_INTEGRATION.md`](./ORCHESTRATOR_INTEGRATION.md). It is a host
|
|
@@ -155,6 +279,13 @@ Do not interrupt the user for information that can be discovered safely in the
|
|
|
155
279
|
project. Request a decision when legitimate alternatives produce materially
|
|
156
280
|
different outcomes, authority is missing, or the action is destructive.
|
|
157
281
|
|
|
282
|
+
Unknown non-blocking details do not prevent contract creation. Record them as
|
|
283
|
+
reversible agent assumptions in `current-contract.assumptions[]` and continue.
|
|
284
|
+
Unresolved blocking decisions, missing authority, and unsafe-to-infer facts
|
|
285
|
+
must be serialized in `current-contract.unresolvedDecisions[]`; they prevent
|
|
286
|
+
`preflight` from returning `READY` and block `EXECUTING` until resolved, not
|
|
287
|
+
contract creation or serialization.
|
|
288
|
+
|
|
158
289
|
### Classify the request
|
|
159
290
|
|
|
160
291
|
- **Answer, explain, or review:** inspect and report evidence; do not make implicit changes.
|
|
@@ -275,10 +406,14 @@ requirements, closer instructions, code evidence, or higher-level host rules.
|
|
|
275
406
|
### Design gate
|
|
276
407
|
|
|
277
408
|
Before behavior, feature, architecture, or instruction changes, do proportional
|
|
278
|
-
design after discovery.
|
|
279
|
-
|
|
280
|
-
|
|
281
|
-
|
|
409
|
+
design after discovery. Classify unresolved design decisions before requesting
|
|
410
|
+
approval. Require user approval only for load-bearing decisions whose
|
|
411
|
+
alternatives materially change the requested product and cannot be resolved
|
|
412
|
+
through a safe, reversible local default. For non-blocking prototype choices,
|
|
413
|
+
choose a reasonable default, record the assumption, and continue. Retain
|
|
414
|
+
approval for material alternatives and external or irreversible decisions. For
|
|
415
|
+
small documentation maintenance, keep the treatment compact while still
|
|
416
|
+
confirming the objective, boundaries, and verification.
|
|
282
417
|
|
|
283
418
|
Use the [Execution contract](#execution-contract), [Project discovery](#project-discovery),
|
|
284
419
|
[Guide selection](#guide-selection), and [Proportional planning](#proportional-planning)
|
|
@@ -76,6 +76,15 @@ The following JSON Schemas define the boundaries a host may implement:
|
|
|
76
76
|
- `schemas/task-brief.schema.json` and
|
|
77
77
|
`schemas/delegated-result.schema.json` define optional delegation.
|
|
78
78
|
- `schemas/evidence.schema.json` defines the shared evidence vocabulary.
|
|
79
|
+
- `schemas/current-contract.schema.json`, `schemas/gate.schema.json`,
|
|
80
|
+
`schemas/preflight.schema.json`, and `schemas/source-registry.schema.json`
|
|
81
|
+
define preparation and provenance artifacts.
|
|
82
|
+
- `schemas/check.schema.json` and `schemas/evidence-coverage.schema.json`
|
|
83
|
+
define observed verification and load-bearing success coverage.
|
|
84
|
+
- `schemas/event.schema.json`, `schemas/activation.schema.json`,
|
|
85
|
+
`schemas/config.schema.json`, `schemas/policy.schema.json`, and
|
|
86
|
+
`schemas/task-bundle.schema.json` define chronology, mode, policy, and
|
|
87
|
+
handoff boundaries.
|
|
79
88
|
|
|
80
89
|
`src/core/conformance.js` validates relationships that individual schemas
|
|
81
90
|
cannot express: route/state protocol versions, route/state guide sets,
|
|
@@ -84,6 +93,12 @@ statuses are `VALID`, `INCOMPLETE`, `STALE`, `INCONSISTENT`, and `INVALID`.
|
|
|
84
93
|
`forgeloop validate-protocol` is read-only and reports the exact failed
|
|
85
94
|
invariant.
|
|
86
95
|
|
|
96
|
+
The preparation and completion commands are also local validators:
|
|
97
|
+
`preflight` must be `READY` before executable work, `audit` is a consistency
|
|
98
|
+
report, and `complete` returns `VALID` only after current evidence, coverage,
|
|
99
|
+
receipt relationships, and ledger chronology pass. None of these commands
|
|
100
|
+
execute a project command or a model.
|
|
101
|
+
|
|
87
102
|
Every artifact is JSON-compatible, carries `schemaVersion: 1` and
|
|
88
103
|
`protocolVersion: 1`, and contains no executable callbacks, provider-specific
|
|
89
104
|
tool objects, credentials, hidden prompts, or remote database references.
|
package/QUALITY_SCORECARD.md
CHANGED
|
@@ -14,6 +14,8 @@ policy are all present.
|
|
|
14
14
|
| Graph readiness | Serializable state/transition contracts and `ORCHESTRATOR_INTEGRATION.md`; no runtime required. |
|
|
15
15
|
| Portability | Node 20/22/24 Linux depth, OS smoke coverage, path/line-ending fixtures, and adapter compatibility evidence. |
|
|
16
16
|
| Observability | `inspect`/`status`/`validate-protocol` shared derived state classification, real schema health, shared evidence, rich doctor findings, receipts, and no telemetry. |
|
|
17
|
+
| Completion enforcement | Canonical contract, persisted route, guide-declared gates, preflight, phase ledger, structured checks, evidence coverage, `audit`, `report`, and `complete` validators. |
|
|
18
|
+
| Pre-contract autonomy | Blocking vs Non-Blocking Decisions policy, explicit ASSUMPTION / source=agent-default recording, safe-boundary invariant, positive and negative tests, and a blind run showing non-blocking ambiguity continues while blocking ambiguity remains user-gated. |
|
|
17
19
|
| 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. |
|
|
18
20
|
| Multi-agent coordination | Self-contained briefs, write/write and write/read ownership checks, dependency-set validation, reviewer independence, normalized results, and inline fallback. |
|
|
19
21
|
| Security boundaries | Realpath containment, bounded untrusted JSON, threat model, nested secret scanning, publication evidence, and explicit authority rules. |
|
|
@@ -48,6 +50,8 @@ are both present:
|
|
|
48
50
|
| Graph readiness | Serializable phase/transition mapping in `ORCHESTRATOR_INTEGRATION.md` | Python semantic validator and workflow-policy tests |
|
|
49
51
|
| 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` |
|
|
50
52
|
| 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 |
|
|
53
|
+
| 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` |
|
|
54
|
+
| Pre-contract autonomy | `LOOP_ENGINEERING.md`, `CLAUDE.md`, `AGENTS.md`, `.github/copilot-instructions.md`, `.cursor/rules/project-loop.mdc`, and the blind conformance artifacts | `tests/autonomy-policy.test.js`, `tests/conformance-scenarios.test.js` |
|
|
51
55
|
|
|
52
56
|
The implementation references above are local observations. OS runners,
|
|
53
57
|
remote links, provider sessions, publication, and deployment remain `Not
|
package/README.md
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# ForgeLoop — Instruction Guides for AI Agents
|
|
2
2
|
|
|
3
|
-
[](https://github.com/cassiomc1/forgeloop/actions/workflows/docs-quality.yml)
|
|
4
4
|
|
|
5
5
|
An English-only collection of operational guides for AI agents and developers.
|
|
6
6
|
It covers product strategy, code, testing, security, performance,
|
|
@@ -135,6 +135,18 @@ Protocol-support commands are local and do not invoke an agent or model:
|
|
|
135
135
|
|
|
136
136
|
```bash
|
|
137
137
|
npx @cassiomc1/forgeloop route --work complete-website --surface ui --risk untrusted-input
|
|
138
|
+
npx @cassiomc1/forgeloop activate
|
|
139
|
+
npx @cassiomc1/forgeloop preflight --json
|
|
140
|
+
npx @cassiomc1/forgeloop advance --to EXECUTING
|
|
141
|
+
npx @cassiomc1/forgeloop advance --to VERIFYING
|
|
142
|
+
npx @cassiomc1/forgeloop prepare-completion --json
|
|
143
|
+
npx @cassiomc1/forgeloop record-check --id tests --requirement tests --status passed --evidence-kind OBSERVED --command "npm test" --result "exit 0" --json
|
|
144
|
+
npx @cassiomc1/forgeloop advance --to REVIEWING
|
|
145
|
+
npx @cassiomc1/forgeloop audit --json
|
|
146
|
+
npx @cassiomc1/forgeloop complete --json
|
|
147
|
+
npx @cassiomc1/forgeloop report
|
|
148
|
+
npx @cassiomc1/forgeloop policy web-premium
|
|
149
|
+
npx @cassiomc1/forgeloop bundle --task website-001 --json
|
|
138
150
|
npx @cassiomc1/forgeloop inspect --json
|
|
139
151
|
npx @cassiomc1/forgeloop status --json
|
|
140
152
|
npx @cassiomc1/forgeloop status --contract-file .forgeloop/current-contract.json --json
|
|
@@ -144,6 +156,21 @@ npx @cassiomc1/forgeloop validate-protocol --route-file ./routing-result.json --
|
|
|
144
156
|
```
|
|
145
157
|
|
|
146
158
|
`route` expands declared signals into deterministic guide IDs and reason codes.
|
|
159
|
+
`activate` records a session marker without storing prompts or hidden reasoning.
|
|
160
|
+
Before implementation, write the canonical contract, persist the route, create
|
|
161
|
+
required gate artifacts under `.forgeloop/gates/`, and require `preflight` to
|
|
162
|
+
return `READY`. `advance` enforces legal phase transitions; it never runs the
|
|
163
|
+
project's commands. After implementation, advance to `VERIFYING`, use
|
|
164
|
+
`prepare-completion` to create a safe receipt skeleton, and use `record-check`
|
|
165
|
+
to serialize results that the agent has already observed. `record-check` never
|
|
166
|
+
executes the supplied command text. Advance to `REVIEWING` before running
|
|
167
|
+
`audit` and `complete`.
|
|
168
|
+
`audit` is a read-only consistency check. `complete` validates the final
|
|
169
|
+
contract, route, gates, phase ledger, structured evidence, coverage, receipt,
|
|
170
|
+
and freshness before it can return `VALID`. `report` renders the same result as
|
|
171
|
+
independent task, verification, publication, and production-readiness
|
|
172
|
+
dimensions. `policy` selects a local strictness pack and `bundle` exports
|
|
173
|
+
canonical protocol artifacts for handoff or review.
|
|
147
174
|
`inspect`, `status`, and `validate-state` explain installation and resumable
|
|
148
175
|
state; they do not execute commands from the target profile.
|
|
149
176
|
`inspect` and `status` parse the target-local schemas and report `valid`,
|
|
@@ -165,6 +192,21 @@ Capability gaps and inline/non-Git degraded mode are defined in
|
|
|
165
192
|
[`AGENT_COMPATIBILITY.md`](./AGENT_COMPATIBILITY.md); they are reported as
|
|
166
193
|
limitations rather than treated as silent successes.
|
|
167
194
|
|
|
195
|
+
### Live conformance modes
|
|
196
|
+
|
|
197
|
+
Standard blind conformance uses the same mode throughout a run:
|
|
198
|
+
|
|
199
|
+
```text
|
|
200
|
+
forgeloop preflight
|
|
201
|
+
→ forgeloop audit
|
|
202
|
+
→ forgeloop complete
|
|
203
|
+
```
|
|
204
|
+
|
|
205
|
+
Strict blind conformance is a separate profile. First verify the target
|
|
206
|
+
`PROJECT_PROFILE.md`, then use `--strict` consistently with `preflight`,
|
|
207
|
+
`audit`, and `complete`. Do not evaluate a Standard run with Strict criteria
|
|
208
|
+
unless that escalation is explicitly recorded.
|
|
209
|
+
|
|
168
210
|
### Protocol compatibility
|
|
169
211
|
|
|
170
212
|
The npm package version is independent of protocol version. The current
|
package/THREAT_MODEL.md
CHANGED
|
@@ -14,6 +14,10 @@ remaining trust boundaries and their executable evidence.
|
|
|
14
14
|
| Symlink escape | Redirects a managed path to another directory | Existing target parents and artifact paths | Reject symlinked targets, parents, and destinations before access | The check is not a filesystem lock | `tests/core.test.js`, `tests/portability.test.js`, `tests/fixtures/protocol/invalid/symlink-target.json` |
|
|
15
15
|
| Malicious manifest | Causes unsafe update or false ownership claims | `.forgeloop/manifest.json` | Schema, hash, safe-path, and preserve-flag validation; conflicts remain visible | A trusted operator can still deliberately edit the manifest | `tests/cli.test.js`, `tests/core.test.js` |
|
|
16
16
|
| Malicious work-state | Resumes stale, secret-bearing, or invalid work | `.forgeloop/work-state.json` | Schema/semantic checks, version checks, transition checks, contract/HEAD/artifact freshness, secret scan, size/depth bounds | Freshness cannot prove that an external process did not alter a file immediately afterward | `tests/work-state.test.js`, `tests/checkpoint-freshness.test.js`, `tests/security-limits.test.js` |
|
|
17
|
+
| Forged preparation | Makes an agent's prose claim look like a completed preflight | Contract, route, gate, and preflight artifacts | Canonical SHA-256 fingerprints, guide-declared gate requirements, stale-artifact checks, and `E_*` failures | The CLI cannot stop a separate process from writing project files before preflight | `tests/protocol-artifacts.test.js`, `tests/preflight.test.js` |
|
|
18
|
+
| Chronology rewrite | Hides execution before route, gates, or verification | `.forgeloop/events.ndjson` | Append-only local ledger, sequence numbers, hash chaining, and chronology validation without prompts or hidden reasoning | A privileged process can still replace the ledger after validation | `tests/lifecycle.test.js` |
|
|
19
|
+
| Unsupported profile fact | Turns an agent decision into a durable user fact | `PROJECT_PROFILE.md` and `.forgeloop/sources.json` | Source IDs, source-kind validation, unknown-reference rejection, and explicit misclassification failures | Arbitrary Markdown semantics still require a human or host-specific parser | `tests/profile-provenance.test.js`, `src/core/profile.js` |
|
|
20
|
+
| Weak verification | Treats a vague or inferred claim as observed evidence | Receipt checks and coverage | Versioned check schema, contradictory-status rejection, observed-evidence requirements, and coverage matrix | Evidence remains local and declarative; it is not a remote attestation service | `tests/evidence-coverage.test.js`, `tests/completion.test.js` |
|
|
17
21
|
| Malicious receipt | Turns local claims into false publication or completion claims | Execution receipt JSON | Semantic evidence checks for completion, checks, review, push, commit, and deployment; explicit publication booleans | Evidence text is declarative and must still be reviewed for provenance | `tests/receipt-semantics.test.js`, `tests/observability.test.js` |
|
|
18
22
|
| Malicious task brief | Grants a child task more authority than intended | Delegation brief JSON and host harness | Relative path boundaries, guide/verification/authority checks, secret-free validation, set validation, parent integration ownership | The host harness remains responsible for OS permissions and execution policy | `tests/delegation.test.js`, `tests/delegation-set.test.js` |
|
|
19
23
|
| Artifact content exposure | Sensitive material enters portable artifacts or diagnostics | State, receipt, delegation, evidence, and repository text | Nested key/value detection, shaped marker patterns, scanner coverage, no content echo in errors | Content scanners cannot prove that an unknown encoding is harmless | `tests/security-limits.test.js`, `tests/test_scan_secrets.py`, `scripts/scan_secrets.py` |
|
|
@@ -33,3 +37,5 @@ remaining trust boundaries and their executable evidence.
|
|
|
33
37
|
- Local checks do not imply remote publication, merge, deployment, or provider
|
|
34
38
|
confirmation.
|
|
35
39
|
- Credentials remain outside Git and outside protocol artifacts.
|
|
40
|
+
- `preflight`, `audit`, `report`, and `complete` never execute commands copied
|
|
41
|
+
from a profile, contract, receipt, state, gate, policy, or bundle.
|
|
@@ -0,0 +1,42 @@
|
|
|
1
|
+
# ForgeLoop conformance scenarios
|
|
2
|
+
|
|
3
|
+
These scenarios are adapter-facing contracts. They describe requests and the
|
|
4
|
+
artifacts a live agent must produce; they do not invoke a model runtime and are
|
|
5
|
+
not part of the deterministic `npm test` execution path.
|
|
6
|
+
|
|
7
|
+
Run a scenario in a disposable target using the Standard profile first:
|
|
8
|
+
|
|
9
|
+
```bash
|
|
10
|
+
npx @cassiomc1/forgeloop preflight --json
|
|
11
|
+
npx @cassiomc1/forgeloop audit --json
|
|
12
|
+
npx @cassiomc1/forgeloop complete --json
|
|
13
|
+
```
|
|
14
|
+
|
|
15
|
+
The expected post-implementation path is:
|
|
16
|
+
|
|
17
|
+
```text
|
|
18
|
+
EXECUTING
|
|
19
|
+
→ advance --to VERIFYING
|
|
20
|
+
→ prepare-completion
|
|
21
|
+
→ record-check for each observed check
|
|
22
|
+
→ advance --to REVIEWING
|
|
23
|
+
→ audit
|
|
24
|
+
→ complete
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
Use the Strict profile only as a separate experiment:
|
|
28
|
+
|
|
29
|
+
```bash
|
|
30
|
+
# PROJECT_PROFILE.md must be verified before this profile starts.
|
|
31
|
+
npx @cassiomc1/forgeloop preflight --strict --json
|
|
32
|
+
npx @cassiomc1/forgeloop audit --strict --json
|
|
33
|
+
npx @cassiomc1/forgeloop complete --strict --json
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
Do not mix Standard and Strict criteria in one conformance result. Live-run
|
|
37
|
+
diagnostic records belong under [`conformance/runs/`](./runs/); they must not
|
|
38
|
+
contain secrets, credentials, hidden reasoning, or unnecessary conversation
|
|
39
|
+
history.
|
|
40
|
+
|
|
41
|
+
The complete-website scenario deliberately fails when implementation starts
|
|
42
|
+
before the contract, route, and required gates exist.
|