@voybio/ace-swarm 0.1.0

package/assets/.agents/skills/memory-curator/SKILL.md

@@ -0,0 +1,179 @@
+---
+name: memory-curator
+description:
+  Reconcile evidence, decisions, and risks into durable memory artifacts. Use when agent-state is noisy, contradictory, stale, or needs compression before handoff.
+---
+
+# Memory Curator
+
+## Purpose
+
+Keep long-running autonomy state compact, accurate, and evidence-linked so agents reason from truth, not stale noise.
+Memory without curation is hoarding. Memory with curation is institutional knowledge.
+
+## Canonical Use Cases
+
+1. `EVIDENCE_LOG.md` and related state files are growing noisy and handoff context needs compression without losing provenance.
+2. Contradictory decisions, risks, or evidence claims must be reconciled before another routing or release pass.
+3. A long-running workspace needs a durable memory index so later agents do not repeat old analysis.
+
+---
+
+## MICE Boundaries
+
+| Rule | Enforcement |
+|---|---|
+| **Modular** | Summarizes and indexes; does NOT delete source logs or make scope decisions. |
+| **Interoperable** | Memory index entries follow canonical format below. |
+| **Customizable** | Staleness thresholds adapt to sprint cadence in `TEAL_CONFIG.md`. |
+| **Extensible** | New memory categories added via index schema, not prose. |
+
+---
+
+## MICE/TEAL Alignment
+
+- Modular memory maintenance with no contract mutation.
+- Preserves TEAL orchestration context by keeping dependency decisions evidence-linked.
+
+---
+
+## Trigger Conditions
+
+Use when:
+
+- `EVIDENCE_LOG.md` exceeds 200 entries or 50KB
+- contradictory assumptions appear across state files
+- repeated cycles re-state same claims without new evidence
+- pre-handoff context compression needed
+- post-incident knowledge consolidation
+
+---
+
+## Inputs
+
+- `agent-state/EVIDENCE_LOG.md`
+- `agent-state/DECISIONS.md`
+- `agent-state/RISKS.md`
+- `agent-state/HANDOFF_HISTORY/*.json`
+- `agent-state/STATUS_EVENTS.ndjson`
+
+---
+
+## Socratic Questions (Pre-Curation)
+
+- Which entries are still decision-relevant for the current objective?
+- Which assumptions were invalidated by later evidence?
+- Which repeated entries add no new information beyond the first occurrence?
+- Which decisions have been superseded but not marked as such?
+- Are there contradictions between `DECISIONS.md` and `EVIDENCE_LOG.md`?
+
+---
+
+## Curation Rules
+
+| Rule | Enforcement |
+|---|---|
+| **Append-Only Source** | NEVER delete or modify entries in `EVIDENCE_LOG.md`. Index only. |
+| **Provenance Preservation** | Every summary retains link to original entry timestamp. |
+| **Contradiction Flagging** | Contradictory claims get explicit `CONTRADICTION` marker with both refs. |
+| **Staleness Marking** | Entries older than 2 sprint windows with no downstream reference are marked `STALE`. |
+| **Deduplication** | Repeated claims with identical evidence are collapsed to single index entry with count. |
+| **Decision Lineage** | Superseded decisions linked to their replacement with reason. |
+
+---
+
+## Memory Index Entry Schema
+
+```markdown
+### MEM-<NNN>: <summary title>
+- **Category:** <decision | evidence | risk | assumption | contradiction>
+- **Status:** <active | stale | superseded | invalidated>
+- **Original Refs:** <EVIDENCE_LOG.md#ts:ISO8601>, <DECISIONS.md#section>
+- **Summary:** <1-2 sentence distillation>
+- **Superseded By:** <MEM-NNN or N/A>
+- **Contradiction With:** <MEM-NNN or N/A>
+- **Last Relevant:** <ISO8601 of last downstream reference>
+```
+
+---
+
+## Workflow — Mapped to Clarity Protocol
+
+### `[STATE_ANALYSIS]`
+1. Measure current state file sizes and entry counts.
+2. Identify compression opportunity (entries without downstream references).
+3. Scan for contradictions across `DECISIONS.md`, `RISKS.md`, `EVIDENCE_LOG.md`.
+
+### `[STRATEGY_SELECTOR]`
+4. Choose curation scope:
+   - Full curation: all source files, all time windows.
+   - Delta curation: only entries since last `MEMORY_INDEX.md` update.
+   - Contradiction-only: scan for and flag contradictions without full indexing.
+5. Plan processing order: contradictions first, then dedup, then staleness.
+
+### `[EXECUTION_LOG]`
+6. Cluster entries by objective and time window.
+7. Detect and flag contradictions with dual-reference markers.
+8. Deduplicate repeated statements with no new references.
+9. Mark entries older than staleness threshold with no downstream ref as `STALE`.
+10. Link superseded decisions to their replacements.
+11. Preserve provenance links for all retained summaries.
+
+### `[ARTIFACT_UPDATE]`
+12. Write `agent-state/MEMORY_INDEX.md` with all indexed entries.
+13. Write `agent-state/MEMORY_RECONCILIATION.md`:
+
+```markdown
+# Memory Reconciliation Report
+Generated: <ISO8601>
+
+## Statistics
+| Metric | Value |
+|---|---|
+| Total source entries scanned | <n> |
+| Active entries indexed | <n> |
+| Stale entries marked | <n> |
+| Contradictions flagged | <n> |
+| Duplicates collapsed | <n> |
+| Superseded decisions | <n> |
+
+## Contradictions Found
+- MEM-<NNN> vs MEM-<NNN>: <description>
+
+## Recommended Actions
+- <action with owner and evidence ref>
+```
+
+14. Append curation evidence to `EVIDENCE_LOG.md`.
+
+### `[VERIFICATION]`
+15. No source log entries were deleted or modified.
+16. Every index entry has provenance link to original.
+17. All contradictions have dual-reference markers.
+18. Reconciliation report statistics are mathematically consistent.
+
+---
+
+## Output Contract
+
+- `agent-state/MEMORY_INDEX.md` (compact, categorized, contradiction-aware)
+- `agent-state/MEMORY_RECONCILIATION.md` (statistics, contradictions, recommended actions)
+
+---
+
+## Anti-Patterns
+
+| Anti-Pattern | Correct Behavior |
+|---|---|
+| Deleting old evidence entries | Mark as STALE in index; source is append-only |
+| Summarizing without provenance link | Every summary must link to original timestamp |
+| Ignoring contradictions | Flag explicitly with both refs; do not silently pick one |
+| Curating during active incident | Wait for incident closure; active state is volatile |
+| Marking everything as active | Apply staleness threshold ruthlessly |
+
+---
+
+## Failure Policy
+
+Do not remove or rewrite source logs; only summarize with pointers. `EVIDENCE_LOG.md` remains append-only.
+If contradictions cannot be resolved from available evidence, emit `FIX_REQUIRED` routed to the owning agent for clarification.

