---
name: co-fita-hyper-workspace
type: analysis
title: "Hyper Workspace State — Live Operational Data"
description: "The hyper_workspace: task spec, directions tried, progress tracking, failure tree data, orchestrator logs"
tags: [workspace, state, orchestrator, failure-tree, progress]
timestamp: 2026-07-21
---

# Hyper Workspace State — Live Operational Data

The hyper_workspace is the live operational state of the Co-Fita Hyper-Harness during execution. It implements the Deli_AutoResearch protocol's state file architecture, ensuring that all progress persists across context compaction and session boundaries.

## State File Architecture

Following the Deli_AutoResearch protocol, the workspace maintains a structured state directory:

```
hyper_workspace/
├── state/
│   ├── task_spec.md           # Goal, milestones, success criteria
│   ├── progress.json          # Iteration count, findings, stale tracking
│   ├── directions_tried.json  # Historical directions (prevents repetition)
│   └── findings.jsonl         # Accumulated findings (append-only)
├── failure_tree/
│   └── failure_tree.json      # EnCompass-style execution tree (658 KB)
└── logs/
    └── orchestrator.jsonl     # Timestamped orchestration events
```

## Current State

### Task Specification

The current task is:

> "Maintain and evolve the system (Centralismo Democratico)"

This is the root objective for the governance system's autonomous operation.

### Progress Metrics

| Metric | Value | Interpretation |
|--------|-------|----------------|
| **Iteration** | 0 | System initialized but not yet iterating |
| **Total Findings** | 0 | No findings accumulated yet |
| **Status** | `initialized` | Ready for first iteration |
| **Stale Count** | 0 | No stalls detected |
| **Last Seen** | 1781758476.297426 | Unix timestamp of last activity |

### Directions Tried

The `directions_tried.json` file is currently empty (`[]`), indicating the system has not yet attempted any directions. This is consistent with the `initialized` status.

## Failure Tree Analysis

The failure tree (658 KB) implements the EnCompass-style execution tree with unexplored branch tracking. The root node and initial children show:

### Root Node Structure

| Field | Value |
|-------|-------|
| **Root ID** | `48470eb7` |
| **Root Approach** | "Maintain and evolve the system (Centralismo Democratico)" |
| **Root Status** | running |
| **Depth** | 0 |

### Node Properties

Each node in the tree contains:

```json
{
  "id": "ca9f0b5a",
  "approach": "Maintain and evolve the system (Centralismo Democratico)",
  "status": "running",
  "parent_id": null,
  "children": [],
  "depth": 0,
  "failure_reason": null,
  "failure_category": null,
  "reflection": null,
  "metrics": {},
  "created_at": 1781758476.3033412,
  "completed_at": null
}
```

### Observed Pattern

The failure tree shows multiple root-level nodes with identical approaches, all in `running` status. This suggests the orchestrator has been spawning parallel execution contexts, each starting fresh with the same task specification. The nodes have:

- **No parent-child relationships** (`parent_id: null`, `children: []`)
- **No failures recorded** (`failure_reason: null`)
- **No reflections generated** (`reflection: null`)
- **Consistent timestamps** (spaced ~30 seconds apart)

This pattern indicates the system is in its initialization phase, spawning multiple parallel workers before any have completed or failed.

## Orchestrator Logs

The orchestrator logs (`orchestrator.jsonl`) show the initialization pattern:

### Log Entry Format

```json
{
  "ts": 1781758476.298393,
  "source": "orchestrator",
  "level": "info",
  "event": "initialized",
  "detail": "Task: Maintain and evolve the system (Centralismo Democratico)"
}
```

### Initialization Sequence

The logs reveal a consistent pattern:

1. **initialized**: Task specification loaded
2. **tree_root**: Failure tree root node created

This two-step initialization repeats for each parallel worker, with timestamps spaced approximately 30 seconds apart:

| Timestamp | Event | Root ID |
|-----------|-------|---------|
| 1781758476.298393 | initialized | ca9f0b5a |
| 1781760392.193687 | initialized | ab1ae2f9 |
| 1781760410.1033611 | initialized | 372e2e06 |
| 1781760440.264925 | initialized | 706b6cab |
| 1781760470.272795 | initialized | 4e8a0d49 |
| 1781760500.2838762 | initialized | e781b538 |
| 1781760530.305341 | initialized | 4d3cf634 |
| 1781760560.313236 | initialized | 2f01c568 |
| 1781760590.3253682 | initialized | db373a78 |
| 1781760620.338675 | initialized | 315c15dd |

The 30-second spacing suggests the orchestrator is using a polling interval consistent with the Deli_AutoResearch protocol's heartbeat mechanism.

## EnCompass Integration

