ramza-parallel-spec
TRANCE-only G3 evaluator-optimizer mode: fan out 2-4 perspective-diverse clean-context candidate specs, score with a bias-hardened evaluator anchored on ramza-score, judge-merge into ONE spec, terminate at confidence ≥85% or hard cap 3 iterations. Read-only; never the default — runs ONLY when the cortex authorizes TRANCE.
- License 许可
- MIT
- 所属仓库
- Rynaro/prisma
- 最近更新
- 2026-10-18
- Stars
- ★ 1
- Forks
- 0
01 前言 Front Matter
- name
- ramza-parallel-spec
- metadata
- { "phase": "TRANCE", "methodology": "RAMZA" }
- description
- TRANCE-only G3 evaluator-optimizer mode: fan out 2-4 perspective-diverse clean-context candidate specs, score with a bias-hardened evaluator anchored on ramza-score, judge-merge into ONE spec, terminate at confidence ≥85% or hard cap 3 iterations. Read-only; never the default — runs ONLY when the cortex authorizes TRANCE.
03 SKILL.md 正文
RAMZA — Parallel Spec Mode (G3 evaluator-optimizer)
This mode wraps the standard RS→S→P→E→C→T→R→A cycle — it does NOT replace it. It operationalizes the G3 TRANCE form named in the nexus trance-matrix ("Generator + evaluator + termination gate; cap 3 iterations").
Activation — TRANCE-GATED (never default)
This mode is TRANCE-gated. Do NOT fan out candidate specs at standard tier; run the single-pass RS→S→P→E→C→T→R→A cycle instead.
Activate ONLY when the cortex authorizes TRANCE — i.e. BOTH complexity AND stakes
flags hold: complexity 10–12 (per ramza-score --rubric complexity) STRATEGIC/CHANGE
specs, multi-service architecture, or high-rework-risk system design. At standard
tier, fall back to the normal cycle.
Read-vs-write safety
RAMZA is READ-ONLY in every phase (DESIGN-RATIONALE.md D2), so the parallel
generator branches are the explicitly-SAFE parallel-READ case — NO worktree
isolation is required (R1-01). This is distinct from Vivi/APIVR-Δ's
parallel-WRITE, which does need worktree isolation.
The cycle: GENERATE → EVALUATE → JUDGE-MERGE → TERMINATE
1. GENERATE (perspective-diverse fan-out)
Fan out 2-4 clean-context generator branches (default 3, hard cap 4). Each branch receives the SAME Scope + Pattern context but a DIFFERENT assigned perspective, producing a full candidate draft spec:
- one conservative (low-risk, proven)
- one pattern-leveraging (maximize reuse of existing conventions)
- one innovative (novel approach)
- optionally one risk-minimizing (blast-radius-first)
Perspective diversity is deliberate, not naive N-identical sampling — quality dominates raw diversity, so cap at 3-4 high-quality branches, never spawn N clones (R3-04, R3-06; cost-ceiling C1 max 5 → capped at 4 here because spec generation is expensive). Use clean-context subagents so branches cannot self-condition on each other's trajectory (R1-03).
2. EVALUATE (bias-hardened scoring)
A single evaluator scores each candidate through the tool — never hand-computed:
echo '{"alignment":9,"correctness":8,"maintainability":7,"performance":7,"simplicity":6,"risk":7,"innovation":5}' \
| ramza-score --rubric explore --state <state> --label "<candidate-perspective>"
The 7-dimension weighted rubric (Alignment 25% + Correctness 20% +
Maintainability 15% + Performance 15% + Simplicity 10% + Risk 10% + Innovation
5%, see docs/methodology/scoring.md) is arithmetic done by ramza-score, not
the evaluator — the evaluator's job is producing honest per-dimension inputs
while applying EXPLICIT LLM-as-judge bias mitigations (R3-09):
- Strip authoring-branch identity/label from each candidate before scoring (counters self-preference / identity bias).
- Randomize / rotate candidate presentation order across the comparison (counters position bias).
- Length-normalize — judge on rubric-dimension content, not verbosity (counters verbosity bias).
- Anchor on deterministic checks — prefer
ramza-lint/ramza-ears-lintand the dependency/constraint layers already in the Test (T) phase as the trust anchor over pure LLM judgment.
Record the per-candidate ramza-score results (each call appends to the state
file's gates[] and the calibration log) and the bias mitigations applied, so
the evaluation is auditable in the final spec.
3. JUDGE-MERGE (mandatory aggregation)
Synthesize ONE spec by taking the highest-scoring approach per dimension:
- Record which candidate won each dimension and why, via
[DECISION]markers (per-dimension provenance table). - Carry every rejected candidate's rationale into the Rejected Alternatives
section (a full-tier-required section, see
docs/methodology/tiers.md) — never silently discard a losing branch.
The result is one synthesized dual-format spec (Markdown + YAML/JSON) that
still passes through the normal Assemble exit gates — ramza-freeze, then
ramza-verify-emit before any envelope is emitted. Downstream sees exactly one
spec + one validated ECL envelope, identical to the standard cycle. The
parallel mode is invisible at the hand-off boundary.
4. TERMINATE (bounded)
Stop when the merged-spec confidence ≥85% (ramza-score --rubric confidence at the Assemble gate) OR the iteration count reaches the hard cap
of 3 — whichever comes first. The cap is inviolable (inherited unchanged from
SPECTRA, DESIGN-RATIONALE.md D2; the nexus trance-matrix R4 refusal gate). On
non-convergence, emit a [GAP]/[BLOCKED] gap report and escalate to the
human — do not loop past the cap.
Hard constraints (P0)
- TRANCE-only — never the default; standard tier runs the single-pass cycle.
- READ-ONLY; no worktree isolation needed (read-only ⇒ safe parallel).
- Cap branches at 4 (default 3); cap iterations at 3.
- Evaluator MUST apply identity-strip + order-rotate + length-normalize +
deterministic-anchor and record them auditably; scoring arithmetic always
runs through
ramza-score, never hand-computed. - JUDGE-MERGE produces ONE spec with per-dimension
[DECISION]provenance, and still passes throughramza-freeze+ramza-verify-emitbefore emission. - Non-convergence →
[GAP]escalation, never an unbounded loop.
See SPEC.md "## Parallel spec mode (TRANCE-gated)" for the
full methodology section and DESIGN-RATIONALE.md for the succession's
research basis.
RAMZA — Parallel Spec Mode (TRANCE / G3)
04 同仓库更多 Skills
vivi-verify-incoming
Load when reading any upstream artefact handed off to Vivi that carries a sibling .envelope.json. BLOCKING per ECL §6.2.2: the orchestrator MUST have verified the envelope's SHA-256 (eidolons verify-envelope --block / eidolons run --verify) and recorded a verify_pass before dispatch. If no verify_pass exists for the message_id, or a verify_fail is present, REFUSE to process the payload and hand back to the orchestrator. Symmetric receiver gate — every Eidolon enforces it identically.
vivi-parallel-tracks
Load ONLY under TRANCE authorization when the Plan phase yields N independent, non-overlapping implementation tracks (disjoint file sets). Operationalizes the TRANCE G4 form — parallel multi-track implementation in mandatory git-worktree isolation, max 5 clean-context tracks, a per-track verifier cascade, a non-fungible per-track ≤3 reflection budget, explicit stop conditions, and a single-threaded merge/aggregation step. Absent TRANCE gating, Vivi runs exactly as today: single-track A→P→I→V→Δ/R.
vivi-methodology
Full Vivi cycle reference — A(nalyze) → P(lan) → I(mplement) → V(erify) → Δ(Delta)/R(eflect). Use when the task is a non-trivial feature implementation in a brownfield codebase and you need the complete methodology reference: complexity routing, evidence-grounded planning rules, test-anchoring requirements, and failure-escalation thresholds.
vivi-memory-management
Load at Vivi session start, session end, or when you notice a repeating pattern across tasks. CRYSTALIUM-primary memory protocol: when mcp__crystalium__* tools are available, route ALL memory through CRYSTALIUM (recall/commit/ingest/plan_checkpoint/session_end). The local agents/memories/*.md files are the standalone fallback for when CRYSTALIUM is absent — EIIS conformance. Never write both.
vivi-loop-native
Load in Vivi's V (Verify) phase. The core capability that distinguishes Vivi from its predecessor APIVR-Δ: drive the closed, autonomous, bounded edit-run-test loop (`eidolons sandbox loop`) as its `--fix-hook`, consuming localized feedback, retrying in fresh context, refusing to game the tests, and gating on pass^k. Use whenever the task has an executable test oracle and a loop-competent host.
vivi-failure-recovery
Load when the Vivi Verify phase produces failures — test fails, lint error, build break, or three consecutive unsuccessful attempts at the same category. Provides the failure classification taxonomy, bounded debugging protocol, and escalation thresholds. Use to avoid the 'random retries' anti-pattern.