package/assets/.agents/skills/problem-triage/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: problem-triage
+description: 
+  Classify a new request as one of: existing skill fits, existing skill needs patching, new skill warranted, missing tool or permission, or one-off task. Use when the user asks whether something should become a skill, how to route a skill-system request, or what the right next building block is.
+---
+
+# Problem Triage
+
+Use this skill before creating or patching ACE skills. Its job is to stop duplicate or premature skill creation by turning a vague request into a concrete route decision.
+
+## Canonical Use Cases
+
+1. A user asks whether a repeated workflow deserves a new skill.
+2. A request overlaps an existing skill, but the current skill may need metadata, structure, or validation fixes.
+3. The real blocker is missing tooling, permissions, or runtime setup rather than the absence of a skill.
+
+## Inputs
+
+- The raw user request or workflow description.
+- The current skill catalog, including discoverable workspace and package-default skills.
+- Any visible blockers such as missing MCP servers, approvals, credentials, or network access.
+
+## Workflow
+
+1. Read the request for reusable-workflow signals, patch signals, and blocker signals.
+2. Compare the request against existing skill names, descriptions, and headings.
+3. Classify the request into exactly one route:
+   - existing skill fits
+   - existing skill needs patching
+   - new skill warranted
+   - missing tool or permission
+   - one-off task
+4. Write `agent-state/PROBLEM_TRIAGE.md` with confidence, rationale, top matches, and next steps.
+
+## Outputs
+
+- `agent-state/PROBLEM_TRIAGE.md`
+- A route decision with confidence, rationale, and top skill matches
+- Suggested next steps for the next ACE module or skill-building pass
+
+## Validation
+
+- Run the `problem_triage` MCP tool with a known request and verify that it writes `agent-state/PROBLEM_TRIAGE.md`.
+- Verify that requests mentioning client overlays or portability do not require `agents/openai.yaml` to classify correctly.
+- Check that repeated-workflow requests route to either `existing skill needs patching` or `new skill warranted`, never silently to one-off when reusable signals are strong.
+
+## Compatibility
+
+- `SKILL.md` is the canonical portable source of truth.
+- Any files under `agents/` are optional client overlays only and must not redefine the core route semantics.
+- The skill should remain understandable and executable in Claude, Cursor, Codex, Antigravity, and similar environments even when no adapter file exists.
+
+## Failure Policy
+
+- If catalog evidence is weak or ambiguous, lower confidence and surface the ambiguity explicitly.
+- If a tool, permission, or credential blocker is present, route to `missing tool or permission` instead of recommending skill creation.
+- Do not create a new skill when an existing skill can be patched to cover the request.

