/gyoshu-auto

description: Start goal-based autonomous research with bounded execution

Start an AUTONOMOUS research session for the following goal:

$ARGUMENTS

---

> **This is the standalone autonomous research command.** For interactive, step-by-step research, use `/gyoshu <goal>` instead. The `/gyoshu-auto` command runs to completion without user intervention (within budget limits).

---

AUTO Mode Behavior

This command runs in **AUTO mode** - bounded autonomous execution that: 1. Creates or continues a session targeting the specified goal 2. Runs a bounded loop: delegate to @jogyo → **verify with @baksa** → check completion 3. Continues until goal is COMPLETED, BLOCKED (needs user input), or budget exhausted

Adversarial Verification in AUTO Mode

**CRITICAL: The AUTO loop includes mandatory verification via @baksa**

After EVERY @jogyo completion, execute the challenge loop:

Challenge Loop (Max 3 Rounds)

1. **Get Snapshot**: `gyoshu_snapshot(researchSessionID: "...")` 2. **Invoke Critic**: `@baksa Challenge these claims with evidence: [from snapshot]` 3. **Evaluate Trust Score**:

• **80-100 (VERIFIED)**: Accept result, continue to next cycle
• **60-79 (PARTIAL)**: Accept with caveats, note limitations
• **40-59 (DOUBTFUL)**: Send rework request to @jogyo
• **0-39 (REJECTED)**: Escalate to BLOCKED status

4. **If Rework Needed**:

   @jogyo CHALLENGE FAILED - REWORK REQUIRED (Round N/3)

   Failed Challenges:
   - [List from @baksa]

   Required: Address each challenge with evidence

5. **If Round 3 Fails**:

• Set goalStatus to BLOCKED
• Report to user with challenge history
• Do NOT continue autonomous execution

Budget Impact

Challenge rounds count toward the cycle budget:

• Each @baksa invocation = 0.5 cycle cost
• Each @jogyo rework = 1 cycle cost
• Plan accordingly: a single task may consume 3-4 cycles with verification

This ensures research quality through systematic skepticism - no claim passes without verification.

Stage Watchdog

The Stage Watchdog supervises Jogyo's execution of each stage, ensuring bounded execution and graceful recovery from stuck or runaway processes.

Polling Behavior

During stage execution, Gyoshu monitors progress every **5-10 seconds**:

┌─────────────────────────────────────────────────────────────┐
│                    Stage Execution                          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│   t=0s     t=5s     t=10s    t=15s    t=20s    ...         │
│     │        │        │        │        │                   │
│     ▼        ▼        ▼        ▼        ▼                   │
│   [poll]  [poll]  [poll]  [poll]  [poll]                   │
│                                                             │
│   Each poll checks:                                         │
│   ✓ New cells executed since last poll?                     │
│   ✓ New markers emitted ([STAGE:progress], [METRIC:*])?     │
│   ✓ New artifacts created in output directory?              │
│   ✓ Runtime within maxDuration limit?                       │
│                                                             │
└─────────────────────────────────────────────────────────────┘

**Progress Signals:** | Signal | Indicates | Example | |--------|-----------|---------| | New cells | Execution is progressing | Cell count: 5 → 6 | | New markers | Research milestones reached | `[STAGE:progress:pct=50]` | | New artifacts | Output being produced | `model.pkl` created | | REPL output | Active computation | stdout/stderr activity |

**Stall Detection:** A stage is considered **stalled** if no progress signals are detected for 3 consecutive polls (15-30 seconds). Stall triggers a warning but not immediate intervention—some operations (model training) may have long compute phases without output.

Timeout Thresholds

Timeouts are based on the stage's `maxDurationSec` from the stage envelope:

| Threshold | Time | Action | |-----------|------|--------| | **Soft Timeout** | `maxDuration` | Warning logged, grace period begins | | **Hard Timeout** | `maxDuration + 30s` | Interrupt signal sent | | **Absolute Limit** | 600s (10 min) | Cannot exceed regardless of envelope |

**Timeline Diagram:**

Time 0                   maxDuration              maxDuration+30s
  │                           │                         │
  │←──── Normal Execution ────│←──── Grace Period ─────│
  │                           │                         │
  │  [STAGE:begin]            │  [WARNING: soft        │  [SIGINT sent]
  │                           │   timeout exceeded]     │
  │  Regular polling          │                         │
  │  every 5-10s              │  Polling intensifies   │  Escalation
  │                           │  to every 2s           │  begins
  │                           │                         │

Escalation Sequence

When hard timeout is reached, the watchdog escalates through increasingly forceful termination signals:

┌─────────────────────────────────────────────────────────────────────┐
│                     WATCHDOG ESCALATION                             │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  t=maxDur          t=maxDur+5s      t=maxDur+8s      t=maxDur+10s  │
│      │                  │                │                │         │
│      ▼                  ▼                ▼                ▼         │
│   SIGINT            SIGTERM          SIGKILL         CHECKPOINT    │
│   (graceful)        (terminate)      (force kill)    (emergency)   │
│                                                                     │
│  ┌──────────┐      ┌──────────┐      ┌──────────┐   ┌───────────┐  │
│  │ Request  │──5s─▶│  Force   │──3s─▶│  Kill    │─2s▶│  Save     │  │
│  │ cleanup  │      │ terminate│      │  process