synergyspec-selfevolving 1.3.0 → 2.0.0

package/dist/core/templates/skill-templates.js

@@ -22,4 +22,5 @@ export { getCiSkillTemplate, getOpsxCiCommandTemplate } from './workflows/ci.js'
 export { getOpsxProposeSkillTemplate, getOpsxProposeCommandTemplate } from './workflows/propose.js';
 export { getFeedbackSkillTemplate } from './workflows/feedback.js';
 export { getCompareImagesSkillTemplate } from './workflows/compare-images.js';
+export { getSelfEvolvingSkillTemplate } from './workflows/self-evolving.js';
 //# sourceMappingURL=skill-templates.js.map

package/dist/core/templates/workflow-manifest.js

@@ -18,6 +18,7 @@ import { getNewChangeSkillTemplate, getOpsxNewCommandTemplate, } from './workflo
 import { getOnboardSkillTemplate, getOpsxOnboardCommandTemplate, } from './workflows/onboard.js';
 import { getOpsxProposeCommandTemplate, getOpsxProposeSkillTemplate, } from './workflows/propose.js';
 import { getOpsxRunTestsCommandTemplate, getRunTestsSkillTemplate, } from './workflows/run-tests.js';
+import { getSelfEvolvingSkillTemplate } from './workflows/self-evolving.js';
 import { getOpsxSyncCommandTemplate, getSyncSpecsSkillTemplate, } from './workflows/sync-specs.js';
 import { getOpsxTddCommandTemplate, getTddSkillTemplate, } from './workflows/tdd.js';
 import { getOpsxVerifyCommandTemplate, getVerifyChangeSkillTemplate, } from './workflows/verify-change.js';
