@cassiomc1/forgeloop 0.1.11 → 0.1.13
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 +16 -18
- package/.github/copilot-instructions.md +16 -19
- package/AGENTS.md +18 -24
- package/AGENT_COMPATIBILITY.md +4 -211
- package/CLAUDE.md +16 -18
- package/LOOP_ENGINEERING.md +104 -0
- package/LOOP_SYSTEM_DESIGN.md +13 -11
- package/PROTOCOL_INTEGRATION.md +199 -0
- package/QUALITY_SCORECARD.md +1 -1
- package/README.md +125 -174
- package/TERMINOLOGY.md +2 -0
- package/THREAT_MODEL.md +5 -0
- package/package.json +5 -4
- package/src/commands/validate-protocol.js +11 -8
- package/src/core/conformance.js +47 -5
- package/src/core/discovery-surfaces.js +22 -0
- package/src/core/inspect.js +23 -12
- package/src/core/native-adapters.js +34 -2
- package/src/core/templates.js +1 -0
- package/src/core/verification-capability.js +47 -0
- package/conformance/README.md +0 -153
- package/conformance/backend-auth/EXPECTED_ROUTE.json +0 -7
- package/conformance/backend-auth/REQUEST.md +0 -4
- package/conformance/backend-auth/REQUIRED_EVIDENCE.json +0 -3
- package/conformance/backend-auth/REQUIRED_GATES.json +0 -3
- package/conformance/blind-premium-website/EXPECTED_ROUTE.json +0 -7
- package/conformance/blind-premium-website/REQUEST.md +0 -6
- package/conformance/blind-premium-website/REQUIRED_EVIDENCE.json +0 -14
- package/conformance/blind-premium-website/REQUIRED_GATES.json +0 -3
- package/conformance/complete-website/EXPECTED_ROUTE.json +0 -7
- package/conformance/complete-website/REQUEST.md +0 -6
- package/conformance/complete-website/REQUIRED_EVIDENCE.json +0 -3
- package/conformance/complete-website/REQUIRED_GATES.json +0 -3
- package/conformance/docs-only/EXPECTED_ROUTE.json +0 -7
- package/conformance/docs-only/REQUEST.md +0 -4
- package/conformance/docs-only/REQUIRED_EVIDENCE.json +0 -3
- package/conformance/docs-only/REQUIRED_GATES.json +0 -3
- package/conformance/runs/2026-08-11-codex-first-live.md +0 -98
- package/conformance/runs/2026-08-11-codex-second-live.md +0 -87
- package/conformance/runs/2026-08-13-codex-fifth-live.md +0 -386
- package/conformance/runs/2026-08-13-codex-fourth-live.md +0 -309
- package/conformance/runs/2026-08-13-codex-sixth-live.md +0 -412
- package/conformance/simple-bug/EXPECTED_ROUTE.json +0 -7
- package/conformance/simple-bug/REQUEST.md +0 -4
- package/conformance/simple-bug/REQUIRED_EVIDENCE.json +0 -3
- package/conformance/simple-bug/REQUIRED_GATES.json +0 -3
- package/src/core/agent-support.js +0 -89
|
@@ -3,30 +3,28 @@ description: Universal verified project loop
|
|
|
3
3
|
alwaysApply: true
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
+
<!-- FORGELOOP_PROJECT_PROTOCOL=REQUIRED -->
|
|
6
7
|
# Cursor — Universal Project Loop
|
|
7
8
|
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
4. Report the selected guide IDs.
|
|
12
|
-
5. Respect higher-level and local instructions and the latest request.
|
|
13
|
-
6. Make the minimum change, run a specific check, and then run proportional regression checks.
|
|
14
|
-
7. Diagnose failures before fixing them and do not repeat an attempt without new evidence.
|
|
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. 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.
|
|
9
|
+
This project is ForgeLoop-enabled. If your execution environment loaded this
|
|
10
|
+
file, ForgeLoop applies regardless of model, provider, IDE, agent, or runtime.
|
|
11
|
+
Do not treat ForgeLoop as vendor-specific, optional, or to follow only "in spirit".
|
|
17
12
|
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
13
|
+
1. Read [`LOOP_ENGINEERING.md`](../../LOOP_ENGINEERING.md) and [`PROTOCOL_INTEGRATION.md`](../../PROTOCOL_INTEGRATION.md).
|
|
14
|
+
2. Confirm [`PROJECT_PROFILE.md`](../../PROJECT_PROFILE.md) from real sources; initialize if in `template` mode.
|
|
15
|
+
3. Use [`GUIDE_ROUTER.md`](../../GUIDE_ROUTER.md) to activate relevant guides and report IDs.
|
|
16
|
+
4. Respect higher-level and local instructions and the latest request.
|
|
17
|
+
5. Make the minimum change, run specific checks, and run proportional regression checks.
|
|
18
|
+
6. Diagnose failures before fixing them; do not repeat attempts without new evidence.
|
|
19
|
+
7. Request authority for unrelated actions, installations, and publications. Do not install a missing verification tool merely to satisfy a check. For missing Qwen-MM-Plugins, follow `LOOP_ENGINEERING.md`.
|
|
20
|
+
8. After implementation begins, do not return a final result in `EXECUTING`: advance through `VERIFYING` → structured evidence → `REVIEWING` → execution receipt → validator-backed `COMPLETE`. If closure cannot be reached, report `BLOCKED` or `PARTIALLY VERIFIED`.
|
|
21
21
|
|
|
22
|
-
|
|
22
|
+
After implementation work for the current task is complete, run `forgeloop next` before returning a final result. Follow the returned lifecycle action until ForgeLoop reaches a terminal state or an explicit blocker.
|
|
23
23
|
|
|
24
|
-
|
|
25
|
-
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
|
|
26
|
-
load-bearing, irreversible, externally consequential, unsafe, or real
|
|
27
|
-
user/business decisions.
|
|
24
|
+
9. Report only demonstrated results and checks.
|
|
28
25
|
|
|
29
|
-
|
|
26
|
+
Do not stop for non-blocking missing product details. When a safe, reversible
|
|
27
|
+
local default exists, record it as an agent assumption and follow the Blocking vs Non-Blocking Decisions policy in `LOOP_ENGINEERING.md`.
|
|
30
28
|
|
|
31
29
|
## Pre-question decisions
|
|
32
30
|
|
|
@@ -1,30 +1,27 @@
|
|
|
1
|
+
<!-- FORGELOOP_PROJECT_PROTOCOL=REQUIRED -->
|
|
1
2
|
# GitHub Copilot — Universal Project Loop
|
|
2
3
|
|
|
3
|
-
|
|
4
|
-
|
|
4
|
+
This project is ForgeLoop-enabled. If your execution environment loaded this
|
|
5
|
+
file, ForgeLoop applies regardless of model, provider, IDE, agent, or runtime.
|
|
6
|
+
Do not treat ForgeLoop as vendor-specific, optional, or to follow only "in spirit".
|
|
5
7
|
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
-
|
|
9
|
-
-
|
|
8
|
+
Use these instructions across the repository while preserving local rules.
|
|
9
|
+
|
|
10
|
+
- Read [`LOOP_ENGINEERING.md`](../LOOP_ENGINEERING.md) and [`PROTOCOL_INTEGRATION.md`](../PROTOCOL_INTEGRATION.md).
|
|
11
|
+
- Confirm [`PROJECT_PROFILE.md`](../PROJECT_PROFILE.md) from evidence; initialize if in `template` mode.
|
|
12
|
+
- Select context with [`GUIDE_ROUTER.md`](../GUIDE_ROUTER.md) and report activated guide IDs.
|
|
10
13
|
- Respect the latest request, scope, and higher-level instructions.
|
|
11
|
-
- Make the smallest coherent change
|
|
12
|
-
- Diagnose
|
|
13
|
-
- Do not install
|
|
14
|
-
- After implementation begins, do not return a final result in `EXECUTING`:
|
|
14
|
+
- Make the smallest coherent change; validate with specific and regression checks.
|
|
15
|
+
- Diagnose causes before fixing failures; do not make unverified attempts.
|
|
16
|
+
- Do not install software, publish, delete, or alter external state without authority. Do not install a missing verification tool merely to satisfy a check. For missing Qwen-MM-Plugins, follow `LOOP_ENGINEERING.md`.
|
|
17
|
+
- After implementation begins, do not return a final result in `EXECUTING`: advance through `VERIFYING` → structured evidence → `REVIEWING` → execution receipt → validator-backed `COMPLETE`. If closure cannot be reached, report `BLOCKED` or `PARTIALLY VERIFIED`.
|
|
15
18
|
|
|
16
|
-
After implementation work for the current task is complete, run `forgeloop next`
|
|
17
|
-
before returning a final result. Follow the returned lifecycle action until
|
|
18
|
-
ForgeLoop reaches a terminal state or an explicit blocker.
|
|
19
|
+
After implementation work for the current task is complete, run `forgeloop next` before returning a final result. Follow the returned lifecycle action until ForgeLoop reaches a terminal state or an explicit blocker.
|
|
19
20
|
|
|
20
|
-
- Report
|
|
21
|
+
- Report results, checks actually run, limitations, and publication state.
|
|
21
22
|
|
|
22
23
|
Do not stop for non-blocking missing product details. When a safe, reversible
|
|
23
|
-
local default exists, record it as an agent assumption and follow the Blocking vs Non-Blocking Decisions policy in `LOOP_ENGINEERING.md`.
|
|
24
|
-
load-bearing, irreversible, externally consequential, unsafe, or real
|
|
25
|
-
user/business decisions.
|
|
26
|
-
|
|
27
|
-
The loop and router are canonical; do not replicate domain rules here.
|
|
24
|
+
local default exists, record it as an agent assumption and follow the Blocking vs Non-Blocking Decisions policy in `LOOP_ENGINEERING.md`.
|
|
28
25
|
|
|
29
26
|
## Pre-question decisions
|
|
30
27
|
|
package/AGENTS.md
CHANGED
|
@@ -1,31 +1,25 @@
|
|
|
1
|
+
<!-- FORGELOOP_PROJECT_PROTOCOL=REQUIRED -->
|
|
1
2
|
# Universal Project Loop Instructions
|
|
2
3
|
|
|
3
|
-
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
before returning a final result. Follow the returned lifecycle action until
|
|
20
|
-
ForgeLoop reaches a terminal state or an explicit blocker.
|
|
21
|
-
13. Finish with the result, checks actually run, limitations, and publication state.
|
|
4
|
+
This project is ForgeLoop-enabled. If your execution environment loaded this
|
|
5
|
+
file, ForgeLoop applies regardless of model, provider, IDE, agent, or runtime.
|
|
6
|
+
Do not treat ForgeLoop as vendor-specific, optional, or to follow only "in spirit".
|
|
7
|
+
|
|
8
|
+
1. Follow platform rules, the user's latest request, and local instructions first.
|
|
9
|
+
1. Read [`LOOP_ENGINEERING.md`](./LOOP_ENGINEERING.md) and [`PROTOCOL_INTEGRATION.md`](./PROTOCOL_INTEGRATION.md).
|
|
10
|
+
1. Inspect [`PROJECT_PROFILE.md`](./PROJECT_PROFILE.md). Confirm facts from sources; initialize if in `template` mode.
|
|
11
|
+
1. Use [`GUIDE_ROUTER.md`](./GUIDE_ROUTER.md) to select relevant guides and report activated guide IDs.
|
|
12
|
+
1. Make the smallest coherent change, run specific checks, and proportional regression checks.
|
|
13
|
+
1. Diagnose failures before fixing; do not repeat attempts without new evidence.
|
|
14
|
+
1. Do not install software, publish, delete, or migrate data without authority. Do not install a missing verification tool merely to satisfy a check. For missing Qwen-MM-Plugins, follow `LOOP_ENGINEERING.md`.
|
|
15
|
+
1. Before implementation, create/validate `.forgeloop/current-contract.json`, persist routing, satisfy gates, and require `forgeloop preflight` to return `READY`.
|
|
16
|
+
1. Before claiming `COMPLETE`, require `forgeloop complete` to return `VALID`; otherwise report completion as not protocol-verified.
|
|
17
|
+
1. After implementation begins, do not return a final result in `EXECUTING`: advance through `VERIFYING` → structured evidence → `REVIEWING` → execution receipt → validator-backed `COMPLETE`. If closure cannot be reached, report `BLOCKED` or `PARTIALLY VERIFIED`.
|
|
18
|
+
1. After implementation work for the current task is complete, run `forgeloop next` before returning a final result. Follow the returned lifecycle action until ForgeLoop reaches a terminal state or an explicit blocker.
|
|
19
|
+
1. Finish with result, checks run, limitations, and publication state.
|
|
22
20
|
|
|
23
21
|
Do not stop for non-blocking missing product details. When a safe, reversible
|
|
24
|
-
local default exists, record it as an agent assumption and follow the Blocking vs Non-Blocking Decisions policy in `LOOP_ENGINEERING.md`.
|
|
25
|
-
load-bearing, irreversible, externally consequential, unsafe, or real
|
|
26
|
-
user/business decisions.
|
|
27
|
-
|
|
28
|
-
The guides provide technical defaults; explicit requirements and project evidence prevail.
|
|
22
|
+
local default exists, record it as an agent assumption and follow the Blocking vs Non-Blocking Decisions policy in `LOOP_ENGINEERING.md`.
|
|
29
23
|
|
|
30
24
|
## Pre-question decisions
|
|
31
25
|
|
package/AGENT_COMPATIBILITY.md
CHANGED
|
@@ -1,214 +1,7 @@
|
|
|
1
|
-
#
|
|
1
|
+
# Deprecated filename
|
|
2
2
|
|
|
3
|
-
|
|
4
|
-
native entry point required by each supported agent. The package does not
|
|
5
|
-
install an agent, configure a provider, or run a live model session.
|
|
3
|
+
ForgeLoop is vendor-neutral and does not use a supported-agent allowlist.
|
|
6
4
|
|
|
7
|
-
|
|
5
|
+
The canonical integration contract is:
|
|
8
6
|
|
|
9
|
-
|
|
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
|
-
|
|
20
|
-
## Optional capability extensions
|
|
21
|
-
|
|
22
|
-
The installed loop can direct the active agent to inspect its native model and
|
|
23
|
-
harness capabilities. When a task requires a missing multimodal capability,
|
|
24
|
-
the agent may install the smallest task-scoped `Qwen-MM-Plugins` capability
|
|
25
|
-
through the harness's native mechanism or the official upstream installer,
|
|
26
|
-
then verify that the skill/MCP tool is callable before using it. This does not
|
|
27
|
-
turn the package into a model runtime or provider configuration tool: API keys,
|
|
28
|
-
system dependencies, and unrelated environment changes remain separately
|
|
29
|
-
gated. Live model sessions and external plugin installation are outside the
|
|
30
|
-
reproducible `npm test` boundary.
|
|
31
|
-
|
|
32
|
-
## Support matrix
|
|
33
|
-
|
|
34
|
-
| Agent | Support | Reads in the installed project | Official documentation |
|
|
35
|
-
| --- | --- | --- | --- |
|
|
36
|
-
| Codex | Direct adapter | `AGENTS.md` | [OpenAI — Custom instructions with AGENTS.md](https://developers.openai.com/codex/guides/agents-md) |
|
|
37
|
-
| Claude Code | Direct adapter | `CLAUDE.md` | [Anthropic — How Claude remembers your project](https://code.claude.com/docs/en/memory) |
|
|
38
|
-
| Cursor | Direct adapter | `AGENTS.md`, `.cursor/rules/project-loop.mdc` | [Cursor — Rules](https://cursor.com/docs/rules) |
|
|
39
|
-
| GitHub Copilot | Direct adapter | `.github/copilot-instructions.md` | [GitHub — Repository custom instructions](https://docs.github.com/en/copilot/how-tos/configure-custom-instructions-in-your-ide/add-repository-instructions-in-your-ide) |
|
|
40
|
-
| Antigravity | `AGENTS.md` compatibility | `AGENTS.md` | [Antigravity — CLI best practices](https://antigravity.google/docs/cli/best-practices) |
|
|
41
|
-
| OpenCode | `AGENTS.md` compatibility | `AGENTS.md` | [OpenCode — Rules](https://opencode.ai/docs/rules/) |
|
|
42
|
-
| Hermes | `AGENTS.md` compatibility | `AGENTS.md` | [Hermes — Context files](https://github.com/NousResearch/hermes-agent/blob/main/website/docs/user-guide/features/context-files.md) |
|
|
43
|
-
| Pi | `AGENTS.md` compatibility | `AGENTS.md` | [Pi — Coding-agent SDK and context files](https://github.com/earendil-works/pi/blob/main/packages/coding-agent/docs/sdk.md) |
|
|
44
|
-
| Command Code | `AGENTS.md` compatibility | `AGENTS.md` | [Command Code — Memory](https://commandcode.ai/docs/core-concepts/memory) |
|
|
45
|
-
| Freebuff | `AGENTS.md` compatibility | `AGENTS.md` | [Freebuff — Knowledge file names](https://github.com/CodebuffAI/freebuff/blob/main/common/src/constants/knowledge.ts) |
|
|
46
|
-
|
|
47
|
-
## What direct and compatibility mean
|
|
48
|
-
|
|
49
|
-
Direct adapters are files with a format or location specifically documented
|
|
50
|
-
by the agent. Compatibility entries use the same root `AGENTS.md`; no second
|
|
51
|
-
copy of the loop is needed because the agent officially recognizes that file.
|
|
52
|
-
|
|
53
|
-
Claude Code is the important exception: it reads `CLAUDE.md`, not `AGENTS.md`.
|
|
54
|
-
The package therefore installs both files, with the Claude-specific adapter
|
|
55
|
-
pointing to the same canonical loop documents.
|
|
56
|
-
|
|
57
|
-
Codex, Cursor, and GitHub Copilot may also discover `AGENTS.md` on some
|
|
58
|
-
surfaces. The dedicated files remain useful because they make the behavior
|
|
59
|
-
explicit and cover each product's native entry point.
|
|
60
|
-
|
|
61
|
-
## Harness capability and bootstrap boundary
|
|
62
|
-
|
|
63
|
-
An adapter proves that the package installed a supported instruction or context
|
|
64
|
-
entry point. It is not proof of a callable optional tool, isolation feature,
|
|
65
|
-
review primitive, or bootstrap hook in the active harness, even when the
|
|
66
|
-
canonical loop can use one when available.
|
|
67
|
-
|
|
68
|
-
When a harness supports native context bootstrap or startup verification, prefer
|
|
69
|
-
an explicit unique marker to confirm that the expected instruction path is
|
|
70
|
-
active. When that proof is unavailable, treat the adapter file and repository
|
|
71
|
-
checks as installation evidence only.
|
|
72
|
-
|
|
73
|
-
Optional capability gaps use the loop fallback rules instead of invented
|
|
74
|
-
commands or assumed integrations. Agents should never invent a tool call to
|
|
75
|
-
simulate missing harness support. Global configuration, provider credentials,
|
|
76
|
-
system packages, and other machine-level setup remain outside the installed
|
|
77
|
-
package boundary.
|
|
78
|
-
|
|
79
|
-
## Precedence and existing instructions
|
|
80
|
-
|
|
81
|
-
`forgeloop init` never overwrites an existing instruction file. If the target
|
|
82
|
-
already contains a more specific or higher-priority file, that agent may use
|
|
83
|
-
it instead of the installed entry point:
|
|
84
|
-
|
|
85
|
-
- Codex can use `AGENTS.override.md` before `AGENTS.md`.
|
|
86
|
-
- Claude Code combines `CLAUDE.md` and closer `CLAUDE.local.md` files.
|
|
87
|
-
- Cursor may combine project rules with user rules and nested rules.
|
|
88
|
-
- Antigravity can add workspace rules under `.agents/rules/`.
|
|
89
|
-
- Hermes gives `.hermes.md`/`HERMES.md` priority over `AGENTS.md`.
|
|
90
|
-
- OpenCode can add instructions through `opencode.json` and uses
|
|
91
|
-
`CLAUDE.md` as a fallback when `AGENTS.md` is absent.
|
|
92
|
-
- Freebuff recognizes `knowledge.md`, `AGENTS.md`, and `CLAUDE.md`; an existing
|
|
93
|
-
higher-priority knowledge file can affect which project context is loaded.
|
|
94
|
-
|
|
95
|
-
When a target already has local rules, keep them and merge only the relevant
|
|
96
|
-
loop reference manually. Run `doctor --path /path/to/project` after resolving
|
|
97
|
-
the merge so missing files and managed drift are visible.
|
|
98
|
-
|
|
99
|
-
## External workflow compatibility
|
|
100
|
-
|
|
101
|
-
An external planning, brainstorming, design-review, testing, or documentation
|
|
102
|
-
workflow can be installed and still be `INCOMPATIBLE WITH AUTONOMOUS MODE`.
|
|
103
|
-
Installation is a capability fact; compatibility is a precedence and behavior
|
|
104
|
-
fact. The ForgeLoop `NON_BLOCKING` classification remains authoritative in
|
|
105
|
-
autonomous mode. A mandatory approval policy for a reversible local choice is
|
|
106
|
-
recorded as `WORKFLOW_CONFLICT`, with no user question and no fake entry in
|
|
107
|
-
`current-contract.unresolvedDecisions[]`.
|
|
108
|
-
|
|
109
|
-
The supported autonomous boundary is:
|
|
110
|
-
|
|
111
|
-
| Workflow policy | Result |
|
|
112
|
-
| --- | --- |
|
|
113
|
-
| Local planning, review, tests, or docs | Compatible. |
|
|
114
|
-
| Approval only for a real ForgeLoop `BLOCKING` decision | Compatible; the justified question may proceed. |
|
|
115
|
-
| Approval for every design choice or before implementation | `INCOMPATIBLE WITH AUTONOMOUS MODE`. |
|
|
116
|
-
| Reclassifying reversible aesthetics as blocking | `INCOMPATIBLE WITH AUTONOMOUS MODE`. |
|
|
117
|
-
|
|
118
|
-
Interactive operation is explicit (`autonomousMode=false`) and must not be
|
|
119
|
-
selected silently. Live conformance records the available and invoked external
|
|
120
|
-
workflows, mandatory-approval setting, brainstorming/design hard gates,
|
|
121
|
-
autonomy mode, process count, subagent count, and delegation status. For the
|
|
122
|
-
sixth blind run, the harness must report:
|
|
123
|
-
|
|
124
|
-
```text
|
|
125
|
-
mandatory-approval workflows enabled: NO
|
|
126
|
-
external brainstorming hard gate enabled: NO
|
|
127
|
-
external design approval gate enabled: NO
|
|
128
|
-
subagents enabled: NO
|
|
129
|
-
delegation enabled: NO
|
|
130
|
-
```
|
|
131
|
-
|
|
132
|
-
Question attribution remains `USER_REQUIREMENT`,
|
|
133
|
-
`FORGELOOP_BLOCKING_DECISION`, `EXTERNAL_WORKFLOW_POLICY`, or
|
|
134
|
-
`MODEL_PREFERENCE`. In autonomous mode, only the first two can authorize a
|
|
135
|
-
question, and `ASK_USER` additionally requires a valid ForgeLoop blocking
|
|
136
|
-
reason. External policy alone cannot manufacture a blocker.
|
|
137
|
-
|
|
138
|
-
If a mandatory approval workflow cannot be disabled, the run is
|
|
139
|
-
`TEST_NOT_STARTED`; do not call it a failed or successful conformance result.
|
|
140
|
-
|
|
141
|
-
## Deterministic verification boundary
|
|
142
|
-
|
|
143
|
-
The repository verifies package contents, adapter paths, installation into a
|
|
144
|
-
selected target directory, and the official instruction-file contracts. It
|
|
145
|
-
does not launch Codex, Claude Code, or another provider during `npm test`; live
|
|
146
|
-
sessions require external authentication and are intentionally outside the
|
|
147
|
-
reproducible package test suite.
|
|
148
|
-
|
|
149
|
-
## Protocol-support commands and degraded mode
|
|
150
|
-
|
|
151
|
-
The CLI can deterministically evaluate declared routing signals, inspect target
|
|
152
|
-
health, validate local receipts and work state, and report resumable status. It
|
|
153
|
-
does not call an LLM, schedule agents, execute commands from
|
|
154
|
-
`PROJECT_PROFILE.md`, or provide `forgeloop run`/orchestration commands.
|
|
155
|
-
|
|
156
|
-
If a harness has no subagents, worktrees, web access, MCP, persistent state, or
|
|
157
|
-
Git checkout, the compatible agent continues inline and reports the missing
|
|
158
|
-
capability as a limitation. Inline execution is not independent review, a
|
|
159
|
-
non-Git target cannot provide branch/HEAD drift evidence, and a missing remote
|
|
160
|
-
service is a blocker rather than a simulated success.
|
|
161
|
-
|
|
162
|
-
The degraded-mode contract is explicit:
|
|
163
|
-
|
|
164
|
-
| Missing capability | Required behavior |
|
|
165
|
-
| --- | --- |
|
|
166
|
-
| Subagents | Execute the same brief inline; do not claim delegation or independent review. |
|
|
167
|
-
| Worktrees or isolation | Keep ownership boundaries in the brief and serialize conflicting work. |
|
|
168
|
-
| Web or MCP | Use a local equivalent only when it provides compatible evidence; otherwise mark the check not verified or blocked. |
|
|
169
|
-
| Persistent state | Keep the handoff in the current session and report that resume across sessions is unavailable. |
|
|
170
|
-
| Git checkout | Continue with local file evidence, but report that branch/HEAD drift cannot be verified. |
|
|
171
|
-
|
|
172
|
-
These are limitations of the active harness, not reasons to invent a command,
|
|
173
|
-
provider, remote service, or successful check.
|
|
174
|
-
|
|
175
|
-
## Installed files
|
|
176
|
-
|
|
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:
|
|
180
|
-
|
|
181
|
-
```text
|
|
182
|
-
AGENTS.md
|
|
183
|
-
CLAUDE.md
|
|
184
|
-
.cursor/rules/project-loop.mdc
|
|
185
|
-
.github/copilot-instructions.md
|
|
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/
|
|
205
|
-
```
|
|
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
|
-
|
|
213
|
-
See the main [README](https://github.com/cassiomc1/forgeloop#readme) for the complete `npx` installation,
|
|
214
|
-
diagnostic, first-run, and update workflow.
|
|
7
|
+
[`PROTOCOL_INTEGRATION.md`](./PROTOCOL_INTEGRATION.md)
|
package/CLAUDE.md
CHANGED
|
@@ -1,27 +1,25 @@
|
|
|
1
|
+
<!-- FORGELOOP_PROJECT_PROTOCOL=REQUIRED -->
|
|
1
2
|
# Claude Code — Universal Project Loop
|
|
2
3
|
|
|
3
|
-
|
|
4
|
+
This project is ForgeLoop-enabled. If your execution environment loaded this
|
|
5
|
+
file, ForgeLoop applies regardless of model, provider, IDE, agent, or runtime.
|
|
6
|
+
Do not treat ForgeLoop as vendor-specific, optional, or to follow only "in spirit".
|
|
4
7
|
|
|
5
|
-
|
|
6
|
-
2. Read [`LOOP_ENGINEERING.md`](./LOOP_ENGINEERING.md) before planning or editing.
|
|
7
|
-
3. Verify [`PROJECT_PROFILE.md`](./PROJECT_PROFILE.md) against real sources. Initialize it in a target project when it remains in `template` mode.
|
|
8
|
-
4. Consult [`GUIDE_ROUTER.md`](./GUIDE_ROUTER.md), select all relevant guides and only those guides, and announce their IDs.
|
|
9
|
-
5. Make small changes, run a specific check, and then run proportional regression checks.
|
|
10
|
-
6. Investigate the root cause of a failure before fixing it.
|
|
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. 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.
|
|
8
|
+
When working in this repository:
|
|
13
9
|
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
10
|
+
1. Follow higher-level instructions, the user's latest request, and local rules first.
|
|
11
|
+
1. Read [`LOOP_ENGINEERING.md`](./LOOP_ENGINEERING.md) and [`PROTOCOL_INTEGRATION.md`](./PROTOCOL_INTEGRATION.md).
|
|
12
|
+
1. Verify [`PROJECT_PROFILE.md`](./PROJECT_PROFILE.md) against real sources; initialize if in `template` mode.
|
|
13
|
+
1. Consult [`GUIDE_ROUTER.md`](./GUIDE_ROUTER.md), select relevant guides, and announce their IDs.
|
|
14
|
+
1. Make small changes, run specific checks, and run proportional regression checks.
|
|
15
|
+
1. Investigate root causes before fixing failures; do not make unverified attempts.
|
|
16
|
+
1. Request authority for unrelated installations, publications, deletions, or migrations. Do not install a missing verification tool merely to satisfy a check. For missing Qwen-MM-Plugins, follow `LOOP_ENGINEERING.md`.
|
|
17
|
+
1. After implementation begins, do not return a final result in `EXECUTING`: advance through `VERIFYING` → structured evidence → `REVIEWING` → execution receipt → validator-backed `COMPLETE`. If closure cannot be reached, report `BLOCKED` or `PARTIALLY VERIFIED`.
|
|
18
|
+
1. After implementation work for the current task is complete, run `forgeloop next` before returning a final result. Follow the returned lifecycle action until ForgeLoop reaches a terminal state or an explicit blocker.
|
|
19
|
+
1. Report current evidence, limitations, and publication state without claiming checks that were not run.
|
|
18
20
|
|
|
19
21
|
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`.
|
|
21
|
-
load-bearing, irreversible, externally consequential, unsafe, or real
|
|
22
|
-
user/business decisions.
|
|
23
|
-
|
|
24
|
-
Do not duplicate guide rules here; treat the loop and router as canonical sources.
|
|
22
|
+
local default exists, record it as an agent assumption and follow the Blocking vs Non-Blocking Decisions policy in `LOOP_ENGINEERING.md`.
|
|
25
23
|
|
|
26
24
|
## Pre-question decisions
|
|
27
25
|
|
package/LOOP_ENGINEERING.md
CHANGED
|
@@ -4,6 +4,110 @@
|
|
|
4
4
|
> technical rules remain in the guides selected through
|
|
5
5
|
> [`GUIDE_ROUTER.md`](./GUIDE_ROUTER.md).
|
|
6
6
|
|
|
7
|
+
## Protocol applicability
|
|
8
|
+
|
|
9
|
+
ForgeLoop is a project-local engineering protocol.
|
|
10
|
+
|
|
11
|
+
If the active execution environment discovers a ForgeLoop project adapter,
|
|
12
|
+
ForgeLoop applies to work performed in that project regardless of the
|
|
13
|
+
environment's model, provider, product, IDE, agent name, runtime name, or
|
|
14
|
+
orchestration implementation.
|
|
15
|
+
|
|
16
|
+
Named integrations, documented discovery surfaces, previous conformance runs,
|
|
17
|
+
and certification records are informational evidence only. They are never an
|
|
18
|
+
allowlist.
|
|
19
|
+
|
|
20
|
+
An execution environment that has not been previously tested is
|
|
21
|
+
`CONFORMANCE_UNVERIFIED`, not `PROTOCOL_OPTIONAL`.
|
|
22
|
+
|
|
23
|
+
```text
|
|
24
|
+
INVALID:
|
|
25
|
+
"I am not a named ForgeLoop integration, therefore ForgeLoop does not apply."
|
|
26
|
+
"I will follow ForgeLoop only in spirit because my harness is not documented."
|
|
27
|
+
|
|
28
|
+
VALID:
|
|
29
|
+
"I discovered the ForgeLoop project adapter. ForgeLoop applies.
|
|
30
|
+
My current runtime may have unverified or limited capabilities, which I will evaluate."
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
### Unknown execution environment policy
|
|
34
|
+
|
|
35
|
+
An unknown or undocumented execution environment is not a blocker by itself.
|
|
36
|
+
|
|
37
|
+
If it discovered the ForgeLoop project adapter, evaluate capabilities:
|
|
38
|
+
|
|
39
|
+
- If protocol-capable: execute ForgeLoop normally.
|
|
40
|
+
- If capability-limited: execute all supported ForgeLoop dimensions, fail closed
|
|
41
|
+
for unavailable dimensions, and report limitations precisely.
|
|
42
|
+
|
|
43
|
+
Never downgrade ForgeLoop to optional guidance solely because the runtime
|
|
44
|
+
name is unknown.
|
|
45
|
+
|
|
46
|
+
### CLI-owned artifact policy
|
|
47
|
+
|
|
48
|
+
Lifecycle-owned ForgeLoop artifacts must be created or mutated only through
|
|
49
|
+
the supported ForgeLoop lifecycle commands or canonical ForgeLoop APIs:
|
|
50
|
+
|
|
51
|
+
- `.forgeloop/preflight.json`
|
|
52
|
+
- `.forgeloop/work-state.json`
|
|
53
|
+
- `.forgeloop/events.ndjson`
|
|
54
|
+
- `.forgeloop/execution-receipt.json`
|
|
55
|
+
- completion recovery metadata
|
|
56
|
+
- canonical check/evidence state
|
|
57
|
+
- terminal-result lifecycle state
|
|
58
|
+
|
|
59
|
+
If the required CLI/API capability cannot be resolved:
|
|
60
|
+
|
|
61
|
+
- do not fabricate current lifecycle state;
|
|
62
|
+
- do not synthesize event history;
|
|
63
|
+
- do not manually assign `COMPLETE`;
|
|
64
|
+
- do not construct a fake execution receipt;
|
|
65
|
+
- do not invent `record-check` evidence;
|
|
66
|
+
- do not rewrite `events.ndjson` to simulate chronology.
|
|
67
|
+
|
|
68
|
+
Report the corresponding ForgeLoop dimension as `NOT_VERIFIED` with
|
|
69
|
+
`E_FORGELOOP_CLI_UNAVAILABLE`.
|
|
70
|
+
|
|
71
|
+
### Missing verification tool policy
|
|
72
|
+
|
|
73
|
+
A missing verification tool does not grant authority to install it.
|
|
74
|
+
|
|
75
|
+
When a verification command or checker is unavailable:
|
|
76
|
+
|
|
77
|
+
1. Try only already-installed or explicitly non-installing resolution paths.
|
|
78
|
+
2. Prefer an already available equivalent when it can verify the same requirement.
|
|
79
|
+
3. If no suitable local capability exists, request explicit installation authority
|
|
80
|
+
only when the missing verification is genuinely required.
|
|
81
|
+
4. If authority is unavailable or the check is non-critical, record the affected
|
|
82
|
+
verification dimension as `NOT_VERIFIED` with `E_VERIFICATION_TOOL_UNAVAILABLE`.
|
|
83
|
+
|
|
84
|
+
Do not retry a failed non-installing lookup with a command that implicitly
|
|
85
|
+
downloads or installs the missing package.
|
|
86
|
+
|
|
87
|
+
Examples of forbidden escalation without authority:
|
|
88
|
+
|
|
89
|
+
```text
|
|
90
|
+
npx --no-install TOOL → missing
|
|
91
|
+
npx TOOL → implicit install
|
|
92
|
+
```
|
|
93
|
+
|
|
94
|
+
```text
|
|
95
|
+
command -v TOOL → missing
|
|
96
|
+
package-manager install TOOL
|
|
97
|
+
```
|
|
98
|
+
|
|
99
|
+
```text
|
|
100
|
+
local executable missing
|
|
101
|
+
curl | sh
|
|
102
|
+
```
|
|
103
|
+
|
|
104
|
+
Automatic installation is allowed only when an explicit ForgeLoop rule grants
|
|
105
|
+
that exact task-scoped installation authority and higher-priority platform/user
|
|
106
|
+
rules permit it.
|
|
107
|
+
|
|
108
|
+
A missing checker must never be converted into environmental mutation merely
|
|
109
|
+
to make verification pass.
|
|
110
|
+
|
|
7
111
|
## Blocking vs Non-Blocking Decisions
|
|
8
112
|
|
|
9
113
|
Classify every unresolved decision before deciding whether to ask the user.
|
package/LOOP_SYSTEM_DESIGN.md
CHANGED
|
@@ -10,11 +10,13 @@ The system should use every guide that materially helps the task without loading
|
|
|
10
10
|
|
|
11
11
|
## Primary decisions
|
|
12
12
|
|
|
13
|
-
- The
|
|
14
|
-
|
|
15
|
-
-
|
|
16
|
-
|
|
17
|
-
|
|
13
|
+
- The protocol is vendor-neutral, project-scoped, and capability-based,
|
|
14
|
+
supporting any AI agent, coding assistant, IDE runtime, or developer workflow.
|
|
15
|
+
- Common discovery surfaces (e.g. `AGENTS.md`, `CLAUDE.md`, `.cursor/rules/`,
|
|
16
|
+
`.github/copilot-instructions.md`) use project-local shims delegating to the
|
|
17
|
+
canonical protocol under `.forgeloop/kit/`, while other environments use the
|
|
18
|
+
shared `AGENTS.md` entry point or manual bootstrap.
|
|
19
|
+
- The portable instruction layer uses Markdown and each environment's native instruction mechanism; the optional local Node CLI validates and installs the kit without an agent runtime or third-party dependency.
|
|
18
20
|
- English is the only language used by repository content and guide metadata.
|
|
19
21
|
- The agent uses all applicable guides, not every file indiscriminately.
|
|
20
22
|
- Design, planning, test-first, and review process gates live in the canonical loop and scale with task risk instead of becoming unconditional boilerplate in every adapter or architecture note.
|
|
@@ -131,11 +133,11 @@ GitHub Copilot adapter. It activates the same operational contract while preserv
|
|
|
131
133
|
|
|
132
134
|
Always-applicable Cursor adapter. It delegates decisions to the loop and router.
|
|
133
135
|
|
|
134
|
-
### `
|
|
136
|
+
### `PROTOCOL_INTEGRATION.md`
|
|
135
137
|
|
|
136
|
-
Human-readable
|
|
137
|
-
|
|
138
|
-
|
|
138
|
+
Human-readable integration protocol and capability levels. It explains native entry
|
|
139
|
+
points, discovery surfaces, required and optional capabilities, degradation,
|
|
140
|
+
and the deterministic verification boundary.
|
|
139
141
|
|
|
140
142
|
### `LOOP_ENGINEERING.md`
|
|
141
143
|
|
|
@@ -389,8 +391,8 @@ update practice.
|
|
|
389
391
|
## Acceptance criteria
|
|
390
392
|
|
|
391
393
|
- The repository and its maintained content are English-only.
|
|
392
|
-
-
|
|
393
|
-
|
|
394
|
+
- Common project instruction surfaces and generic bootstrap mechanisms have a
|
|
395
|
+
documented entry into one canonical loop.
|
|
394
396
|
- The router selects every relevant guide and excludes irrelevant guides in the six defined scenarios.
|
|
395
397
|
- The profile contains verifiable facts, sources, and real commands without secrets.
|
|
396
398
|
- The loop requires evidence before completion claims and exits safely when blocked.
|