The failure tree implements the EnCompass pattern from MIT CSAIL (NeurIPS 2025), which provides:

1. **Probabilistic Angelic Nondeterminism (PAN)**: Branch points in execution
2. **Backtracking**: When a path fails, return to the last decision point
3. **Cloning**: Spawn parallel exploration of alternative branches
4. **Unexplored Branch Tracking**: Identify promising unexplored siblings

### Key Insight from EnCompass

> "When a path fails, EnCompass can backtrack to the last decision point, clone the agent's runtime state, explore alternative branches in parallel, and track which branches were never visited."

This validates Alefita's intuition: "se outras possibilidades se abrem com ramos daquele caminho falho que nunca foram explorados."

### Heuristic Prioritization

The failure tree's `get_promising_unexplored()` method ranks unexplored nodes by:
- Parent depth (deeper = more context)
- Sibling failure type (some failures indicate more promising alternatives)
- Failure category (goal drift vs logic error vs stalling)

## The Five-Phase Orchestrator Loop

The orchestrator implements a 5-phase loop with Phase V Governance:

```
Phase I: Ideation (SearXNG + Crawl4AI research)
    ↓
Phase II: Execution (OpenCode via ACP)
    ↓
Phase III: Audit (HashMath + Red Team)
    ↓
Phase IV: Fixation (Wiki export + state update)
    ↓
Phase V: Governance (Proposal generation + Congress)
```

### Failure Path

When audit fails:
1. `GovernanceIntegration.process_iteration(audit_passed=False)`
2. Automatic proposal generated from failure
3. Proposal enters DRAFT status
4. Congress convenes every N=3 iterations

### Success Path

When audit passes:
1. Wiki export (state compiled to knowledge base)
2. Governance check (congress interval)
3. Progress metrics updated
4. Next iteration begins

## Stall Detection Mechanisms

Following the Deli_AutoResearch protocol:

| Mechanism | Rule | Current Status |
|-----------|------|----------------|
| **Stall detection** | 0 new findings or metric drop → stale_count + 1 | stale_count = 0 |
| **Forced pivot** | stale_count >= 2 → structural constraint change | Not triggered |
| **Human escalation** | stale_count >= 4 → flag for human attention | Not triggered |
| **Direction diversity** | New direction must differ from all tried | 0 directions tried |
| **Round cap** | 15 rounds or 30 minutes per session | Not reached |

### Pivot Strategy

> "Pivot structure, not tactics" — when a task stalls repeatedly within a frame, the decisive gain usually comes from correcting the environment/structural constraint itself, not from tuning strategy parameters harder inside the existing frame.

## State Persistence Across Context Compaction

The workspace implements the Deli_AutoResearch protocol's state management:

1. **Physical State Files**: All progress written to `state/` directory
2. **Fresh Session per Iteration**: Each iteration starts with fresh context
3. **Curated State Injection**: Only relevant state injected at session start
4. **No Resume**: Never resume from conversation memory

This prevents the cognitive loop failure mode where context accumulation leads to repeated similar strategies with diminishing returns.

## Failure Tree Deep Dive

The failure tree (658 KB) is the largest state file, implementing the EnCompass pattern for probabilistic agent backtracking.

### Tree Structure

```
Root Node (48470eb7)
├── ca9f0b5a (running)
├── ab1ae2f9 (running)
├── 372e2e06 (running)
├── 706b6cab (running)
├── 4e8a0d49 (running)
├── e781b538 (running)
├── 4d3cf634 (running)
├── 2f01c568 (running)
├── db373a78 (running)
├── 315c15dd (running)
└── ... (more nodes)
```

### Node Properties

Each node contains:
- **id**: Unique 8-character hex identifier
- **approach**: The strategy being attempted
- **status**: `running`, `completed`, `failed`, or `unexplored`
- **parent_id**: Link to parent node (null for root)
- **children**: List of child node IDs
- **depth**: Distance from root (0 for root)
- **failure_reason**: Why this approach failed (if applicable)
- **failure_category**: Classification from AgentRx taxonomy
- **reflection**: Natural language self-critique (Reflexion-style)
- **metrics**: Quantitative measurements
- **created_at**: Unix timestamp
- **completed_at**: Unix timestamp (null if still running)

### Failure Categories (AgentRx Taxonomy)

| Category | Description | Example |
|----------|-------------|---------|
| **Goal Drift** | Agent deviates from original objective | Starts optimizing wrong metric |
| **Tool Misuse** | Incorrect tool selection or parameters | Uses search when should read file |
| **Logic Error** | Correct tools, wrong reasoning | Off-by-one in loop |
| **Stalling** | Agent loops without progress | Same tool call repeated 5+ times |
| **Silent Failure** | Reports success but goal not met | "Done!" but output is wrong |
| **Hallucination** | Fabricated facts or API calls | Calls non-existent endpoint |

