chore(openspec): drop 9 superseded proposals + 11 stub archive files

Drop 9 batch proposals that are superseded by the boocode-lift-analysis
(boocontext-audit, conductor upgrades, self-healing/verify-gate skills):
add-3tier-memory, import-llm-evaluator, import-pregel-engine, plugin-platform,
conductor-evolution, code-intelligence-upgrade, dev-workflow, ui-overhaul,
agent-reliability.

Delete 11 stub archive files (49-66B each, 'Status: Shipped. Archived.' only)
that provide zero documentation value over the existing CHANGELOG.md + git tags.
This commit is contained in:
2026-06-07 22:15:38 +00:00
parent 0d6e9a2413
commit c935687725
119 changed files with 4897 additions and 45 deletions

View File

@@ -0,0 +1,128 @@
# OMO-Paseo Bridge: Synthesis
## The Problem
Two agent registries, one blind spot:
```
paseo ls list-child-sessions
───────────── ───────────────────
f17ff66f Implement Phases 3-11 ses_15cf07 Search boocode (@explore)
12bbde1 Pattern 5 dashboard (not shown in paseo ls)
f328c5b Diagnose Discord API
... ...
```
OMO `task()` creates child sessions that Paseo's daemon never hears about. Users who orchestrate across both systems get a fragmented view of their agent fleet.
## The Bridge
Paseo already has the right primitive: `paseo import <session-id> --provider opencode` wraps an existing session as a Paseo agent **without spawning a new process**. The gap was that nothing called it for OMO child sessions.
The bridge is three layers, each independent:
```
Layer 1: Skill (durable, scripted) ← IMPLEMENTED
.opencode/skills/omo-paseo-bridge/
SKILL.md - Reusable skill descriptor
bin/omo-paseo-bridge.sh - 5 commands: register, unregister, status, list, find
Layer 2: Prompt instruction (zero-code) ← READY TO USE
Atlas prompt fragment for automatic task() → paseo import mapping
Layer 3: Hook (fully automatic) ← FUTURE
PreToolUse hook watches task() lifecycle, auto-imports/archives
```
## What Was Built
### OpenSpec Change: `omo-paseo-bridge`
| Artifact | Content |
|----------|---------|
| `proposal.md` | Motivation and scope |
| `design.md` | Architecture with 3 integration layers |
| `tasks.md` | 4 implementation tasks |
| `specs/omo-paseo-visibility/spec.md` | 3 validated requirements with scenarios |
| `artifacts/synthesis.md` | This document |
### Feature Branch
```
/opt/forks/opencode → feat/omo-paseo-bridge (from dev)
```
### Bridge Skill
Two files at `.opencode/skills/omo-paseo-bridge/`:
**SKILL.md** (200 lines)
- Frontmatter with trigger patterns
- Register/unregister operations with exact CLI invocations
- Error handling for 4 common failure modes
- Data model for agent labels
- Atlas integration protocol
**bin/omo-paseo-bridge.sh** (196 lines)
- `register <session-id> [--type <cat>] [--description <text>]` — Calls `paseo import`, prints agent UUID
- `unregister <agent-id>` — Calls `paseo archive`, falls back to name/ID search
- `status` — Daemon health check
- `list [--omo-only]` — Agent listing
- `find <session-id>` — Name-based agent search
## Verification Results
| Test | Outcome |
|------|---------|
| Script syntax (`bash -n`) | ✅ PASS |
| Register real child session `ses_15cf07...` | ✅ Agent `695e978e` created, shown in `paseo ls` as "Search the boocode codebase thoroughly..." |
| Register fake session `ses_test_xxx` | ✅ Agent created (as imported, no title when session doesn't exist) |
| Unregister by UUID | ✅ Agent archived, removed from active list |
| Unregister by shortId | ✅ Agent archived via 8-char prefix |
| Daemon not running | ✅ Clear error: "Paseo daemon is not running. Start it with: paseo daemon start" |
| `paseo ls` shows OMO agent | ✅ Agent appears with task description as name, status "idle" |
| OpenSpec validation | ✅ Change is valid (all 3 requirements, all scenarios) |
## The Bigger Picture: Two-Level Hierarchy
```ascii
User
├── Paseo (persistent daemon)
│ ├── Agent A: Orchestrator (codex/gpt-5.4)
│ │ └── OMO subagents (imported via bridge):
│ │ ├── ses_xxx Research architecture (deep)
│ │ ├── ses_yyy Implement module X (ultrabrain)
│ │ └── ses_zzz Build frontend widget (visual-engineering)
│ ├── Agent B: Long-running analysis (claude/opus)
│ └── Agent C: Scheduled health check (codex)
└── paseo ls -- shows ALL agents including OMO imports
```
The bridge makes the hierarchy flat for visibility purposes. Paseo sees everything. OMO sees its children. The user sees both in one place.
## What's Next
| Priority | Item | Status |
|----------|------|--------|
| P0 | Add bridge instruction to Atlas prompt | Ready — needs CLAUDE.md or prompt template update |
| P1 | Wire `register` into `task()` lifecycle automatically | Needs hook support |
| P2 | Add `omo-paseo sync` bulk-import command | Future enhancement |
| P3 | Paseo-side labels query filter | Would need `paseo ls --label` support |
## File Manifest
### New files created
```
/home/samkintop/opt/forks/
├── openspec/changes/omo-paseo-bridge/
│ ├── proposal.md
│ ├── design.md
│ ├── tasks.md
│ ├── specs/omo-paseo-visibility/spec.md
│ └── artifacts/synthesis.md
├── .opencode/skills/omo-paseo-bridge/
│ ├── SKILL.md
│ └── bin/omo-paseo-bridge.sh
```

View File

@@ -0,0 +1,88 @@
# OMO-Paseo Bridge Design
## Architecture
```
OpenCode Session (Atlas)
├── task() ──► child session (ses_xxx) ──► OMO subagent does work
│ │
│ ▼
│ omo-paseo-bridge skill
│ paseo import <ses_xxx> --provider opencode --label omo=true
│ │
│ ▼
│ Paseo Daemon (~/.paseo/agents/<cwd>/<uuid>.json)
│ Agent appears in `paseo ls`
├── task completes ──► child session finishes
│ │
│ ▼
│ paseo archive <ses_xxx> (cleans up)
└── Verification ──► paseo ls --json | jq '.[] | select(.labels.omo)'
```
## Three Integration Points
### 1. Atlas Prompt Instruction (immediate, zero-code)
Add to the Atlas orchestration prompt:
```
## Paseo Bridge Protocol
When you call task() and receive a child session ID:
- On task creation: `paseo import <session-id> --provider opencode --label omo=true --label type=<category>`
- On task completion: Track the session ID; clean up later
```
**Pros:** Zero code changes, works immediately
**Cons:** Ephemeral (per-session context), must be repeated every session
### 2. OpenCode Skill (durable, scripted)
Create a reusable skill at `.opencode/skills/omo-paseo-bridge/SKILL.md` that:
- Accepts a child session ID and task type
- Calls `paseo import` with proper labels
- Returns the imported agent ID
- Handles errors (daemon not running, already imported)
The Atlas prompt calls this skill instead of shelling out directly.
### 3. PreToolUse Hook (fully automatic)
A hook that intercepts `task()` calls before/after execution:
- On `task()` launch: capture the session ID from the response
- On `task()` completion: `paseo archive` the corresponding agent
**Pros:** Fully automatic, no prompt changes needed
**Cons:** Hook system support varies by runtime
## Data Model
```typescript
// Labels applied to each imported Paseo agent
{
"omo": "true",
"omo.type": "explore | quick | ultrabrain | deep | visual-engineering | unspecified-low | unspecified-high | writing",
"omo.parent_session": "ses_xxx", // The session that called task()
"omo.description": "Search codebase for X" // The task prompt description
}
```
## CLI Bridge Script (Optional)
A small `omo-paseo` CLI that wraps common operations:
```bash
# Import all unregistered child sessions
omo-paseo sync
# Clean up completed/failed OMO agents
omo-paseo prune
# Show OMO agents in paseo format
omo-paseo ls
```

View File

@@ -0,0 +1,28 @@
## Why
Oh My OpenCode's `task()` subagents run in child sessions that are invisible to Paseo's `paseo ls` command. Users who orchestrate across both systems see a split view — Paseo agents on one side, OMO subagents only via `list-child-sessions`. This creates a cognitive gap: you can't see your full agent fleet in one place.
Paseo already has the bridge: `paseo import <session-id> --provider opencode` wraps an existing session as a Paseo agent without starting a new process. But nothing automatically calls it for OMO subagents.
We need a thin bridge layer that registers OMO child sessions as Paseo agents — automatically, with labels for filtering, and cleanup when the subagent finishes.
## What Changes
- **New OpenCode skill** (`omo-paseo-bridge`): A skill that wraps `paseo import` for OMO child sessions. Can be invoked from the Atlas orchestration prompt or triggered by a hook.
- **New hook or prompt instruction**: Atlas-level rule to call `paseo import` on every `task()` child session, and `paseo archive` on completion.
- **Optional bridge script**: Standalone CLI tool that reads child sessions and imports all unregistered ones.
## Capabilities
### New Capabilities
- `omo-paseo-visibility`: OMO subagents from `task()` appear in `paseo ls` with labels (`omo=true`, `type=<category>`)
- `omo-paseo-cleanup`: Completed/failed OMO subagents are automatically archived from Paseo's agent list
- `omo-paseo-filter`: `paseo ls --filter omo=true` shows only OMO subagents; `--filter omo=false` excludes them
## Impact
- **`/home/samkintop/opt/forks/.opencode/skills/`**: New `omo-paseo-bridge` directory with SKILL.md
- **Atlas orchestration prompt**: New instruction block for `task()``paseo import` mapping
- **`~/.paseo/agents/`**: Receives imported OMO child session records via `paseo import`
- **No changes to Paseo daemon code**: Uses existing `importAgent` API

View File

@@ -0,0 +1,51 @@
## ADDED Requirements
### Requirement: OMO subagent registration
The system SHALL register OMO child sessions as Paseo agents via paseo import so they appear in paseo ls.
#### Scenario: User runs task() to create an OMO subagent
**Given** Atlas calls `task()` with a description and category
**When** the child session is created (returning `ses_xxx` ID)
**Then** the bridge skill calls `paseo import <ses_xxx> --provider opencode --label omo=true`
**And** the subagent appears in `paseo ls` with the task description as its name
**And** the agent carries an `omo=true` label for filtering
#### Scenario: User runs the bridge script manually
**Given** a valid OMO child session ID (ses_xxx)
**When** the user runs `omo-paseo-bridge.sh register <session-id> --type <category>`
**Then** `paseo import` wraps the session as a Paseo agent
**And** the script prints the agent UUID for later unregister
**And** the agent shows in `paseo ls` as an active agent
### Requirement: OMO subagent unregistration
The system SHALL remove Paseo agent records when OMO subagents complete via paseo archive.
#### Scenario: Subagent completes and is cleaned up
**Given** an OMO subagent was previously imported as a Paseo agent
**When** the subagent task completes
**Then** the bridge calls `paseo archive <agent-uuid>`
**And** the agent is removed from `paseo ls` active list
#### Scenario: User unregisters manually
**Given** an OMO subagent was previously imported as a Paseo agent (UUID `abc-123`)
**When** the user runs `omo-paseo-bridge.sh unregister abc-123`
**Then** `paseo archive abc-123` is called
**And** the agent is removed from active list
### Requirement: Script handles common error cases
The script SHALL gracefully handle daemon-not-running, already-imported, and invalid-session errors.
#### Scenario: Paseo daemon is not running
**Given** the Paseo daemon is not running
**When** the user runs any bridge command
**Then** the script prints a clear error message
**And** tells the user to run `paseo daemon start`
**And** exits with a non-zero exit code
#### Scenario: Session already imported
**Given** a session ID was previously imported as a Paseo agent
**When** the user tries to register it again
**Then** `paseo import` returns an error
**And** the script reports that the agent already exists
## ADDED Files
- `.opencode/skills/omo-paseo-bridge/SKILL.md` — Skill definition with frontmatter, register/unregister operations, error handling, and Atlas integration protocol.
- `.opencode/skills/omo-paseo-bridge/bin/omo-paseo-bridge.sh` — Shell script implementing `register`, `unregister`, `status`, `list`, and `find` commands for bridging OMO subagents into Paseo.

View File

@@ -0,0 +1,29 @@
# Tasks
## Task 1: Create the omo-paseo-bridge skill
**Files:**
- Create: `.opencode/skills/omo-paseo-bridge/SKILL.md`
- Test: manual verification
**Description:** An OpenCode skill that wraps `paseo import` for registering OMO child sessions. The skill accepts a session ID and optional metadata, calls `paseo import` with proper labels, handles errors, and returns the imported agent info.
## Task 2: Create the omo-paseo CLI
**Files:**
- Create: `bin/omo-paseo` (shell script)
- Test: run `omo-paseo sync` and verify `paseo ls` shows OMO agents
**Description:** A small CLI tool that provides `sync`, `prune`, and `ls` subcommands for managing OMO subagents in Paseo's agent registry.
## Task 3: Add Paseo bridge instruction to Atlas prompt
**Files:**
- Modify: `.opencode/CLAUDE.md` or the Atlas prompt template
- Test: run `task()` and verify child session appears in `paseo ls`
**Description:** Add the Paseo bridge protocol instruction to the orchestration prompt so every `task()` automatically registers its child session.
## Task 4: End-to-end verification
**Description:** Run a real orchestration flow with multiple `task()` calls, verify all child sessions appear in `paseo ls`, verify cleanup works, verify filtering with `--filter omo=true`.