package/assets/.agents/skills/problem-triage/agents/openai.yaml

@@ -0,0 +1,3 @@
+display_name: "Problem Triage"
+short_description: "Classify whether a request fits, patches, or warrants a skill."
+default_prompt: "Use the problem-triage skill to classify this request and write agent-state/PROBLEM_TRIAGE.md."

package/assets/.agents/skills/release-sentry/SKILL.md

@@ -0,0 +1,189 @@
+---
+name: release-sentry
+description:
+  Promotion gatekeeper skill ensuring release readiness, rollback viability, and provenance completeness.
+---
+
+# Release Sentry
+
+## Purpose
+
+Make release decisions explicit, reversible, and evidence-backed.
+No artifact moves toward users without a deterministic gate pass.
+
+## Canonical Use Cases
+
+1. A verified build is being considered for release-candidate or production promotion.
+2. The team needs a hold/approve decision with rollback readiness and provenance evidence explicitly documented.
+3. Releases are resuming after an incident and someone must verify gate completeness before land or production movement.
+
+---
+
+## MICE Boundaries
+
+| Rule | Enforcement |
+|---|---|
+| **Modular** | Gates promotion decisions; does NOT build, test, or deploy artifacts. |
+| **Interoperable** | Decision payloads conform to `RELEASE_DECISION.schema.json` if present. |
+| **Customizable** | Gate checklist adapts to `TEAL_CONFIG.md` pipeline stage. |
+| **Extensible** | New gate checks are added as checklist rows, not ad-hoc prose. |
+
+---
+
+## MICE/TEAL Alignment
+
+- Modular promotion gate independent from build implementation details.
+- TEAL-aware release checks ensure all upstream dependencies and sidecar gates are satisfied.
+
+---
+
+## Trigger Conditions
+
+Use when:
+
+- moving from verified artifacts to release candidate
+- approving production promotion
+- evaluating rollback readiness
+- any handoff contains `release_candidate: true`
+- post-incident re-verification before resuming releases
+
+---
+
+## Inputs
+
+- `agent-state/EVAL_REPORT.md`
+- `agent-state/VERIFICATION_REPORT.md`
+- `agent-state/ARTIFACT_MANIFEST.json`
+- `agent-state/PROVENANCE_LOG.md`
+- `agent-state/RISKS.md` (current risk scorecard)
+- `agent-state/QUALITY_GATES.md`
+- security/observability summaries (if present)
+
+---
+
+## Release Gate Checklist
+
+Every promotion decision requires ALL rows to pass:
+
+| # | Gate | Pass Criteria | Fail Action |
+|---|---|---|---|
+| 1 | **Quality Gates** | All gates in `QUALITY_GATES.md` status = `PASSED` | Block; route to `agent-qa` |
+| 2 | **Verification Report** | `VERIFICATION_REPORT.md` exists, current, no open failures | Block; route to `agent-qa` |
+| 3 | **Eval Regression** | `EVAL_REPORT.md` shows no regression vs. baseline | Block; route to `agent-qa` |
+| 4 | **Provenance Chain** | Every artifact in manifest has provenance entry with checksum | Block; route to `agent-builder` |
+| 5 | **Risk Scorecard** | No CRITICAL/HIGH risks with status = `open` | Block; route to `risk-quant` |
+| 6 | **Spec Alignment** | Artifacts satisfy `SPEC_CONTRACT.json` requirements | Block; route to `agent-spec` |
+| 7 | **Rollback Runbook** | `ROLLBACK_RUNBOOK.md` exists and references specific revert steps | Block; create runbook |
+| 8 | **Documentation** | Release notes / changelog entry exists | Block; route to `agent-docs` |
+
+---
+
+## Promotion Decision Matrix
+
+| All Gates Pass | Risk Posture | Decision | Action |
+|---|---|---|---|
+| YES | No HIGH/CRITICAL open | `APPROVE` | Emit `RELEASE_APPROVED` event; update `STATUS.md` |
+| YES | MEDIUM risks accepted | `APPROVE_WITH_RISK` | Emit event with accepted risk references |
+| NO | Any gate failed | `HOLD` | Emit `GATE_FAILED`; route to failing gate owner |
+| N/A | Active incident | `ROLLBACK` | Trigger rollback runbook; emit `RELEASE_ROLLED_BACK` |
+
+---
+
+## Rollback Readiness Checklist
+
+| # | Check | Requirement |
+|---|---|---|
+| 1 | Revert mechanism | Specific command/process documented in `ROLLBACK_RUNBOOK.md` |
+| 2 | Data migration | Backward-compatible or rollback migration exists |
+| 3 | Dependency lock | All dependency versions pinned and restorable |
+| 4 | Verification | Post-rollback verification steps defined |
+| 5 | Communication | Stakeholder notification plan documented |
+
+---
+
+## Workflow — Mapped to Clarity Protocol
+
+### `[STATE_ANALYSIS]`
+1. Read all input artifacts. Determine which gates have evidence and which are missing.
+2. Check `STATUS.md` for current pipeline phase and active role.
+
+### `[STRATEGY_SELECTOR]`
+3. Walk the Release Gate Checklist top-to-bottom.
+4. For each gate, determine: pass / fail / missing-evidence.
+5. If any gate fails, plan routing to the responsible owner.
+
+### `[EXECUTION_LOG]`
+6. Execute each gate check against actual artifacts.
+7. Validate provenance checksums against manifest.
+8. Verify rollback runbook completeness.
+9. Check risk scorecard for open HIGH/CRITICAL entries.
+
+### `[ARTIFACT_UPDATE]`
+10. Write `agent-state/RELEASE_DECISION.md`:
+
+```markdown
+# Release Decision
+Generated: <ISO8601>
+Decision: <APPROVE | APPROVE_WITH_RISK | HOLD | ROLLBACK>
+Reason: <one sentence>
+
+## Gate Results
+| Gate | Status | Evidence |
+|---|---|---|
+| Quality Gates | PASS/FAIL | <ref> |
+| Verification | PASS/FAIL | <ref> |
+| ... | ... | ... |
+
+## Accepted Risks (if APPROVE_WITH_RISK)
+- RISK-<NNN>: <title> — accepted because <reason>
+
+## Required Actions (if HOLD)
+- <gate> → <owner> — <what must happen>
+```
+
+11. Verify or create `agent-state/ROLLBACK_RUNBOOK.md`.
+12. Append evidence anchor to `EVIDENCE_LOG.md`.
+
+### `[VERIFICATION]`
+13. Decision is one of exactly 4 values: `APPROVE`, `APPROVE_WITH_RISK`, `HOLD`, `ROLLBACK`.
+14. Every gate has explicit pass/fail with evidence reference.
+15. HOLD decisions include owner routing for every failed gate.
+16. Rollback runbook exists and has all 5 checklist items.
+
+---
+
+## Output Contract
+
+- `agent-state/RELEASE_DECISION.md`
+- `agent-state/ROLLBACK_RUNBOOK.md` (created or verified)
+- event emission: `RELEASE_APPROVED` or `GATE_FAILED` or `RELEASE_ROLLED_BACK`
+
+---
+
+## Anti-Patterns
+
+| Anti-Pattern | Correct Behavior |
+|---|---|
+| "LGTM, ship it" | Walk every gate row; document pass/fail |
+| Approving with open CRITICAL risk | HOLD until risk is mitigated or accepted with evidence |
+| Rollback plan = "revert the commit" | Runbook must cover data, deps, verification, communication |
+| Skipping provenance check | Every artifact needs checksum + builder provenance |
+
+---
+
+## Wrong-Stuff Protocol
+
+| Finding | Classification | Route To |
+|---|---|---|
+| Verification report missing/stale | `verification_gap` | `agent-qa` |
+| Provenance chain broken | `implementation_bug` | `agent-builder` |
+| Spec not satisfied | `spec_violation` | `agent-spec` |
+| Docs missing | `documentation_drift` | `agent-docs` |
+| Risk scorecard has open CRITICAL | `unresolved_risk` | `risk-quant` then owner |
+
+---
+
+## Failure Policy
+
+Block promotion when any required gate is missing, stale, or unresolved.
+No "soft approvals" — every promotion decision is documented with gate evidence and is reversible via the rollback runbook.