@@ -67,6 +68,7 @@ const WORKFLOW_MANIFEST = [
     workflow('run-tests', 'synergyspec-selfevolving-run-tests', getRunTestsSkillTemplate, getOpsxRunTestsCommandTemplate, ['workflow', 'test']),
     workflow('ci', 'synergyspec-selfevolving-ci', getCiSkillTemplate, getOpsxCiCommandTemplate, ['workflow', 'test', 'ci']),
     utility('synergyspec-selfevolving-compare-images', getCompareImagesSkillTemplate, ['utility', 'test']),
+    utility('synergyspec-selfevolving-self-evolving', getSelfEvolvingSkillTemplate, ['utility', 'learn', 'critic']),
 ];
 export function getWorkflowManifest() {
     return WORKFLOW_MANIFEST;

package/dist/core/templates/workflows/learn.d.ts

@@ -1,8 +1,10 @@
 /**
  * Skill Template Workflow Modules
  *
- * Learn workflow: review completed apply/verify evidence and produce
- * preview-first learning recommendations.
+ * Learn workflow: thin entrance to self-evolution — selects the change,
+ * spawns the fresh-context runner skill
+ * (synergyspec-selfevolving-self-evolving), which triggers ONE loop-v2
+ * self-evolution episode, and relays its verdict.
  */
 import type { SkillTemplate, CommandTemplate } from '../types.js';
 export declare function getLearnSkillTemplate(): SkillTemplate;

package/dist/core/templates/workflows/learn.js

@@ -2,20 +2,7 @@ const INSTRUCTIONS_BODY = `**Input**: Optionally specify a change name. If omitt
 
 **Purpose**
 
-This is the review-and-learn step after \`/synspec:apply\` and \`/synspec:verify\`, and it is the ENTRANCE to autonomous self-evolution. When you run this skill you invoke learn with \`--apply --yes\` (the bare \`learn\` CLI previews by default — writing nothing — for safety; the skill opts into evolution explicitly). That does two things: (1) summarize reusable lessons and consolidate memory, and (2) evolve the tool itself from those lessons — authoring and promoting a concrete improvement to a canonical prompt/template — WITHOUT asking for confirmation. You (the agent running this skill) are the proposer: you already hold the full change context, so you author the improved file yourself and the CLI validates → gates → promotes it onto the local installed file (no rebuild, no republish, no second agent, no \`claude -p\`).
-
-Preview-only is the bare-CLI default and the explicit opt-out: run \`synergyspec-selfevolving learn <change> --preview\` (or simply omit \`--apply\`) to analyze without evolving.
-
-**Default Mode: Autonomous self-evolution**
-
-- After reviewing the change, you DO the evolution. Do not stop at a report, and do not ask permission.
-- Safety is AUTOMATED, not human-gated: a canonical file is promoted ONLY when the change's test evidence is OBSERVED green (the CLI verifies the ACTUAL test run from the session trajectory, not just the authored \`test-report.md\`), the static gate passes, the target is evolvable under the per-target switch, and a rollback snapshot is taken.
-- When nothing canonical is written, CLASSIFY why before moving on — do not blanket-archive every no-op as "safety working":
-  - **(a) SAFE refusal (expected, not a bug):** evidence is missing or red, the target is frozen, or the static gate failed on real grounds. The floor refused to evolve on unverified / failing / out-of-scope edits. State the reason in the Evolution Result and move on.
-  - **(b) DEFECT (a tool bug to SURFACE, not archive over):** the evolution target STILL could not be BOUND after you named one concrete same-kind \`--evolve-target\` (a preview target with \`targetId: null\` / \`needsDisambiguation: true\`, or an \`evolution-target-unresolved\` observation, that PERSISTS post-naming), or promotion failed for a reason that is NOT about evidence / freezing / scope. A FIRST-pass \`evolution-target-unresolved\` observation (severity \`action\`) on an autonomous \`--apply\` run is NOT this — it only means the kind-only hint is AMBIGUOUS; pick ONE concrete id from its candidates, pass it with \`--evolve-target\`, and re-run (do NOT hand-edit a canonical file to work around it). For a genuine DEFECT, nothing was written because the CLI COULD NOT act — not because it correctly declined: surface it as an unresolved issue (keep an \`incident\` memory entry), name the target id that would not bind, and flag it for a fix. \`synergyspec-selfevolving status\` prints the machine-written \`Evolution:\` outcome — do not contradict it in free text.
-- Frozen gate-defining / oracle files (the gen-test/run-test oracle, schema contracts you were not asked to evolve) are NEVER touched — the CLI rejects any such edit.
-
-This run also produces neutral \`observations\` in the JSON output (reflection signals). During autonomous evolution learn persists derived evolution hints to \`.synergyspec-selfevolving/learn-handoffs/<change>/<timestamp>/hints.json\`; you then author the edit and promote it via the \`self-evolution evolve-from-edits\` command in the evolve step. The \`--agent\` flag (a headless \`claude -p\` proposer) is a cron/CI fallback ONLY — never use it when you are the running agent, and never assume \`claude\` exists on a non-Claude host.
+This is the review-and-learn step after \`/synspec:apply\` and \`/synspec:verify\`, and it is the ENTRANCE to one self-evolution EPISODE (loop v2 — self-evolution as in-context RL) — but the episode itself runs through a FRESH-CONTEXT runner subagent (\`synergyspec-selfevolving-self-evolving\`). The rollout actor does not grade its own work: end-of-cycle sessions are context-heavy, and the system grades the on-disk trajectory, not the actor's intentions. The runner does not grade or edit either — it triggers the CLI episode orchestrator, which CODE-SPAWNS the 奖励智能体 REWARD AGENT (scoring) and 演进智能体 EVOLVING AGENT (the ONE bounded edit onto the 策略 POLICY), then relays the result. Your job here is to select the change, hand the runner explicit handles, and relay its verdict.
 
 **Steps**
 
@@ -27,169 +14,41 @@ This run also produces neutral \`observations\` in the JSON output (reflection s
 
    Prefer changes that have completed apply/verify evidence. If apply or verify appears incomplete, continue in preview mode and clearly mark the missing evidence.
 
-2. **Load change status and artifacts**
-
-   Run:
-   \`\`\`bash
-   synergyspec-selfevolving status --change "<name>" --json
-   synergyspec-selfevolving instructions apply --change "<name>" --json
-   \`\`\`
-
-   Read every file in \`contextFiles\`. Also check for these optional evidence files under \`synergyspec-selfevolving/changes/<name>/\`:
-   - \`spec-tests.md\`
-   - \`test-report.md\`
-   - \`test-plan.md\`
-   - \`verification.md\`
-   - \`verification-report.md\`
-   - \`spec-blast-radius.md\`
-
-3. **Review implementation and verification evidence**
-
-   Summarize:
-   - Artifact shape: proposal/use cases/specs/design/tasks, schema, and missing pieces
-   - Task completion: completed, incomplete, reopened, or ambiguous tasks
-   - Test evidence: mapped tests, uncovered use-case steps, failing tests, PBT regressions, manual test plans
-   - Verification evidence: critical/warning/suggestion findings, blast radius, and unresolved recommendations
-   - Implementation evidence from git diff if useful, but do not require git history to produce the preview
-
-4. **Extract reusable experience**
-
-   Identify lessons that are specific enough to help future SynergySpec-SelfEvolving work:
-   - Reusable patterns: artifact structure, traceability conventions, implementation sequencing, test strategy, verification heuristics
-   - Problems to avoid: gaps, rework causes, missing tests, brittle assumptions, confusing instructions, unresolved warnings
-   - Local memory candidates: concise lessons that should help a future agent or teammate
-   - Template observations: repeated workflow-template opportunities that may justify a future change, but should not be edited now
-   - Optimization signals: which workflow prompt, artifact template, skill instruction, schema, verifier, or evaluator target could be improved, how it would be improved, and the exact evidence for that mapping
-
-   Be transparent about what is known versus not yet materialized. For each optimization signal, name the CONCRETE canonical target (e.g. \`artifact-template:design\`, \`workflow-prompt:design\`) and the exact edit — you author and promote it in the evolve step.
-
-5. **Generate the preview**
-
-   Use this structure:
-
-   \`\`\`markdown
-   ## Review and Learn: <change-name>
-
-   ### Evidence Read
-   | Evidence | Status |
-   |----------|--------|
-   | tasks.md | loaded / missing |
-   | spec-tests.md | loaded / missing |
-   | test-report.md | loaded / missing |
-   | verification.md | loaded / missing |
-
-   ### Reusable Experience
-   - <lesson with source artifact or file reference>
-
-   ### Problems To Avoid
-   - <issue, why it mattered, and how to prevent it>
-
-   ### Suggested Local Memory Entries
-   | Candidate ID | Type | Title | Disposition | Why Keep It | Evidence |
-   |--------------|------|-------|-------------|-------------|----------|
-   | <id> | workflow | <title> | keep / report-only / reject | <reason> | <artifact/test/verification source> |
-
-   ### Memory Consolidation
-   - Status: preview only / applied
-   - Consolidated: <exact memory entries written, or exact keep candidates that would be written>
-   - Evidence: <retrieval checks, source artifacts, or why no candidate passed the keep gate>
-
-   ### Template Observations
-   - <observation that may justify a future template/spec change>
-
-   ### Skill/Template Optimization Preview
-   | Target | Kind | How It Would Be Optimized | Evidence | Status |
-   |--------|------|---------------------------|----------|--------|
-   | <canonical target id or none> | workflow-prompt / artifact-template / skill-instruction | clarify-instruction / tighten-output-contract / change-template-field / add-verification-step | <hint source artifact or observation> | preview only / hints written / no target |
-
-   ### Next Step
-   - <write memory / persist hints / propose-canonical / auto-evolve / archive>
-
-   ### Evolution Result
-   <which canonical file was evolved + the rollback command, OR why evolution was skipped: --preview, evidence not observed-green, or gate refused>
-   \`\`\`
-
-6. **Consolidate memory and hints (autonomous — no confirmation)**
-
-   Unless \`--preview\` was requested, apply the learn writes directly — do not ask which to apply:
-   - write the learn report (\`synergyspec-selfevolving/changes/<name>/learn-report.md\`);
-   - the approved keep memory entries are written FOR you by this skill's \`learn --apply --yes\` run — it stamps them with the learn-candidate tags + \`synergyspec-selfevolving-learn\` provenance. Do NOT also hand-write them with a bare \`synergyspec-selfevolving memory add\` (that loses the provenance/tag set and double-writes); reserve \`memory add\` for ad-hoc notes that are deliberately NOT learn candidates (report-only / reject candidates stay out of memory either way);
-   - persist evolution hints: \`synergyspec-selfevolving learn "<name>" --persist-hints\` (this writes the hints.json you use in the evolve step).
-
-   \`--preview\` is the only mode that skips these writes.
-
-7. **Apply only approved writes**
-
-   If applying a report, write \`synergyspec-selfevolving/changes/<name>/learn-report.md\` with the preview content plus an "Applied Writes" section.
-
-   If applying memory entries MANUALLY (only when you did NOT run \`learn --apply\`, which already writes them with these tags), use \`synergyspec-selfevolving memory add\` with:
-   - \`--type workflow\` for reusable workflow lessons
-   - \`--type incident\` for problems to avoid
-   - \`--tag synspec-learn\`
-   - \`--tag change:<name>\`
-   - \`--agent-id synergyspec-selfevolving-learn\`
-   - \`--promotion-candidate\` only for template observations that deserve later human review
-
-   Canonical workflow prompts/templates are evolved through the gated \`self-evolution evolve-from-edits\` flow in the next step — not by hand-editing the file (which would bypass the oracle + scope checks).
-
-8. **Evolve the tool from these lessons (autonomous — DO THIS, do not ask)**
-
-   This is the close-the-loop step: you author a concrete improvement to a canonical prompt/template and promote it onto the LOCAL installed file — no rebuild, no republish, no confirmation, no \`claude -p\`.
-
-   a. **Pick the concrete target + its local file.** From the "Skill/Template Optimization Preview" take the canonical target id and its resolved LOCAL file path (e.g. \`artifact-template:design\` → \`synergyspec-selfevolving/schemas/spec-driven/templates/design.md\`). If the preview marks a target unbindable / needs-disambiguation (\`targetId: null\`, \`needsDisambiguation: true\`, formerly shown as \`:unspecified\`), choose ONE concrete id from its \`candidateTargetIds\` and pass it explicitly with \`--evolve-target\` (e.g. \`--evolve-target artifact-template:design\`); then re-run the preview to confirm it now binds. If it STILL will not bind after you name a single concrete \`--evolve-target\`, that is the case-(b) DEFECT above (\`evolution-target-unresolved\`) — surface it and stop; do NOT hand-edit the file to work around it.
-
-   a.5. **Consult the optimization trajectory first.** Before authoring, run \`synergyspec-selfevolving self-evolution trajectory <id> --json\` to see the scored history of prior candidates for this target — their loss, verdict, and one-line approach — plus the \`BASELINE TO BEAT\`. Aim for an edit that would score a LOWER loss than the best prior entry, and do NOT repeat the approach of entries marked \`rejected\`, \`rolled-back\`, or \`outcompeted\`. If it reports no prior candidates yet, just proceed.
-
-   b. **Author the edit yourself.** Reason about the exact prompt/template gap that caused the missed evidence (e.g. the design step missed a stdlib/API-shape compatibility check), then READ the LOCAL file the preview's \`localFiles\` resolves to and write its FULL improved contents. Keep the change minimal and targeted; never touch frozen oracle files.
-
-      Author against the path the preview gives you in \`localFiles\` (project-local). For an artifact-template / schema target on the FIRST evolution that project-local base may not exist on disk yet — the preview resolves the path read-only, and \`evolve-from-edits\` MATERIALIZES the canonical default into it (project-local override → user override → packaged default) when you promote. So if reading \`localFiles\` returns "not found", author your full new file against the canonical default content (the same base the CLI will materialize), not against a global copy. Do NOT go hunting in the GLOBAL npm install for the base (e.g. \`npm root -g\` → \`…/AppData/Roaming/npm/node_modules/synergyspec-selfevolving/schemas/…\`), and never edit anything under the global install — the materialize + promote writes land project-local under the repo (the promote write is guarded by an explicit within-repo assertion). If \`localFiles\` is empty, that target has no user-editable local surface here; treat it as the case-(b) DEFECT, not a reason to reach outside the repo.
-
-   c. **Promote it in one non-interactive command** (validates → gates → observed-verified → promotes onto the local file):
-   \`\`\`bash
-   synergyspec-selfevolving self-evolution evolve-from-edits --from-learn "<hints.json>" --evolve-target <id> --from-edits edits.json --yes
-   \`\`\`
-   where \`edits.json\` = \`{ "targetId": "<id>", "rationale": "<why this fixes the gap>", "edits": [{ "relPath": "<the local file>", "content": "<full new file>" }] }\` (pass \`-\` to read it from stdin).
+2. **Gather explicit handles**
 
-   d. **Report the result.** If it promoted: state the canonical file that changed and the undo command (\`synergyspec-selfevolving self-evolution promote <id> --rollback\`). If it stopped (test evidence not observed-green, or the gate refused): state the reason — the safety floor refused to evolve on unverified/failing evidence; that is correct, not an error.
+   The runner starts with NO conversation context, so collect every handle it needs:
+   - **Project root**: the absolute path of the current working directory.
+   - **Change name**: from step 1.
+   - **Harness**: read the \`harness:\` key from \`synergyspec-selfevolving/changes/<name>/.synergyspec-selfevolving.yaml\`; if absent, use \`unknown\`.
+   - **Mode**: \`preview\` only if the user asked for a preview (the runner passes \`--preview\` so the orchestrator scores and diagnoses WITHOUT committing a rollback or evolution); otherwise \`apply\` (the orchestrator runs the full episode — score, decide, and the 演进智能体's ONE bounded edit — autonomously, no confirmation prompt).
+   - **Session handle (optional)**: if your harness exposes this session's id or transcript path, capture it; otherwise omit it (the 主智能体 MAIN AGENT arm's trajectory discovery then uses the change window).
 
-   Never use \`--agent\` and never spawn \`claude -p\` here — that headless proposer (\`synergyspec-selfevolving self-evolution auto-evolve --change "<name>"\`) is a cron/CI fallback for runs with NO agent in the loop, and it does not exist on a non-Claude host. It honors the same per-target evolve/freeze switch and rollback snapshot.
+3. **Spawn the runner**
 
-9. **(Optional) LLM trajectory-summary handoff**
+   Use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke synergyspec-selfevolving-self-evolving for change '<name>'. Project root: <root>. Harness: <harness>. Mode: <apply|preview>. Session-id: <id>. Transcript: <path>. Trigger the loop-v2 self-evolution episode autonomously, do not ask the user questions, and end with the '## Episode Verdict' block.")
 
-   The learn pipeline can distil reusable memory items from this session's own transcript via an LLM handoff. It is opt-in and runs in three non-blocking phases, so a single agent can both produce and fulfill the brief without the 600-second poll deadlock that the old in-process poll caused.
+   Include the \`Session-id: <id>.\` / \`Transcript: <path>.\` segment only when the session handle from step 2 is known — omit it entirely when unknown.
 
-   **Phase 1 — emit the brief.** Run:
-   \`\`\`bash
-   synergyspec-selfevolving learn handoff "<change>"
-   \`\`\`
-   This assembles the trajectory, writes \`extraction-brief.json\` and a sibling \`README.md\` to \`.synergyspec-selfevolving/learn-handoffs/<change>/<timestamp>/\`, and returns immediately (no polling), printing the workdir and the response path. If it reports \`no-transcript\` (no discoverable session for the change window) or \`no-status\` (no verification/test evidence to derive success/failure), stop here — there is nothing to fulfill.
+   The runner triggers exactly one CLI command — \`synergyspec-selfevolving self-evolution episode --change "<name>" --session-id <id>\` (add \`--preview\` in preview Mode) — and the orchestrator CODE-SPAWNS the 奖励智能体 REWARD AGENT + 演进智能体 EVOLVING AGENT (+ optional CRITIC AGENT（基线智能体）). Neither you nor the runner grades or edits canonical files.
 
-   **Phase 2 — fulfill the brief.** Read \`extraction-brief.json\`. Its \`promptText\` field carries the full system instruction (\`SUCCESSFUL_SI\` for successful trajectories); follow it verbatim — do not paraphrase or substitute another prompt. Apply the four generalization constraints listed in the brief's \`constraints\` array (also rendered in the README): prefer concrete actionable procedures, do not embed product-specific strings, at most 3 items per trajectory, no overlapping items. Write the response as memory-item blocks to the printed response path (\`memory-items.md\`):
-   \`\`\`
-   # Memory Item 1
-   ## Type <incident | codebase-fact | workflow>
-   ## SubtaskStep <proposal | usecases | spec | design | tasks | global>
-   ## Title <short identifier>
-   ## Description <when to / when NOT to use this memory>
-   ## Content <1-3 sentences distilling the insight>
-   \`\`\`
-   If no useful items can be extracted, write a comment-only response (e.g. \`<!-- no useful items -->\`). The parser yields zero candidates without raising an error.
+   Guardrails:
+   - Do NOT trigger the episode yourself in this session — it must run from a fresh context.
+   - **Fallback (no Task tool):** if this host has no Task tool (or spawning fails), invoke the synergyspec-selfevolving-self-evolving skill INLINE instead — use the Skill tool, or read \`<skillsDir>/skills/synergyspec-selfevolving-self-evolving/SKILL.md\` and follow it in this session — and note \`Isolation: inline fallback (degraded)\` in the final output.
+   - **Last resort (runner skill not installed):** run \`synergyspec-selfevolving self-evolution episode --change "<name>" --preview\`, report that the full episode could not run via the runner, and suggest re-running \`synergyspec-selfevolving init\`.
 
-   **Phase 3 — ingest.** Turn the response into classified candidates and, on confirmation, write the keep candidates to local memory:
-   \`\`\`bash
-   synergyspec-selfevolving learn ingest-handoff "<workdir>" --apply --yes
-   \`\`\`
-   (Omit \`--apply --yes\` to preview only.) Ingested items pass through the same \`classifyCandidate\` quality gate as heuristic candidates, so only well-formed items (Trigger / Action / Evidence, bounded scope) are written.
+4. **Verify and relay the verdict**
 
-   **Automated / wrapped runs.** When the env var \`SYNERGYSPEC_SELFEVOLVING_LEARN_LLM\` is truthy AND a separate process wraps the whole \`learn\` run, the main \`learn\` command instead writes the brief and polls \`memory-items.md\` itself (default 600s timeout → \`skipReason: "handoff-timeout"\`, heuristic candidates only). In that mode you only perform Phase 2 — the wrapping process handles emit and ingest. If neither the env var is set nor \`learn handoff\` is run, no brief appears and you can skip this step entirely.
+   Read the runner's \`## Episode Verdict\` block from its final message, then:
+   - Cross-check it against \`synergyspec-selfevolving status --change "<name>" --json\` and the episode's \`episode.json\` / \`diagnosis.json\`. NEVER contradict the machine-written outcome.
+   - Relay the outcome, the decision (rolled-back / kept / abstained), the evolution kind, the new 策略 POLICY version, the evolved target, and the rollback command verbatim.
+   - Classify the outcome before moving on: a \`kept\` / \`abstained\` no-op on a verified-green or no-nameable-gap run is the CORRECT outcome (产物即弃), not a missed evolution; a \`rolled-back\` decision is the loop working (the 否决缓冲 reject-buffer recorded the lost direction). A SAFE refusal (missing/red evidence, frozen target, gate refused on real grounds) is expected, not a bug; a DEFECT the runner flagged (an unbindable target, an orchestrator failure that is NOT about evidence / freezing / scope) must be surfaced to the user, not archived over.
 
 **Output Format**
 
-- Lead with the preview result, not the mechanics.
-- Keep each lesson concrete and traceable to an artifact, task, test, or verification finding.
-- Separate "memory candidates" from "template observations".
-- State clearly whether anything was written.
-- If no useful lessons are found, say so and recommend preview-only.
+- Lead with the runner's verdict, not the spawn mechanics.
+- Relay the \`## Episode Verdict\` fields verbatim: outcome, decision, evolution kind, advantage, new 策略 POLICY version, evolved target, canonical file(s) changed, and the rollback command.
+- State clearly whether the 策略 POLICY changed (evolved / rolled-back / unchanged) and the isolation mode (fresh-context subagent, or inline fallback (degraded)).
+- Separate safe no-ops and refusals from DEFECTs to surface.
 - End with the normal next step: \`/synspec:archive\` once the user is satisfied with the review.`;
 export function getLearnSkillTemplate() {
     return {

package/dist/core/templates/workflows/self-evolving.d.ts

@@ -0,0 +1,13 @@
+/**
+ * Skill Template Workflow Modules
+ *
+ * Self-evolving runner: utility skill (no command counterpart) — always
+ * installed regardless of profile. In loop v2 (self-evolution as in-context
+ * RL) the 奖励智能体 REWARD AGENT (scoring) and 演进智能体 EVOLVING AGENT
+ * (editing) are CODE-SPAWNED by the episode orchestrator — so this host-facing
+ * skill is a THIN RUNNER: it triggers the CLI episode and relays the result.
+ * It NEVER grades and NEVER edits canonical files itself.
+ */
+import type { SkillTemplate } from '../types.js';
+export declare function getSelfEvolvingSkillTemplate(): SkillTemplate;
+//# sourceMappingURL=self-evolving.d.ts.map

package/dist/core/templates/workflows/self-evolving.js

@@ -0,0 +1,127 @@
+const INSTRUCTIONS_BODY = `**Role**
+
+You are the RUNNER for a completed SynergySpec-SelfEvolving change. In loop v2 (self-evolution as in-context RL) you do NOT grade and you do NOT edit canonical files — the orchestrator CODE-SPAWNS the 奖励智能体 REWARD AGENT (judge: 算分 reward(主臂)＆reward(基线臂), advantage ＝ reward(主臂) − reward(基线臂), 文本梯度 textual gradient — it never edits and 弃权 abstains when there is no nameable gap) and the 演进智能体 EVOLVING AGENT (optimizer.step: ONE bounded edit ≤L onto the 策略 POLICY — it never scores), plus an optional CRITIC AGENT（基线智能体 baseline agent）that reruns the last episode's policy vN on the SAME change. Your only job is to TRIGGER the episode via the CLI and RELAY the machine-written result. Read ONLY the on-disk evidence (episode.json, diagnosis.json, the episode JSON output) — never an actor's in-conversation self-report, and never re-judge what the agents decided.
+
+**The boundary (read this first)**
+
+- The skill itself NEVER grades. Scoring — reward(主臂), reward(基线臂), advantage, the 文本梯度 textual gradient — is computed by the CODE-SPAWNED 奖励智能体 REWARD AGENT, never by you.
+- The skill itself NEVER edits canonical files. The ONE bounded edit (≤L) onto the 策略 POLICY (the design template — the 主智能体 MAIN AGENT's "weights") is authored by the CODE-SPAWNED 演进智能体 EVOLVING AGENT, never by you. Do NOT hand-edit any schema/template/prompt file from this skill.
+- You trigger ONE CLI command (the episode orchestrator), then READ and RELAY its result. That is the whole job.
+
+**Input contract**
+
+Parse these handles from the spawning prompt:
+- **Change name** (required). If the change name is missing or does not resolve via \`synergyspec-selfevolving list --json\`, stop and report the error — do NOT prompt the user (you may have no user channel).
+- **Absolute project root.** Run every CLI command from it.
+- **Harness**: \`claude\` | \`codex\` | \`opencode\` | \`unknown\`. If a harness was provided and differs from the ambient host, set \`SYNERGYSPEC_SELFEVOLVING_HOST_HARNESS=<harness>\` for the CLI invocation below.
+- **Session-id / transcript path** (optional). When the spawning prompt supplied a session-id or transcript path, pass \`--session-id <id>\` / \`--transcript <path>\` to the \`episode\` command so the 主智能体 MAIN AGENT arm's trajectory discovery does not depend on the change-window fallback.
+
+**Recursion guard**
+
+Execute every step inline in THIS session. NEVER use the Task tool from this skill, and NEVER invoke synergyspec-selfevolving-learn or synergyspec-selfevolving-self-evolving — you ARE the runner. The 奖励智能体 + 演进智能体 (+ optional 基线智能体) are spawned by the CLI orchestrator in their own contexts; do not spawn them yourself.
+
+**Purpose**
+
+This is the review-and-learn step after \`/synspec:apply\` and \`/synspec:verify\`, and it is the ENTRANCE to one self-evolution EPISODE. You trigger the loop-v2 orchestrator with a single CLI command. The orchestrator runs ONE episode in a strict, durably-persisted order:
+
+1. Records the 主智能体 MAIN AGENT (frozen actor, policy vN+1) arm for this change.
+2. Optionally runs the CRITIC AGENT（基线智能体 baseline agent）— reruns the LAST episode's policy vN on the SAME change (skipped when the 单一血统 single lineage has < 2 versions or the last action was refused).
+3. Runs the 奖励智能体 REWARD AGENT — computes reward(主臂)＆reward(基线臂), advantage ＝ reward(主臂) − reward(基线臂), and the 文本梯度 textual gradient; writes diagnosis.json.
+4. DECIDES on the main arm's edits: 弃权 abstained (no nameable gap) ⇒ skip; bad advantage (< threshold) ⇒ ROLLBACK the 策略 POLICY to the prior good version and append a 否决缓冲 reject-buffer entry; otherwise KEEP.
+5. Runs the 演进智能体 EVOLVING AGENT (optimizer.step) — ONE bounded edit (≤L) onto the 策略 POLICY, or refuses, reading the reject-buffer fresh from disk.
+6. Advances the 版本账本 ledger to the new 策略 POLICY version.
+
+Everything in steps 1–6 is CODE. You do not perform any of it. You issue the command and relay what it wrote.
+
+**The episode commits.** The \`episode\` command always runs the full loop — the orchestrator may roll back / keep / evolve as above; it has no read-only mode. If a read-only look (no rollback, no evolution) is wanted, that is NOT this skill's job: the caller should use plain \`learn <change>\` (no \`--apply\`) or the read-only \`self-evolution policy show\` view instead. Do NOT invent a preview flag — there is none.
+
+**Steps**
+
+1. **Confirm the change resolves**
+
+   Run:
+   \`\`\`bash
+   synergyspec-selfevolving status --change "<name>" --json
+   \`\`\`
+   If the change does not resolve, stop and report the error (do NOT prompt — you may have no user channel). Note from the status output whether apply/verify evidence is present; if it is incomplete, flag the missing evidence in your verdict — the orchestrator's 奖励智能体 REWARD AGENT will 弃权 abstain rather than score on absent evidence.
+
+2. **Trigger the episode (the orchestrator does the work)**
+
+   Run exactly ONE command — the loop-v2 orchestrator. It CODE-SPAWNS the 奖励智能体 REWARD AGENT + 演进智能体 EVOLVING AGENT (+ optional CRITIC AGENT（基线智能体）); you spawn nothing:
+   \`\`\`bash
+   synergyspec-selfevolving self-evolution episode --change "<change>" --session-id <id>
+   \`\`\`
+   - Append \`--session-id <id>\` and/or \`--transcript <path>\` ONLY when the spawning prompt supplied them.
+   - If the harness differs from the ambient host, set \`SYNERGYSPEC_SELFEVOLVING_HOST_HARNESS=<harness>\` first.
+
+   Do NOT grade, score, or author any edit yourself, and do NOT run \`evolve-from-edits\`, \`auto-evolve\`, or \`--agent\` / \`claude -p\` — those are not part of loop v2's host-facing path. The episode command IS the loop.
+
+3. **Read the machine-written result**
+
+   The \`episode\` command prints the episode result (and persists it). Read it from the JSON output, and cross-check the on-disk record:
+   - \`.synergyspec-selfevolving/self-evolution/episodes/<episodeId>/episode.json\` — the episode stage and policy versions.
+   - \`.synergyspec-selfevolving/self-evolution/episodes/<episodeId>/diagnosis.json\` — the 奖励智能体's reward(主臂), reward(基线臂), advantage, 文本梯度, and any abstain reason.
+
+   Take these fields straight from the result — NEVER recompute them:
+   - **advantage** ＝ reward(主臂) − reward(基线臂) (null when the baseline arm was skipped or the reward agent 弃权 abstained).
+   - **decision**: \`rolled-back\` | \`kept\` | \`abstained\`.
+   - **evolution kind**: the 演进智能体 outcome — \`evolved\` | \`refused\` | \`not-spawned\` (null when evolution was skipped, e.g. on 弃权).
+   - **new 策略 POLICY version**: the 版本账本 ledger head AFTER the episode (post-rollback / post-evolve).
+
+4. **Consult the 版本账本 ledger for context (read-only, optional)**
+
+   To explain the result against prior episodes, run the READ-ONLY view:
+   \`\`\`bash
+   synergyspec-selfevolving self-evolution policy show --target <targetId> --json
+   \`\`\`
+   This shows the 版本账本 ledger (prior 策略 POLICY versions for the target, with the current head) and the 否决缓冲 reject-buffer (rolled-back directions to avoid). Use it only to contextualize the verdict — it changes nothing.
+
+5. **Classify the outcome (do not re-judge it)**
+
+   Map the machine result to a verdict, classifying any no-op honestly:
+   - **evolved** — the 演进智能体 wrote ONE bounded edit onto the 策略 POLICY; report the new version and the rollback command.
+   - **kept (no evolution) / abstained** — a verified-green or no-nameable-gap run where nothing was promoted is the CORRECT outcome (产物即弃), not a missed evolution. State the reason from diagnosis.json.
+   - **rolled-back** — the edit's advantage fell below threshold; the 策略 POLICY was restored to the prior good version and a 否决缓冲 reject-buffer entry recorded the lost direction. This is the loop working, not a failure.
+   - **SAFE refusal** (evidence missing/red, target frozen, gate refused on real grounds) is expected; state the reason and move on.
+   - **DEFECT** (the orchestrator COULD NOT act for a reason that is NOT about evidence / freezing / scope — e.g. an unbindable target that persists) — surface it as an unresolved issue; do NOT hand-edit a canonical file to work around it. \`synergyspec-selfevolving status\` prints the machine-written \`Evolution:\` outcome — do not contradict it in free text.
+
+6. **Emit the Runner Verdict (always — the final step)**
+
+   Your session's final message MUST end with the \`## Episode Verdict\` block defined in the Output Format below. Copy every field from the machine-written result (the \`episode\` JSON output / episode.json + diagnosis.json) — never re-judge it. Use \`not-run\` when the episode command was never invoked (change did not resolve); state the reason on the verdict lines.
+
+**Output Format**
+
+The session's final message MUST end with exactly this block shape:
+
+\`\`\`
+## Episode Verdict: <change-name>
+- Outcome: evolved | kept | rolled-back | abstained | not-run | refused-static-gate | refused-unverified-evidence | refused-target-frozen | error-<...>
+- Episode id: <episodeId, or none>
+- Decision: rolled-back | kept | abstained
+- Evolution: evolved | refused | not-spawned | none
+- Advantage: <reward(主臂) − reward(基线臂), or null (baseline skipped / 弃权 abstained)>
+- 策略 POLICY version: <new ledger head version, or unchanged>
+- Evolved target: <canonical target id, or none>
+- Canonical file(s) changed: <paths, or none>
+- Rollback: synergyspec-selfevolving self-evolution promote <candidateId> --rollback
+- Loss vs baseline: <loss / baseline, or unmeasured>
+- Defects to surface: <case-(b) items, or none>
+- Key lessons: <up to 3 one-line bullets from diagnosis.json>
+- Isolation: fresh-context subagent | inline fallback (degraded)
+\`\`\`
+
+- EVERY field MUST be copied from the machine-written result (the \`episode\` JSON output / episode.json + diagnosis.json) — never re-judged. The skill neither grades nor edits; it only relays.
+- Use \`not-run\` when the episode command was never invoked (the change did not resolve); state the reason on the verdict lines.
+- A \`kept\` / \`abstained\` outcome on a verified-green run is the CORRECT no-op, not a missed evolution — say so plainly rather than hedging.
+- Report \`Isolation: fresh-context subagent\` when you were spawned as a subagent; report \`Isolation: inline fallback (degraded)\` when this skill is running inline in the spawning session.`;
+export function getSelfEvolvingSkillTemplate() {
+    return {
+        name: 'synergyspec-selfevolving-self-evolving',
+        description: 'Thin runner for a completed SynergySpec-SelfEvolving change: triggers the loop-v2 self-evolution episode (the orchestrator code-spawns the 奖励智能体 REWARD AGENT and 演进智能体 EVOLVING AGENT) and relays the machine-written result. Never grades and never edits canonical files. Normally spawned by synergyspec-selfevolving-learn rather than invoked directly.',
+        instructions: INSTRUCTIONS_BODY,
+        license: 'MIT',
+        compatibility: 'Requires synergyspec-selfevolving CLI.',
+        metadata: { author: 'synergyspec-selfevolving', version: '1.0' },
+    };
+}
+//# sourceMappingURL=self-evolving.js.map

package/dist/core/trajectory/facts.d.ts

@@ -1,4 +1,7 @@
+import { type ParsedTestFailure } from '../fitness/test-failures.js';
 import type { HarnessName, NormalizedTrajectory } from './model.js';
+/** One failing test observed in the graded runner result's output. */
+export type ObservedTestFailure = ParsedTestFailure;
 export interface TrajectoryFacts {
     harness: HarnessName;
     changeName: string;
@@ -23,6 +26,12 @@ export interface TrajectoryFacts {
     observedStatus: 'success' | 'failure' | null;
     /** True only when a runner was actually observed (observedStatus !== null). */
     verified: boolean;
+    /**
+     * Failing test ids + assertion lines parsed from the GRADED runner result's
+     * output (same result that decides `observedStatus`). Present only when at
+     * least one failure was recognized — the critic's observed failure evidence.
+     */
+    observedFailures?: ObservedTestFailure[];
     /** Count of tool_call parts across main + subagents (effort/activity signal). */
     toolCallCount: number;
     /** Distinct subagent sessions merged into the trajectory (coverage signal). */
@@ -30,6 +39,13 @@ export interface TrajectoryFacts {
     /** Absolute raw transcript paths that produced these facts (audit trail). */
     sourcePaths: string[];
 }
+/** Exported for the action-skeleton projection (skeleton.ts) — single source. */
+export declare function isExecTool(tool: string | undefined): boolean;
+/** Exported for the action-skeleton projection (skeleton.ts) — single source. */
+export declare function inputLooksLikeRunner(input: Record<string, unknown> | undefined): boolean;
+/** Best-effort command text from a tool_call input, for debug display.
+ * Exported for the action-skeleton projection (skeleton.ts) — single source. */
+export declare function commandText(input: Record<string, unknown> | undefined): string | undefined;
 /**
  * Compute the {@link TrajectoryFacts} for a change. Returns `null` when there is
  * no trajectory at all, so callers can cleanly fall back to the authored

package/dist/core/trajectory/facts.js

@@ -13,6 +13,7 @@
  * Pure + no throw.
  */
 import { parseTestMetrics } from '../fitness/test-metrics.js';
+import { parseTestFailures } from '../fitness/test-failures.js';
 /**
  * Matches the NAME of a shell/command-executing tool across harnesses — Claude
  * `Bash`; opencode `bash`; Codex `shell`/`local_shell`/`shell_command`/`exec`;
@@ -29,7 +30,8 @@ import { parseTestMetrics } from '../fitness/test-metrics.js';
  * never match.
  */
 const EXEC_TOOL_RE = /(?:^|[._-])(?:bash|sh|zsh|fish|pwsh|powershell|shell|cmd|exec|command|terminal|run)(?:[._-]|$)/i;
-function isExecTool(tool) {
+/** Exported for the action-skeleton projection (skeleton.ts) — single source. */
+export function isExecTool(tool) {
     return tool !== undefined && EXEC_TOOL_RE.test(tool);
 }
 /**
@@ -56,7 +58,8 @@ function matchesRunner(value) {
     }
     return false;
 }
-function inputLooksLikeRunner(input) {
+/** Exported for the action-skeleton projection (skeleton.ts) — single source. */
+export function inputLooksLikeRunner(input) {
     if (!input)
         return false;
     const preferred = [];
@@ -70,8 +73,9 @@ function inputLooksLikeRunner(input) {
     const values = preferred.length > 0 ? preferred : Object.values(input);
     return values.some(matchesRunner);
 }
-/** Best-effort command text from a tool_call input, for debug display. */
-function commandText(input) {
+/** Best-effort command text from a tool_call input, for debug display.
+ * Exported for the action-skeleton projection (skeleton.ts) — single source. */
+export function commandText(input) {
     if (!input)
         return undefined;
     for (const f of COMMAND_FIELDS) {
@@ -173,6 +177,9 @@ export function toTrajectoryFacts(trajectory, changeName) {
         const passed = runnerExitCode === 0 || (observedPassRate !== null && observedPassRate >= 1);
         observedStatus = failed ? 'failure' : passed ? 'success' : null;
     }
+    // Failure CONTENT from the same graded result that decides the verdict —
+    // omitted entirely when nothing was recognized (keeps JSON baselines stable).
+    const observedFailures = last?.output ? parseTestFailures(last.output) : [];
     return {
         harness: trajectory.harness,
         changeName,
@@ -181,6 +188,7 @@ export function toTrajectoryFacts(trajectory, changeName) {
         observedPassRate,
         observedStatus,
         verified: observedStatus !== null,
+        ...(observedFailures.length > 0 ? { observedFailures } : {}),
         toolCallCount,
         subagentCount: trajectory.subagentSessionIds.length,
         sourcePaths: trajectory.sourcePaths,

package/dist/core/trajectory/skeleton.d.ts

@@ -0,0 +1,43 @@
+import type { HarnessName, NormalizedTrajectory } from './model.js';
+export interface SkeletonEvent {
+    kind: 'file-edit' | 'test-run' | 'command';
+    /** 0-based position in the (post-rollup, pre-truncation) event sequence. */
+    ordinal: number;
+    /** Tool name as the harness reports it. */
+    tool: string;
+    /** POSIX-normalized file path (file-edit only). */
+    file?: string;
+    /** How many consecutive edits to `file` this event rolls up (file-edit only). */
+    editCount?: number;
+    /** Executed command line, capped (test-run / command only). */
+    command?: string;
+    /** Exit code of the paired result, when structured (test-run / command). */
+    exitCode?: number | null;
+    /** Pass rate parsed from the paired runner output (test-run only). */
+    passRate?: number | null;
+    /** Failed-test count parsed from the paired runner output (test-run only). */
+    failedCount?: number | null;
+    /** Session that produced the event (main or subagent). */
+    sessionId?: string;
+}
+export interface ActionSkeleton {
+    harness: HarnessName;
+    /** Ordered, rolled-up, bounded events (≤ {@link MAX_SKELETON_EVENTS}). */
+    events: SkeletonEvent[];
+    /** Total tool_call parts seen (pre-projection activity signal). */
+    totalToolCalls: number;
+    /** True when events were middle-out truncated to the cap. */
+    truncated: boolean;
+}
+/**
+ * Project the bounded action skeleton from a normalized trajectory. One walk,
+ * the same call→result pairing approach as facts.ts's collectRunnerResults
+ * (callId map with a positional fallback).
+ */
+export declare function toActionSkeleton(trajectory: NormalizedTrajectory | null): ActionSkeleton | null;
+/**
+ * Human-readable one-line(ish) play-by-play. Deterministic; events are dropped
+ * middle-out (with an elision marker) until the string fits `maxChars`.
+ */
+export declare function renderActionSkeleton(skeleton: ActionSkeleton, maxChars?: number): string;
+//# sourceMappingURL=skeleton.d.ts.map