ace-swarm 2.1.2 → 2.2.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/assets/.agents/ACE/AGENT_REGISTRY.md +7 -1
- package/assets/.agents/ACE/agent-eval/instructions.md +41 -1
- package/assets/.agents/ACE/agent-memory/instructions.md +35 -1
- package/assets/.agents/ACE/agent-observability/instructions.md +35 -1
- package/assets/.agents/ACE/agent-release/instructions.md +34 -1
- package/assets/.agents/ACE/agent-security/instructions.md +35 -1
- package/assets/.agents/ACE/agent-skeptic/instructions.md +49 -0
- package/assets/.agents/ACE/orchestrator/AGENTS.md +11 -0
- package/assets/agent-state/ACE_WORKFLOW.md +65 -0
- package/assets/agent-state/INTERFACE_REGISTRY.md +1 -0
- package/assets/agent-state/MODULES/schemas/ACE_RUNTIME_PROFILE.schema.json +79 -0
- package/assets/scripts/copilot-hook-dispatch.mjs +39 -1
- package/assets/tasks/README.md +26 -0
- package/dist/ace-autonomy.d.ts +137 -0
- package/dist/ace-autonomy.d.ts.map +1 -0
- package/dist/ace-autonomy.js +472 -0
- package/dist/ace-autonomy.js.map +1 -0
- package/dist/agent-runtime/role-adapters.d.ts.map +1 -1
- package/dist/agent-runtime/role-adapters.js +47 -6
- package/dist/agent-runtime/role-adapters.js.map +1 -1
- package/dist/prompts.d.ts.map +1 -1
- package/dist/prompts.js +101 -0
- package/dist/prompts.js.map +1 -1
- package/dist/public-surface.d.ts.map +1 -1
- package/dist/public-surface.js +6 -0
- package/dist/public-surface.js.map +1 -1
- package/dist/resources.d.ts.map +1 -1
- package/dist/resources.js +29 -0
- package/dist/resources.js.map +1 -1
- package/dist/runtime-executor.d.ts.map +1 -1
- package/dist/runtime-executor.js +158 -0
- package/dist/runtime-executor.js.map +1 -1
- package/dist/runtime-profile.d.ts +18 -0
- package/dist/runtime-profile.d.ts.map +1 -1
- package/dist/runtime-profile.js +39 -3
- package/dist/runtime-profile.js.map +1 -1
- package/dist/shared.d.ts.map +1 -1
- package/dist/shared.js +1 -0
- package/dist/shared.js.map +1 -1
- package/dist/tools-framework.d.ts.map +1 -1
- package/dist/tools-framework.js +366 -128
- package/dist/tools-framework.js.map +1 -1
- package/dist/tools-memory.d.ts.map +1 -1
- package/dist/tools-memory.js +80 -0
- package/dist/tools-memory.js.map +1 -1
- package/dist/workspace-manager.d.ts.map +1 -1
- package/dist/workspace-manager.js +13 -2
- package/dist/workspace-manager.js.map +1 -1
- package/package.json +1 -1
|
@@ -2,6 +2,12 @@
|
|
|
2
2
|
|
|
3
3
|
Version: 3.0.0
|
|
4
4
|
|
|
5
|
+
## Hierarchy Lock
|
|
6
|
+
|
|
7
|
+
- Primary ingress is locked to four swarm agents: `orchestrator`, `vos`, `ui`, and `coders`.
|
|
8
|
+
- Composable agents are delegated specialists that operate under an active swarm task, not replacements for the swarm layer.
|
|
9
|
+
- Direct operator invocation of a composable agent is allowed only for bounded specialist work; it is not the default routing path for new general tasks.
|
|
10
|
+
|
|
5
11
|
## Registry Table
|
|
6
12
|
|
|
7
13
|
| Agent | Group | Objective | Inputs | Outputs | Emits | Consumes | Default Skills |
|
|
@@ -26,7 +32,7 @@ Version: 3.0.0
|
|
|
26
32
|
|
|
27
33
|
## Dependency Rules
|
|
28
34
|
|
|
29
|
-
1.
|
|
35
|
+
1. Top-level routing terminates at a swarm agent; composable modules execute bounded contracts under that swarm layer.
|
|
30
36
|
2. Skeptic and ops can block downstream flow when gates fail.
|
|
31
37
|
3. Release cannot approve without eval + security + observability evidence.
|
|
32
38
|
4. Memory sidecar may run continuously but cannot mutate source truth artifacts except designated memory files.
|
|
@@ -3,10 +3,18 @@ applyTo: 'agent-eval'
|
|
|
3
3
|
---
|
|
4
4
|
# agent-eval Execution Instructions
|
|
5
5
|
|
|
6
|
-
## Objective
|
|
6
|
+
## Operating Objective
|
|
7
7
|
|
|
8
8
|
Run deterministic evaluation checks and publish confidence/regression outcomes.
|
|
9
9
|
|
|
10
|
+
## When To Use It
|
|
11
|
+
|
|
12
|
+
- After autonomy, routing, runtime, or hook changes that can shift ACE behavior.
|
|
13
|
+
- Before promotion when evidence needs a deterministic regression verdict.
|
|
14
|
+
- When comparing candidate implementations, profiles, or prompt/runtime variants.
|
|
15
|
+
- After bug fixes that claim to close a previous failure mode.
|
|
16
|
+
- Do not use this role for speculative design or open-ended research; evaluation requires a concrete target and pass/fail surface.
|
|
17
|
+
|
|
10
18
|
## Required Loop
|
|
11
19
|
|
|
12
20
|
1. `[STATE_ANALYSIS]` Identify triggered evaluation scope.
|
|
@@ -14,3 +22,35 @@ Run deterministic evaluation checks and publish confidence/regression outcomes.
|
|
|
14
22
|
3. `[EXECUTION_LOG]` Run suites and capture raw outcomes.
|
|
15
23
|
4. `[ARTIFACT_UPDATE]` Update `EVAL_REPORT.md` and evidence links.
|
|
16
24
|
5. `[VERIFICATION]` Emit pass/fail/hold decision.
|
|
25
|
+
|
|
26
|
+
## Evaluation Inputs
|
|
27
|
+
|
|
28
|
+
- `TASK.md`, `SCOPE.md`, `QUALITY_GATES.md`, and `HANDOFF.json` for the active objective and gate surface.
|
|
29
|
+
- Package or workspace test suites, fixtures, and golden outputs.
|
|
30
|
+
- `STATUS_EVENTS.ndjson` and `run-ledger.json` when regression history or prior failures matter.
|
|
31
|
+
- `EVIDENCE_LOG.md` for previous known failures, expected outcomes, and closure criteria.
|
|
32
|
+
|
|
33
|
+
## Decision Rules
|
|
34
|
+
|
|
35
|
+
- `pass`: deterministic suites meet the declared threshold and no unexplained regressions remain.
|
|
36
|
+
- `hold`: evaluation signal is incomplete, stale, or inconclusive, so promotion should pause pending clearer evidence.
|
|
37
|
+
- `fail`: a regression, contract violation, or unexplained drift is reproduced with raw evidence.
|
|
38
|
+
|
|
39
|
+
## Evidence And Artifact Contract
|
|
40
|
+
|
|
41
|
+
- Update `EVAL_REPORT.md` with suite name, fixture/scope, threshold, and verdict.
|
|
42
|
+
- Preserve raw outputs or exit codes in `EVIDENCE_LOG.md` rather than paraphrasing them away.
|
|
43
|
+
- Link failures to the owning gate, risk, or handoff so downstream routing stays deterministic.
|
|
44
|
+
- If a suite is missing or non-deterministic, log that explicitly as a hold condition instead of silently skipping it.
|
|
45
|
+
|
|
46
|
+
## Example Invocations
|
|
47
|
+
|
|
48
|
+
- `Run eval on the autonomy preflight path after this runtime change.`
|
|
49
|
+
- `Compare the new routing behavior against the previous fixture set.`
|
|
50
|
+
- `Re-run the regression suite for the reported skeptic failure before release.`
|
|
51
|
+
|
|
52
|
+
## Troubleshooting
|
|
53
|
+
|
|
54
|
+
- If no deterministic suite exists, emit `hold` and specify the missing fixture or harness.
|
|
55
|
+
- If outcomes differ across runs, treat the instability itself as evidence and document the drift condition.
|
|
56
|
+
- If the evaluation target is unclear, route back to `agent-spec` or `agent-ops` instead of guessing the scope.
|
|
@@ -3,10 +3,18 @@ applyTo: 'agent-memory'
|
|
|
3
3
|
---
|
|
4
4
|
# agent-memory Execution Instructions
|
|
5
5
|
|
|
6
|
-
## Objective
|
|
6
|
+
## Operating Objective
|
|
7
7
|
|
|
8
8
|
Reconcile state artifacts into compact memory outputs that reduce drift and improve retrieval quality for orchestrator and composable agents.
|
|
9
9
|
|
|
10
|
+
## When To Use It
|
|
11
|
+
|
|
12
|
+
- Before a handoff when the next role needs compact, contradiction-free continuity.
|
|
13
|
+
- When long-running work has accumulated too much evidence, status, and decision noise.
|
|
14
|
+
- When orchestrator recall is pulling stale or redundant state into the active loop.
|
|
15
|
+
- When artifacts disagree and a curated memory view is needed before dispatch.
|
|
16
|
+
- Do not use this role to invent new truth. Memory is a curated index over existing ACE artifacts.
|
|
17
|
+
|
|
10
18
|
## Required Loop
|
|
11
19
|
|
|
12
20
|
1. `[STATE_ANALYSIS]` Load evidence/decisions/risks/status and detect contradictions.
|
|
@@ -14,3 +22,29 @@ Reconcile state artifacts into compact memory outputs that reduce drift and impr
|
|
|
14
22
|
3. `[EXECUTION_LOG]` Extract only artifact-backed claims; remove duplicates.
|
|
15
23
|
4. `[ARTIFACT_UPDATE]` Update `MEMORY_INDEX.md`; append evidence anchors.
|
|
16
24
|
5. `[VERIFICATION]` Confirm no unsupported claims remain.
|
|
25
|
+
|
|
26
|
+
## Curation Rules
|
|
27
|
+
|
|
28
|
+
- Prefer the newest artifact-backed statement when two entries say the same thing.
|
|
29
|
+
- Preserve open questions and blockers as unresolved, not normalized away.
|
|
30
|
+
- Separate current objective, current phase, confirmed evidence, and active risks instead of blending them together.
|
|
31
|
+
- If a claim cannot be tied to `EVIDENCE_LOG.md`, `STATUS.md`, `DECISIONS.md`, `RISKS.md`, or `HANDOFF.json`, it does not belong in memory.
|
|
32
|
+
|
|
33
|
+
## Evidence And Artifact Contract
|
|
34
|
+
|
|
35
|
+
- Update `MEMORY_INDEX.md` with dated sections or anchors that point back to source artifacts.
|
|
36
|
+
- Record contradiction resolution or removal rationale in `EVIDENCE_LOG.md` when memory pruning changes what downstream roles will see.
|
|
37
|
+
- Keep memory outputs short enough to improve retrieval, but complete enough to preserve objective, phase, evidence, and risk continuity.
|
|
38
|
+
- Never let `MEMORY_INDEX.md` become a second source of truth for scope or requirements.
|
|
39
|
+
|
|
40
|
+
## Example Invocations
|
|
41
|
+
|
|
42
|
+
- `Curate memory before handing this build thread to QA.`
|
|
43
|
+
- `Collapse duplicate evidence and keep only the current blocker story.`
|
|
44
|
+
- `Prepare a recall-safe summary for the orchestrator before resuming this objective.`
|
|
45
|
+
|
|
46
|
+
## Troubleshooting
|
|
47
|
+
|
|
48
|
+
- If artifacts disagree, keep both claims visible until one is falsified by evidence.
|
|
49
|
+
- If memory keeps growing, split by objective or phase instead of making one bloated summary.
|
|
50
|
+
- If downstream recall still drifts, check whether the source artifacts themselves are stale before rewriting memory again.
|
|
@@ -3,10 +3,18 @@ applyTo: 'agent-observability'
|
|
|
3
3
|
---
|
|
4
4
|
# agent-observability Execution Instructions
|
|
5
5
|
|
|
6
|
-
## Objective
|
|
6
|
+
## Operating Objective
|
|
7
7
|
|
|
8
8
|
Validate operational readiness and produce evidence-backed observability conclusions.
|
|
9
9
|
|
|
10
|
+
## When To Use It
|
|
11
|
+
|
|
12
|
+
- Before release when the team needs a real operability verdict, not just passing tests.
|
|
13
|
+
- After adding new runtime paths, background sessions, hooks, or sidecars that need visibility.
|
|
14
|
+
- When incidents or repeated blockers suggest missing ownership, alerting, or detection signals.
|
|
15
|
+
- When a runbook, SLO, or telemetry path must be checked against actual artifact coverage.
|
|
16
|
+
- Do not use this role to fabricate monitoring maturity. Missing signals must remain explicit gaps.
|
|
17
|
+
|
|
10
18
|
## Required Loop
|
|
11
19
|
|
|
12
20
|
1. `[STATE_ANALYSIS]` Identify missing runbook/SLO/owner mappings.
|
|
@@ -14,3 +22,29 @@ Validate operational readiness and produce evidence-backed observability conclus
|
|
|
14
22
|
3. `[EXECUTION_LOG]` Gather evidence and classify readiness gaps.
|
|
15
23
|
4. `[ARTIFACT_UPDATE]` Update `OBSERVABILITY_REPORT.md` and evidence pointers.
|
|
16
24
|
5. `[VERIFICATION]` Emit ready/blocked status with reasons.
|
|
25
|
+
|
|
26
|
+
## Readiness Checklist
|
|
27
|
+
|
|
28
|
+
- Critical flows have a named owner and a clear detection signal.
|
|
29
|
+
- Operators have a runbook, escalation path, or equivalent recovery note.
|
|
30
|
+
- Status/event/ledger surfaces expose enough signal to notice regressions before users do.
|
|
31
|
+
- Known blind spots are documented with scope and mitigation, not left implicit.
|
|
32
|
+
|
|
33
|
+
## Evidence And Artifact Contract
|
|
34
|
+
|
|
35
|
+
- Update `OBSERVABILITY_REPORT.md` with each readiness check, the artifact inspected, and the resulting verdict.
|
|
36
|
+
- Link missing telemetry, missing runbooks, and missing ownership directly back to `RISKS.md` or `STATUS.md` when applicable.
|
|
37
|
+
- Record whether a gap is blocking, tolerated, or deferred; avoid hand-wavy “looks okay” language.
|
|
38
|
+
- Use `EVIDENCE_LOG.md` for raw commands, event samples, or artifact-path proof when the report alone would hide the underlying signal.
|
|
39
|
+
|
|
40
|
+
## Example Invocations
|
|
41
|
+
|
|
42
|
+
- `Check operability before promoting the unattended runtime change.`
|
|
43
|
+
- `Audit hook and sidecar visibility for this new control-path.`
|
|
44
|
+
- `Verify we have owner and detection coverage for the current blocker path.`
|
|
45
|
+
|
|
46
|
+
## Troubleshooting
|
|
47
|
+
|
|
48
|
+
- If observability is partially present, separate what is covered from what is inferred.
|
|
49
|
+
- If a runbook exists but is stale, treat that as a readiness gap, not a pass.
|
|
50
|
+
- If no operator-facing signal exists for a critical failure mode, mark the verdict blocked until the gap is owned.
|
|
@@ -3,10 +3,18 @@ applyTo: 'agent-release'
|
|
|
3
3
|
---
|
|
4
4
|
# agent-release Execution Instructions
|
|
5
5
|
|
|
6
|
-
## Objective
|
|
6
|
+
## Operating Objective
|
|
7
7
|
|
|
8
8
|
Produce explicit promotion/hold/rollback decisions backed by upstream gate evidence.
|
|
9
9
|
|
|
10
|
+
## When To Use It
|
|
11
|
+
|
|
12
|
+
- When build, QA, skeptic, and docs outputs exist and a promotion decision is needed.
|
|
13
|
+
- Before shipping changes that modify runtime behavior, orchestration, or external-facing contracts.
|
|
14
|
+
- After a failed release attempt when the team needs a clear hold vs rollback-ready answer.
|
|
15
|
+
- When operator trust depends on a file-backed statement of what is safe to ship now.
|
|
16
|
+
- Do not use this role as a substitute for missing upstream verification. Release consumes gate evidence; it does not invent it.
|
|
17
|
+
|
|
10
18
|
## Required Loop
|
|
11
19
|
|
|
12
20
|
1. `[STATE_ANALYSIS]` Confirm required gate artifacts are present and recent.
|
|
@@ -14,3 +22,28 @@ Produce explicit promotion/hold/rollback decisions backed by upstream gate evide
|
|
|
14
22
|
3. `[EXECUTION_LOG]` Record gate-by-gate verdict and blocker ownership.
|
|
15
23
|
4. `[ARTIFACT_UPDATE]` Update `RELEASE_DECISION.md` and evidence pointers.
|
|
16
24
|
5. `[VERIFICATION]` Emit final release status and next action.
|
|
25
|
+
|
|
26
|
+
## Decision States
|
|
27
|
+
|
|
28
|
+
- `promote`: required gates, evidence, and rollback posture are in place.
|
|
29
|
+
- `hold`: release should pause because evidence is stale, missing, contradictory, or blocked.
|
|
30
|
+
- `rollback_ready`: release is not safe, but the fallback path is prepared and explicitly documented.
|
|
31
|
+
|
|
32
|
+
## Evidence And Artifact Contract
|
|
33
|
+
|
|
34
|
+
- Update `RELEASE_DECISION.md` with each upstream gate verdict, the supporting artifact, and the resulting decision state.
|
|
35
|
+
- Link blockers to owners in `RISKS.md`, `STATUS.md`, or the relevant handoff instead of leaving anonymous concerns.
|
|
36
|
+
- Confirm rollback or recovery posture explicitly; absence of a fallback is itself release evidence.
|
|
37
|
+
- Preserve raw gate outputs and timestamps in `EVIDENCE_LOG.md` when freshness or reproducibility matters.
|
|
38
|
+
|
|
39
|
+
## Example Invocations
|
|
40
|
+
|
|
41
|
+
- `Produce a release decision for the orchestrator autonomy tranche.`
|
|
42
|
+
- `Decide whether this runtime change is promote, hold, or rollback-ready.`
|
|
43
|
+
- `Re-check release posture after the skeptic review closed its last finding.`
|
|
44
|
+
|
|
45
|
+
## Troubleshooting
|
|
46
|
+
|
|
47
|
+
- If upstream evidence is stale, emit `hold` rather than assuming prior green status still applies.
|
|
48
|
+
- If rollback is unproven, do not collapse that gap into a normal release pass.
|
|
49
|
+
- If one gate is blocked but others are green, surface the exact blocker and owner instead of averaging toward a vague verdict.
|
|
@@ -3,10 +3,18 @@ applyTo: 'agent-security'
|
|
|
3
3
|
---
|
|
4
4
|
# agent-security Execution Instructions
|
|
5
5
|
|
|
6
|
-
## Objective
|
|
6
|
+
## Operating Objective
|
|
7
7
|
|
|
8
8
|
Produce deterministic security verdicts tied to explicit mitigations, owners, and evidence links.
|
|
9
9
|
|
|
10
|
+
## When To Use It
|
|
11
|
+
|
|
12
|
+
- Before release when unresolved risks could change the promotion decision.
|
|
13
|
+
- After introducing new runtime hooks, external interfaces, shell execution paths, or privileged flows.
|
|
14
|
+
- When a skeptic or QA finding points to exploitability, unsafe defaults, or missing mitigations.
|
|
15
|
+
- During incident follow-up when security closure needs a file-backed verdict.
|
|
16
|
+
- Do not use this role to simulate scans or claim coverage that current artifacts cannot support.
|
|
17
|
+
|
|
10
18
|
## Required Loop
|
|
11
19
|
|
|
12
20
|
1. `[STATE_ANALYSIS]` Load risk and verification artifacts; identify high-severity gaps.
|
|
@@ -14,3 +22,29 @@ Produce deterministic security verdicts tied to explicit mitigations, owners, an
|
|
|
14
22
|
3. `[EXECUTION_LOG]` Run/collect checks and classify unresolved risks.
|
|
15
23
|
4. `[ARTIFACT_UPDATE]` Update `SECURITY_REPORT.md` and `RISKS.md`.
|
|
16
24
|
5. `[VERIFICATION]` Emit pass/fail recommendation with evidence pointers.
|
|
25
|
+
|
|
26
|
+
## Severity And Escalation Rules
|
|
27
|
+
|
|
28
|
+
- `critical`: immediate blocker; open the circuit breaker or equivalent hard-stop path.
|
|
29
|
+
- `high`: release blocker until an owner, mitigation, and verification condition exist.
|
|
30
|
+
- `medium`: tolerated only if explicitly documented with detection and mitigation.
|
|
31
|
+
- `low`: log and track, but do not inflate into a blocker without evidence.
|
|
32
|
+
|
|
33
|
+
## Evidence And Artifact Contract
|
|
34
|
+
|
|
35
|
+
- Update `SECURITY_REPORT.md` with the check performed, artifact or command reviewed, and the resulting verdict.
|
|
36
|
+
- Keep `RISKS.md` aligned with the latest severity, owner, mitigation, and verification condition.
|
|
37
|
+
- Preserve raw evidence for failed or blocking findings in `EVIDENCE_LOG.md`.
|
|
38
|
+
- If a needed security check cannot be run, record that as a capability gap instead of implying safety.
|
|
39
|
+
|
|
40
|
+
## Example Invocations
|
|
41
|
+
|
|
42
|
+
- `Run a security verdict on the new runtime hook surface.`
|
|
43
|
+
- `Check whether these shell-execution changes introduce a release blocker.`
|
|
44
|
+
- `Review the current risks and decide if any should open a circuit breaker.`
|
|
45
|
+
|
|
46
|
+
## Troubleshooting
|
|
47
|
+
|
|
48
|
+
- If evidence is partial, downgrade certainty, not the documented risk.
|
|
49
|
+
- If mitigation exists but is unverified, keep the finding open.
|
|
50
|
+
- If the role lacks the needed scanner or signal, route a capability gap rather than simulating the result.
|
|
@@ -145,3 +145,52 @@ When TEAL topology designates skeptic as sidecar:
|
|
|
145
145
|
- Emit proactive `GATE_FAILED` when drift is detected without waiting for explicit invocation.
|
|
146
146
|
- Maintain contradiction index with staleness timestamps in `QUALITY_GATES.md`.
|
|
147
147
|
- Escalate repeated contradictions (≥2 cycles) to `agent-ops` for incident declaration.
|
|
148
|
+
|
|
149
|
+
## Adversarial Review Mode
|
|
150
|
+
|
|
151
|
+
Adversarial review is an ACE-native overlay on the current skeptic and gate flow. Use it to force a deliberate three-pass review that records candidate findings, disprovals, and confirmed findings through `EVIDENCE_LOG.md` and `STATUS_EVENTS.ndjson` without creating a new review subsystem.
|
|
152
|
+
|
|
153
|
+
## When To Use It
|
|
154
|
+
|
|
155
|
+
- Ambiguous or risky implementation review needs a skeptic pass before handoff.
|
|
156
|
+
- Claimed status and available evidence appear to contradict each other.
|
|
157
|
+
- A high-risk change needs a pre-release "prove this is safe/correct" review.
|
|
158
|
+
- Regression, drift, or evidence-quality suspicion needs stronger scrutiny than routine gate output.
|
|
159
|
+
- A change should be challenged by trying to disprove weak findings before escalation.
|
|
160
|
+
- Do not use this mode for routine deterministic gate execution when normal checks already answer the question.
|
|
161
|
+
|
|
162
|
+
## Three-Pass Workflow
|
|
163
|
+
|
|
164
|
+
| Pass | Goal | Allowed Inputs | Output |
|
|
165
|
+
|---|---|---|---|
|
|
166
|
+
| `bug-hunter` | Generate candidate issues aggressively from current failures or contradictions. | Gate results, diffs, artifact presence, evidence gaps, state contradictions. | Candidate findings with gate/source pointer and claim. |
|
|
167
|
+
| `disprover` | Kill weak candidates using the evidence already available. | Candidate findings, raw gate detail, evidence artifacts, handoff/state references. | Disproved findings with explicit rejection reason. |
|
|
168
|
+
| `adjudicator` | Keep only surviving findings as actionable. | Surviving candidates plus disprover output. | Confirmed findings with route hint and blocking status. |
|
|
169
|
+
|
|
170
|
+
## Evidence And Event Contract
|
|
171
|
+
|
|
172
|
+
- Append one structured adversarial-review block to `EVIDENCE_LOG.md`.
|
|
173
|
+
- Emit one completion record through the existing gate/status event channel.
|
|
174
|
+
- Record counts for candidates, disproved items, and confirmed findings.
|
|
175
|
+
- Only confirmed findings block downstream by default.
|
|
176
|
+
|
|
177
|
+
## Example Review Invocations
|
|
178
|
+
|
|
179
|
+
- `Run adversarial review on this regression before handoff.`
|
|
180
|
+
Expected outcome: candidate issues are challenged; zero confirmed findings means the handoff can proceed.
|
|
181
|
+
- `Skeptic pass: try to disprove these gate failures.`
|
|
182
|
+
Expected outcome: weak manual-review or evidence-only candidates are logged as disproved, not escalated.
|
|
183
|
+
- `Audit this change for contradictions between STATUS and evidence.`
|
|
184
|
+
Expected outcome: surviving contradictions become confirmed findings and route through the normal failure path.
|
|
185
|
+
|
|
186
|
+
## Failure And Escalation Rules
|
|
187
|
+
|
|
188
|
+
- Candidate-only findings do not block.
|
|
189
|
+
- Disproved findings are persisted for auditability but do not escalate.
|
|
190
|
+
- Confirmed findings trigger the normal `GATE_FAILED` and Wrong-Stuff routing behavior.
|
|
191
|
+
|
|
192
|
+
## Troubleshooting
|
|
193
|
+
|
|
194
|
+
- If evidence is insufficient, log the gap explicitly and keep the candidate unconfirmed.
|
|
195
|
+
- If a manual-review gate has no supporting artifact failure, treat it as a candidate to disprove, not an automatic blocker.
|
|
196
|
+
- If `STATUS.md`, `EVIDENCE_LOG.md`, and `HANDOFF.json` disagree, record the contradiction and escalate only if it survives adjudication.
|
|
@@ -73,6 +73,10 @@ System: ACE v7.1 — Venture, UX, and Engineering swarms coordinated by a single
|
|
|
73
73
|
- Copy and UI strings that match the thesis and flows
|
|
74
74
|
- Tests and build status that prove the implementation
|
|
75
75
|
|
|
76
|
+
6. Swarm hierarchy is not optional
|
|
77
|
+
Top-level ingress stays locked to four primary agents: ACE-Orchestrator, ACE-VOS, ACE-UI, and ACE-Coders.
|
|
78
|
+
Composable agents are subordinate specialists used through those primaries, unless an operator explicitly invokes a bounded specialist task.
|
|
79
|
+
|
|
76
80
|
---
|
|
77
81
|
|
|
78
82
|
|
|
@@ -153,12 +157,19 @@ When any gate or invariant fails:
|
|
|
153
157
|
### 2.2 Subagent Strategy
|
|
154
158
|
|
|
155
159
|
- The Orchestrator delegates deep work to ACE‑VOS, ACE‑UI, and ACE‑Coders, one focused task at a time.
|
|
160
|
+
- Composable agents do not replace the swarm layer. They are attached under the active primary swarm agent for bounded work such as research, gating, build, QA, docs, memory, security, observability, eval, or release review.
|
|
156
161
|
- Typical sequences:
|
|
157
162
|
- **Genesis:** VOS → UI → Coders (zero‑to‑one features)
|
|
158
163
|
- **Pivot:** VOS → Orchestrator → Coders (unit‑economics changes and refactors)
|
|
159
164
|
- **Polish:** UI → Coders → Coders (Mercer critique, implementation, regression)
|
|
160
165
|
- Each delegation is accompanied by a structured handoff object.
|
|
161
166
|
|
|
167
|
+
### 2.2.1 Non-Regression Hierarchy Lock
|
|
168
|
+
|
|
169
|
+
- New work should route first to one of the four swarm agents, not directly to a composable agent.
|
|
170
|
+
- Composable agents may be invoked directly only for explicit operator-targeted bounded tasks or within an already-active swarm workstream.
|
|
171
|
+
- If routing output ever promotes a composable agent as a peer top-level owner for general work, treat that as a regression.
|
|
172
|
+
|
|
162
173
|
### 2.3 Self‑Improvement Loop
|
|
163
174
|
|
|
164
175
|
- After any correction or surprise, the responsible agent appends a short lesson to its logs or decision records.
|
|
@@ -20,6 +20,22 @@ executor:
|
|
|
20
20
|
turn_timeout_ms: 300000
|
|
21
21
|
tools:
|
|
22
22
|
registry_path: "agent-state/runtime-tool-specs.json"
|
|
23
|
+
autonomy:
|
|
24
|
+
orchestrator_preflight: true
|
|
25
|
+
recall_context: true
|
|
26
|
+
state_sources: ["agent-state/TASK.md", "agent-state/SCOPE.md", "agent-state/QUALITY_GATES.md", "agent-state/STATUS.md", "agent-state/HANDOFF.json", "agent-state/EVIDENCE_LOG.md"]
|
|
27
|
+
before_run_checks: []
|
|
28
|
+
stop_checks: []
|
|
29
|
+
review_mode: null
|
|
30
|
+
continuity:
|
|
31
|
+
enabled: true
|
|
32
|
+
source_paths: ["agent-state/TASK.md", "agent-state/SCOPE.md", "agent-state/QUALITY_GATES.md", "agent-state/HANDOFF.json", "agent-state/STATUS.md", "agent-state/DECISIONS.md", "agent-state/RISKS.md", "agent-state/EVIDENCE_LOG.md"]
|
|
33
|
+
max_sources: 6
|
|
34
|
+
max_excerpt_chars: 450
|
|
35
|
+
max_total_chars: 2600
|
|
36
|
+
max_status_events: 6
|
|
37
|
+
max_run_ledger_entries: 4
|
|
38
|
+
include_snapshot: true
|
|
23
39
|
tracker:
|
|
24
40
|
kind: "none"
|
|
25
41
|
config: {}
|
|
@@ -35,6 +51,11 @@ observability:
|
|
|
35
51
|
|
|
36
52
|
Operate under ACE runtime profile `{{runtime.profile_name}}` in `{{runtime.mode}}` mode.
|
|
37
53
|
|
|
54
|
+
## Runtime Intent
|
|
55
|
+
- Use this profile for ACE execution that must stay aligned to file-backed state and managed workspace policy.
|
|
56
|
+
- Treat front matter as execution policy. If a field is `null`, `false`, or empty, do not invent extra runtime machinery.
|
|
57
|
+
- Preserve objective, boundary, evidence, and transition truth inside ACE artifacts rather than chat-local memory.
|
|
58
|
+
|
|
38
59
|
## Task
|
|
39
60
|
{{task}}
|
|
40
61
|
|
|
@@ -52,6 +73,45 @@ Operate under ACE runtime profile `{{runtime.profile_name}}` in `{{runtime.mode}
|
|
|
52
73
|
## Runtime Tools
|
|
53
74
|
- Registry: `{{tools.registry_path}}`
|
|
54
75
|
|
|
76
|
+
## Autonomy
|
|
77
|
+
- Orchestrator preflight: `{{autonomy.orchestrator_preflight}}`
|
|
78
|
+
- Recall context: `{{autonomy.recall_context}}`
|
|
79
|
+
- State sources: `{{autonomy.state_sources}}`
|
|
80
|
+
- Before-run checks: `{{autonomy.before_run_checks}}`
|
|
81
|
+
- Stop checks: `{{autonomy.stop_checks}}`
|
|
82
|
+
- Review mode: `{{autonomy.review_mode}}`
|
|
83
|
+
|
|
84
|
+
## Autonomy Guidance
|
|
85
|
+
- `orchestrator_preflight` means validate ACE truth before substantial work or delegation.
|
|
86
|
+
- `recall_context` means prefer current task, status, handoff, and evidence state over stale thread assumptions.
|
|
87
|
+
- `before_run_checks` are blocking checks. If they fail, stop and surface the failure through ACE evidence and status channels.
|
|
88
|
+
- `stop_checks` are terminal or handoff checks. If they fail, do not continue optimistically.
|
|
89
|
+
- `review_mode` must stay inside existing ACE tools and artifacts; it is an overlay, not a second subsystem.
|
|
90
|
+
|
|
91
|
+
## Continuity
|
|
92
|
+
- Enabled: `{{continuity.enabled}}`
|
|
93
|
+
- Source paths: `{{continuity.source_paths}}`
|
|
94
|
+
- Max sources: `{{continuity.max_sources}}`
|
|
95
|
+
- Max excerpt chars: `{{continuity.max_excerpt_chars}}`
|
|
96
|
+
- Max total chars: `{{continuity.max_total_chars}}`
|
|
97
|
+
- Max status events: `{{continuity.max_status_events}}`
|
|
98
|
+
- Max run-ledger entries: `{{continuity.max_run_ledger_entries}}`
|
|
99
|
+
- Include snapshot: `{{continuity.include_snapshot}}`
|
|
100
|
+
|
|
101
|
+
## Continuity Guidance
|
|
102
|
+
- Continuity packets are derived from current ACE truth; they are not a replacement source of truth.
|
|
103
|
+
- Treat the configured budgets as source-side compaction rules for unattended execution and delegation, including recent status and run-ledger visibility.
|
|
104
|
+
- If continuity is disabled, do not synthesize a replacement packet in chat or hidden state.
|
|
105
|
+
|
|
106
|
+
## ACE Recall
|
|
107
|
+
{{ace_state_recall_md}}
|
|
108
|
+
|
|
109
|
+
## Context Snapshot
|
|
110
|
+
{{ace_context_snapshot_md}}
|
|
111
|
+
|
|
112
|
+
## Continuity Packet
|
|
113
|
+
{{ace_continuity_packet_md}}
|
|
114
|
+
|
|
55
115
|
## Tracker
|
|
56
116
|
- Kind: `{{tracker.kind}}`
|
|
57
117
|
|
|
@@ -64,3 +124,8 @@ Operate under ACE runtime profile `{{runtime.profile_name}}` in `{{runtime.mode}
|
|
|
64
124
|
- Preserve ACE state artifacts as the durable source of truth.
|
|
65
125
|
- Treat Vericify as an optional sidecar, not a required ACE runtime dependency.
|
|
66
126
|
- Treat this template as additive execution guidance for future unattended flows.
|
|
127
|
+
|
|
128
|
+
## Failure Handling
|
|
129
|
+
- When the task contract, evidence, or hooks are contradictory, prefer hold/escalation over optimistic continuation.
|
|
130
|
+
- Record blockers in ACE artifacts with owners and evidence refs before handing off or stopping.
|
|
131
|
+
- If the profile is missing capabilities, keep the gap explicit rather than silently broadening the runtime contract.
|
|
@@ -19,6 +19,7 @@
|
|
|
19
19
|
- `ACE_WORKFLOW.md` is the canonical workspace runtime profile artifact.
|
|
20
20
|
- Its YAML front matter must validate against `MODULES/schemas/ACE_RUNTIME_PROFILE.schema.json`.
|
|
21
21
|
- The markdown body after the closing front matter boundary is the active runtime prompt template.
|
|
22
|
+
- The optional `continuity` block only budgets derived packet content; it must not redefine canonical ACE truth outside the existing state artifacts and sidecar-native stores.
|
|
22
23
|
|
|
23
24
|
## Workspace Session Contract
|
|
24
25
|
|
|
@@ -148,6 +148,85 @@
|
|
|
148
148
|
}
|
|
149
149
|
}
|
|
150
150
|
},
|
|
151
|
+
"autonomy": {
|
|
152
|
+
"type": "object",
|
|
153
|
+
"additionalProperties": false,
|
|
154
|
+
"properties": {
|
|
155
|
+
"orchestrator_preflight": {
|
|
156
|
+
"type": "boolean"
|
|
157
|
+
},
|
|
158
|
+
"recall_context": {
|
|
159
|
+
"type": "boolean"
|
|
160
|
+
},
|
|
161
|
+
"state_sources": {
|
|
162
|
+
"type": "array",
|
|
163
|
+
"items": {
|
|
164
|
+
"type": "string",
|
|
165
|
+
"minLength": 1
|
|
166
|
+
}
|
|
167
|
+
},
|
|
168
|
+
"before_run_checks": {
|
|
169
|
+
"type": "array",
|
|
170
|
+
"items": {
|
|
171
|
+
"type": "string",
|
|
172
|
+
"minLength": 1
|
|
173
|
+
}
|
|
174
|
+
},
|
|
175
|
+
"stop_checks": {
|
|
176
|
+
"type": "array",
|
|
177
|
+
"items": {
|
|
178
|
+
"type": "string",
|
|
179
|
+
"minLength": 1
|
|
180
|
+
}
|
|
181
|
+
},
|
|
182
|
+
"review_mode": {
|
|
183
|
+
"type": [
|
|
184
|
+
"string",
|
|
185
|
+
"null"
|
|
186
|
+
],
|
|
187
|
+
"minLength": 1
|
|
188
|
+
}
|
|
189
|
+
}
|
|
190
|
+
},
|
|
191
|
+
"continuity": {
|
|
192
|
+
"type": "object",
|
|
193
|
+
"additionalProperties": false,
|
|
194
|
+
"properties": {
|
|
195
|
+
"enabled": {
|
|
196
|
+
"type": "boolean"
|
|
197
|
+
},
|
|
198
|
+
"source_paths": {
|
|
199
|
+
"type": "array",
|
|
200
|
+
"items": {
|
|
201
|
+
"type": "string",
|
|
202
|
+
"minLength": 1
|
|
203
|
+
}
|
|
204
|
+
},
|
|
205
|
+
"max_sources": {
|
|
206
|
+
"type": "integer",
|
|
207
|
+
"minimum": 1
|
|
208
|
+
},
|
|
209
|
+
"max_excerpt_chars": {
|
|
210
|
+
"type": "integer",
|
|
211
|
+
"minimum": 1
|
|
212
|
+
},
|
|
213
|
+
"max_total_chars": {
|
|
214
|
+
"type": "integer",
|
|
215
|
+
"minimum": 1
|
|
216
|
+
},
|
|
217
|
+
"max_status_events": {
|
|
218
|
+
"type": "integer",
|
|
219
|
+
"minimum": 1
|
|
220
|
+
},
|
|
221
|
+
"max_run_ledger_entries": {
|
|
222
|
+
"type": "integer",
|
|
223
|
+
"minimum": 1
|
|
224
|
+
},
|
|
225
|
+
"include_snapshot": {
|
|
226
|
+
"type": "boolean"
|
|
227
|
+
}
|
|
228
|
+
}
|
|
229
|
+
},
|
|
151
230
|
"tracker": {
|
|
152
231
|
"type": "object",
|
|
153
232
|
"additionalProperties": false,
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
#!/usr/bin/env node
|
|
2
2
|
|
|
3
|
-
import { existsSync } from "node:fs";
|
|
3
|
+
import { existsSync, readFileSync } from "node:fs";
|
|
4
4
|
import { resolve } from "node:path";
|
|
5
5
|
|
|
6
6
|
const DESTRUCTIVE_COMMAND_PATTERNS = [
|
|
@@ -82,6 +82,40 @@ function aceContext(workspaceRoot) {
|
|
|
82
82
|
};
|
|
83
83
|
}
|
|
84
84
|
|
|
85
|
+
function readAutonomyHint(workspaceRoot) {
|
|
86
|
+
const workflowPath = resolve(workspaceRoot, "agent-state", "ACE_WORKFLOW.md");
|
|
87
|
+
const defaultHint =
|
|
88
|
+
"Runtime autonomy defaults are active: orchestrator preflight, context recall.";
|
|
89
|
+
if (!existsSync(workflowPath)) return defaultHint;
|
|
90
|
+
|
|
91
|
+
let raw = "";
|
|
92
|
+
try {
|
|
93
|
+
raw = readFileSync(workflowPath, "utf8");
|
|
94
|
+
} catch {
|
|
95
|
+
return defaultHint;
|
|
96
|
+
}
|
|
97
|
+
|
|
98
|
+
if (!/^\s*autonomy:\s*$/m.test(raw)) {
|
|
99
|
+
return defaultHint;
|
|
100
|
+
}
|
|
101
|
+
|
|
102
|
+
const signals = [];
|
|
103
|
+
if (/^\s*autonomy:\s*$/m.test(raw) && /^\s*orchestrator_preflight:\s*true\s*$/m.test(raw)) {
|
|
104
|
+
signals.push("orchestrator preflight");
|
|
105
|
+
}
|
|
106
|
+
if (/^\s*autonomy:\s*$/m.test(raw) && /^\s*recall_context:\s*true\s*$/m.test(raw)) {
|
|
107
|
+
signals.push("context recall");
|
|
108
|
+
}
|
|
109
|
+
const reviewMode = raw.match(/^\s*review_mode:\s*["']?([A-Za-z0-9_-]+)["']?\s*$/m)?.[1];
|
|
110
|
+
if (reviewMode) {
|
|
111
|
+
signals.push(`review mode ${reviewMode}`);
|
|
112
|
+
}
|
|
113
|
+
|
|
114
|
+
return signals.length > 0
|
|
115
|
+
? `Runtime autonomy policy is active in agent-state/ACE_WORKFLOW.md: ${signals.join(", ")}.`
|
|
116
|
+
: "";
|
|
117
|
+
}
|
|
118
|
+
|
|
85
119
|
function buildAceMessage(workspaceRoot) {
|
|
86
120
|
const context = aceContext(workspaceRoot);
|
|
87
121
|
if (!context.hasAgentState && !context.hasSkills) return "";
|
|
@@ -103,6 +137,10 @@ function buildAceMessage(workspaceRoot) {
|
|
|
103
137
|
if (context.hasSkills) {
|
|
104
138
|
parts.push("Workspace skills are available under .agents/skills/.");
|
|
105
139
|
}
|
|
140
|
+
const autonomyHint = readAutonomyHint(workspaceRoot);
|
|
141
|
+
if (autonomyHint) {
|
|
142
|
+
parts.push(autonomyHint);
|
|
143
|
+
}
|
|
106
144
|
parts.push(
|
|
107
145
|
"Copilot hook policy protects .github/hooks, .vscode/settings.json, and scripts/ace/copilot-hook-dispatch.mjs from silent self-modification."
|
|
108
146
|
);
|
package/assets/tasks/README.md
CHANGED
|
@@ -14,9 +14,35 @@ This directory contains shared execution artifacts consumed by ACE prompts, tool
|
|
|
14
14
|
- `agent-state/job-locks.json`: collision-free scheduler locks.
|
|
15
15
|
- `agent-state/scheduler-lease.json`: active scheduler lease ownership.
|
|
16
16
|
|
|
17
|
+
## When To Read This Directory
|
|
18
|
+
|
|
19
|
+
- Before starting non-trivial work that needs explicit task, role, or handoff structure.
|
|
20
|
+
- Before issuing or consuming a `SWARM_HANDOFF`.
|
|
21
|
+
- When recovering blocked or deferred work through the scheduler and TODO surfaces.
|
|
22
|
+
- When a repeated failure should become a durable lesson or guardrail.
|
|
23
|
+
|
|
24
|
+
## Common Workflows
|
|
25
|
+
|
|
26
|
+
1. Start work: check `todo.md`, then use `role_tasks.md` to confirm the bounded contract for the active role.
|
|
27
|
+
2. Route work: begin from `SWARM_HANDOFF.template.json`, then compare with the example payloads before publishing.
|
|
28
|
+
3. Recover work: inspect `agent-state/job-queue.json`, `agent-state/job-locks.json`, and `agent-state/scheduler-lease.json` together instead of in isolation.
|
|
29
|
+
4. Harden work: write repeatable failures to `lessons.md` so the same mistake does not re-enter the loop.
|
|
30
|
+
|
|
17
31
|
## Operating Rules
|
|
18
32
|
|
|
19
33
|
1. Update `todo.md` before non-trivial work and after verification.
|
|
20
34
|
2. Log every repeatable correction pattern in `lessons.md`.
|
|
21
35
|
3. Use `SWARM_HANDOFF.template.json` as the base for all routing payloads.
|
|
22
36
|
4. Keep acceptance criteria measurable and tied to file-based evidence.
|
|
37
|
+
|
|
38
|
+
## Validation Rules
|
|
39
|
+
|
|
40
|
+
- Handoffs must reference real artifacts, owners, and acceptance criteria.
|
|
41
|
+
- Scheduler state is advisory unless it matches current task and status artifacts.
|
|
42
|
+
- Lessons should capture a failure pattern, a guardrail, and a verification check, not just an anecdote.
|
|
43
|
+
|
|
44
|
+
## Common Failure Modes
|
|
45
|
+
|
|
46
|
+
- `todo.md` is stale while work has already moved; refresh it before trusting downstream routing.
|
|
47
|
+
- A handoff exists without evidence or acceptance criteria; treat it as incomplete, not merely “draft.”
|
|
48
|
+
- Scheduler files disagree with task or status truth; route the contradiction through ops instead of guessing which surface won.
|