package/assets/.agents/skills/risk-quant/SKILL.md

@@ -0,0 +1,190 @@
+---
+name: risk-quant
+description:
+  Score and prioritize execution risks with owners, mitigations, and verification conditions. Use when new blockers appear, release risk must be assessed, or handoffs reference unscored risk.
+---
+
+# Risk Quant
+
+## Purpose
+
+Convert vague risks into measurable, owner-linked mitigation plans that can gate execution.
+Risk without quantification is anxiety. Risk with quantification is engineering.
+
+## Canonical Use Cases
+
+1. A new blocker, architecture change, or dependency cascade appears and needs immediate scoring plus ownership.
+2. A release or handoff decision references risk, but the risk is still qualitative or incomplete.
+3. A mitigation plan exists and someone needs to verify whether it actually lowers gate-blocking risk.
+
+---
+
+## MICE Boundaries
+
+| Rule | Enforcement |
+|---|---|
+| **Modular** | Scores risks; does NOT implement mitigations or change scope. |
+| **Interoperable** | Risk entries follow the canonical Risk Entry Schema below. |
+| **Customizable** | Reads `TEAL_CONFIG.md` for pipeline stage and criticality weights. |
+| **Extensible** | New risk categories added via schema extension, not ad-hoc fields. |
+
+---
+
+## MICE/TEAL Alignment
+
+- Modular risk scoring layer used by skeptic/ops/qa without coupling to implementation details.
+- TEAL-aware prioritization uses pipeline stage and dependency criticality.
+
+---
+
+## Trigger Conditions
+
+Use when:
+
+- architecture or scope changes
+- blocker cascades emerge
+- release readiness is being assessed
+- any gate decision references unquantified risk
+- handoff payload contains `risks_unscored: true`
+
+---
+
+## Inputs
+
+- `agent-state/RISKS.md`
+- `agent-state/DECISIONS.md`
+- `agent-state/STATUS.md`
+- current handoff payloads
+- `agent-state/EVIDENCE_LOG.md` (for historical risk resolution evidence)
+
+---
+
+## Probability-Impact Scoring Matrix
+
+### Probability Scale
+
+| Score | Label | Definition |
+|---|---|---|
+| 1 | Rare | < 10% chance in current sprint window |
+| 2 | Unlikely | 10–30% chance |
+| 3 | Possible | 30–60% chance |
+| 4 | Likely | 60–85% chance |
+| 5 | Near-Certain | > 85% chance or already manifesting |
+
+### Impact Scale
+
+| Score | Label | Definition |
+|---|---|---|
+| 1 | Negligible | No schedule/scope effect; cosmetic only |
+| 2 | Minor | < 1 day delay or single-module rework |
+| 3 | Moderate | 1–3 day delay or multi-module rework |
+| 4 | Significant | Sprint-level delay or architecture change required |
+| 5 | Critical | Objective failure, thesis invalidation, or data loss |
+
+### Priority Tier Computation
+
+```
+priority_score = probability x impact
+```
+
+| Score Range | Tier | Mitigation SLA | Gate Effect |
+|---|---|---|---|
+| 1–4 | `LOW` | Address within current sprint | Informational only |
+| 5–9 | `MEDIUM` | Mitigation plan required before next handoff | Warning flag |
+| 10–15 | `HIGH` | Owner + mitigation + verification required NOW | Blocks downstream |
+| 16–25 | `CRITICAL` | Immediate circuit breaker; escalate to ops | Hard gate block |
+
+---
+
+## Canonical Risk Entry Schema
+
+Every risk in `RISKS.md` must contain these fields:
+
+```markdown
+### RISK-<NNN>: <title>
+- **Cause:** <what produces this risk>
+- **Effect:** <what happens if it manifests>
+- **Detection Signal:** <how we know it is manifesting>
+- **Probability:** <1-5> (<label>)
+- **Impact:** <1-5> (<label>)
+- **Priority:** <score> / <tier>
+- **Owner:** <agent-role>
+- **Mitigation:** <specific action, not "be careful">
+- **Verification Condition:** <falsifiable test that mitigation worked>
+- **Status:** <open | mitigating | mitigated | accepted | closed>
+- **Evidence Ref:** <EVIDENCE_LOG.md#ts:ISO8601>
+```
+
+---
+
+## Workflow — Mapped to Clarity Protocol
+
+### `[STATE_ANALYSIS]`
+1. Read `RISKS.md` — identify entries missing scores, owners, or mitigations.
+2. Read `DECISIONS.md` — surface any scope changes that create new risk.
+3. Read `STATUS.md` — determine current pipeline stage for criticality weights.
+
+### `[STRATEGY_SELECTOR]`
+4. For each risk entry, determine scoring approach:
+   - Previously scored but stale → re-score with updated evidence.
+   - Unscored → full scoring pass.
+   - Scored and current → skip (no busywork).
+5. Plan scoring order: CRITICAL-suspected first, LOW-suspected last.
+
+### `[EXECUTION_LOG]`
+6. Normalize each risk entry to canonical schema (cause, effect, detection signal).
+7. Assign `probability` and `impact` scores using scales above.
+8. Compute priority tier and mitigation SLA.
+9. For HIGH/CRITICAL: require owner, specific mitigation, and falsifiable verification condition. If missing, emit `FIX_REQUIRED`.
+10. For CRITICAL: check if circuit breaker should be triggered. If yes, emit event to ops.
+
+### `[ARTIFACT_UPDATE]`
+11. Write updated `agent-state/RISKS.md` with scored entries.
+12. Generate `agent-state/RISK_SCORECARD.md` with summary table, top risks, gate implications, and mitigation quality audit.
+13. Append evidence anchor to `EVIDENCE_LOG.md`.
+
+### `[VERIFICATION]`
+14. Every HIGH/CRITICAL risk has owner + mitigation + verification condition.
+15. No risk entry uses vague mitigation ("be careful", "monitor", "TBD").
+16. Priority scores are mathematically consistent with scales.
+17. Scorecard gate implications match actual gate state.
+
+---
+
+## Output Contract
+
+- updated `agent-state/RISKS.md` (all entries in canonical schema)
+- `agent-state/RISK_SCORECARD.md` (summary, top risks, gate implications, mitigation quality)
+
+---
+
+## Anti-Patterns
+
+| Anti-Pattern | Correct Behavior |
+|---|---|
+| "Risk: things might break" | Specify cause, effect, detection signal |
+| Mitigation = "be careful" | Mitigation = specific action with verification condition |
+| All risks scored LOW | Re-examine; if nothing is risky, you are not looking hard enough |
+| Risk without owner | Every HIGH/CRITICAL risk has exactly one owner role |
+| Scoring without evidence | Probability must reference evidence, not gut feeling |
+
+---
+
+## Wrong-Stuff Protocol
+
+When scoring reveals issues:
+
+| Finding | Classification | Route To |
+|---|---|---|
+| Risk stems from unclear spec | `spec_violation` | `agent-spec` |
+| Risk stems from implementation gap | `implementation_bug` | `agent-builder` |
+| Risk stems from unvalidated assumption | `invalid_source` | `agent-research` |
+| Risk documentation is stale | `documentation_drift` | `agent-docs` |
+| Risk triggers circuit breaker | `blocker_storm` | `agent-ops` |
+
+---
+
+## Failure Policy
+
+Block completion when any critical/high risk lacks owner, mitigation, or verification condition.
+Emit `GATE_FAILED` with `failure_type: unquantified_risk` when risk entries resist scoring due to insufficient information — route to `agent-research` for evidence gathering.