### Heuristic Prioritization

The `get_promising_unexplored()` method ranks unexplored nodes by:
1. **Parent Depth**: Deeper nodes have more context
2. **Sibling Failure Type**: Some failures indicate more promising alternatives
3. **Failure Category**: Goal drift suggests different direction, logic error suggests refinement

### EnCompass Integration

The failure tree implements Probabilistic Angelic Nondeterminism (PAN):
- **Branch Points**: Decision nodes where multiple approaches are possible
- **Backtracking**: When a path fails, return to last decision point
- **Cloning**: Spawn parallel exploration of alternative branches
- **Unexplored Tracking**: Identify promising unvisited siblings

**Key Insight from MIT CSAIL**: "When a path fails, EnCompass can backtrack to the last decision point, clone the agent's runtime state, explore alternative branches in parallel, and track which branches were never visited."

This validates Alefita's intuition: "se outras possibilidades se abrem com ramos daquele caminho falho que nunca foram explorados."

## Orchestrator Log Analysis

The orchestrator logs reveal the initialization pattern and polling behavior.

### Log Entry Structure

```json
{
  "ts": 1781758476.298393,
  "source": "orchestrator",
  "level": "info",
  "event": "initialized",
  "detail": "Task: Maintain and evolve the system (Centralismo Democratico)"
}
```

### Event Types

| Event | Description |
|-------|-------------|
| `initialized` | Task specification loaded, orchestrator ready |
| `tree_root` | Failure tree root node created |
| `iteration_start` | New iteration beginning |
| `iteration_complete` | Iteration finished, findings recorded |
| `stall_detected` | stale_count incremented |
| `pivot_forced` | Structural constraint changed |
| `congress_convened` | Governance Congress session started |
| `chancela_pending` | Proposal awaiting human approval |

### Polling Interval

The 30-second spacing between initialization events suggests the orchestrator uses a polling interval consistent with the Deli_AutoResearch protocol's heartbeat mechanism. This interval is:
- Short enough to detect stalls quickly
- Long enough to avoid excessive resource usage
- Aligned with the L1 heartbeat watchdog (hourly)

### Parallel Worker Pattern

The logs show multiple root-level nodes being created in parallel:
- Each worker starts fresh with the same task specification
- Workers operate independently (no parent-child relationships)
- All workers share the same failure tree (read/write access)
- Coordination happens via state files, not direct communication

## The Five-Phase Loop in Detail

### Phase I: Ideation

- SearXNG discovers relevant URLs
- Crawl4AI reads full content of discovered URLs
- OpenCode (via ACP) synthesizes and generates hypotheses
- New directions must differ from `directions_tried.json`

### Phase II: Execution

- OpenCode compiles code, runs experiments
- State files updated with intermediate results
- Failure tree branches created for new approaches
- Max 5 large files per iteration, no file over 300 lines

### Phase III: Audit

- HashMath verifies formal correctness
- Red Team Arena conducts adversarial testing
- Shannon entropy analysis detects reward hacking
- Audit result: `audit_passed` boolean

### Phase IV: Fixation

- Wiki export (state compiled to knowledge base)
- Findings appended to `findings.jsonl`
- Progress metrics updated in `progress.json`
- `directions_tried.json` updated with attempted directions

### Phase V: Governance

- If audit failed: automatic proposal generated
- If audit passed: governance check (congress interval)
- Every N=3 iterations: Congress convened
- Approved proposals → AWAITING_CHANCELA

## State File Relationships

```
task_spec.md (read-only goal)
     │
     ▼
progress.json (iteration count, stale tracking)
     │
     ├──► findings.jsonl (append-only discoveries)
     │
     ├──► directions_tried.json (prevents repetition)
     │
     └──► failure_tree.json (EnCompass branching)
              │
              ▼
         orchestrator.jsonl (timestamped events)
```

### Data Flow

1. **Task Spec** defines the goal (read once at initialization)
2. **Progress** tracks iteration count and staleness (updated each iteration)
3. **Findings** accumulate discoveries (append-only, never modified)
4. **Directions Tried** prevents repetition (read before each iteration)
5. **Failure Tree** tracks branching strategies (read/write during execution)
6. **Orchestrator Logs** record all events (append-only, for debugging)

## Cross-References

- [[co-fita-deli-governance]] — Governance layer that generates proposals
- [[co-fita-harness-wiki]] — Intellectual foundation and state file architecture
- [[co-fita-agent-skills]] — Skills that read/write workspace state
- [[multi-agent-methodology]] — Multi-agent orchestration patterns