0.6.0: Port pipecat-subagents into pipecat core (#411)

* Port pipecat-subagents into pipecat core (0.6.0 foundation)

Squashed from aleix/port-subagents-to-pipecat:
- migrate from pipecat-ai-subagents to in-tree pipecat workers
  (BaseAgent/LLMAgent -> PipelineWorker; AgentRunner -> PipelineRunner)
- adapt #386 (bypass_tutorial) and #410 (init_cekura) to the new
  PipelineWorker structure
- pin pyproject.toml to pipecat-ai/pipecat aleix/port-subagents-to-pipecat
  branch until upstream PR #4493 merges

* stub progress

* llm context dump

* teardown code complete

* client message handler

* pre-task agent move over

* orchestrator prep

* moved task agent over

* task agent move

* update tests

* docs

* release: v0.6.0

* fixed config defaults, use pydantic-settings for typing

* restore supabase server script

* fixed dockerfile uv command

* fixed byoa examples and onboarding prompt

* fixed task agent onboarding (personal ship)

* pin deno version and false out empty envs in config

* Fix BYOA worker registry invalidation

* Honor edge functions override

* Fix BYOA task output type

* Drop stale progress expectation

* Remove duplicate local API server

* Extract event ordering util

* Remove player TaskAgent reuse

* Align text input with Pipecat mute state

* Use typed text append path

* pipecat 1.3.0

* ui-agent port (pre subagent / worker migration)

Author: jptaylor

.claude/skills/byoa-link/SKILL.md

@@ -147,10 +147,10 @@ Path: `--out` value, or `<main-repo-root>/.env.byoa` if not provided. **Never wr
 Resolve the main repo root with `git rev-parse --path-format=absolute --git-common-dir` — its parent is the main worktree root whether the caller is in the main checkout or a linked worktree. The `env.byoa.example` template also lives at that root.
 
 ```bash
-REPO_ROOT="$(dirname "$(git rev-parse --path-format=absolute --git-common-dir)")"
-OUT_PATH="${OUT_OVERRIDE:-$REPO_ROOT/.env.byoa}"
+PROJECT_ROOT="$(dirname "$(git rev-parse --path-format=absolute --git-common-dir)")"
+OUT_PATH="${OUT_OVERRIDE:-$PROJECT_ROOT/.env.byoa}"
 umask 077
-cp "$REPO_ROOT/env.byoa.example" "$OUT_PATH"
+cp "$PROJECT_ROOT/env.byoa.example" "$OUT_PATH"
 python3 - "$OUT_PATH" "<character_id>" "<ship_id>" "<wake_secret_hex>" <<'PY'
 import sys, pathlib
 path, char_id, ship_id, secret = sys.argv[1], sys.argv[2], sys.argv[3], sys.argv[4]

.claude/skills/init/SKILL.md

@@ -86,8 +86,8 @@ Generate a universe (5000 sectors, seed 1234) and load it plus quest definitions
 ```bash
 set -a && source .env.supabase && set +a
 uv run universe-bang 5000 1234
-uv run -m gradientbang.scripts.load_universe_to_supabase --from-json world-data/
-uv run -m gradientbang.scripts.load_quests_to_supabase --from-json quest-data/
+uv run -m gradientbang.scripts.load_universe_to_supabase --from-json tmp/world-data/
+uv run -m gradientbang.scripts.load_quests_to_supabase
 ```
 
 Redirect output and check for errors. These commands can take a minute.

.claude/skills/load-quests/SKILL.md

@@ -1,6 +1,6 @@
 # Load Quest Data
 
-Loads quest definitions from JSON files in `quest-data/` into Supabase.
+Loads quest definitions from `GRADIENTBANG_QUEST_DATA_DIR` (`data/quests/` by default) into Supabase.
 
 ## Parameters
 
@@ -20,17 +20,17 @@ set -a && source .env.supabase && set +a
 
 Upsert mode (default — updates existing quests, inserts new ones):
 ```bash
-uv run -m gradientbang.scripts.load_quests_to_supabase --from-json quest-data/
+uv run -m gradientbang.scripts.load_quests_to_supabase
 ```
 
 Force mode (wipes all quest definitions and reloads from scratch):
 ```bash
-uv run -m gradientbang.scripts.load_quests_to_supabase --from-json quest-data/ --force
+uv run -m gradientbang.scripts.load_quests_to_supabase --force
 ```
 
 Dry run (validate JSON files without writing to database):
 ```bash
-uv run -m gradientbang.scripts.load_quests_to_supabase --from-json quest-data/ --dry-run
+uv run -m gradientbang.scripts.load_quests_to_supabase --dry-run
 ```
 
 ### 3. Verify
@@ -39,7 +39,7 @@ Confirm the output shows "Success!" and check the stats summary for expected que
 
 ## Important notes
 
-- Each `.json` file in `quest-data/` represents one quest chain. The loader picks up all `*.json` files in the directory.
+- Each `.json` file in `GRADIENTBANG_QUEST_DATA_DIR` represents one quest chain. The loader picks up all `*.json` files in the directory.
 - The loader upserts by quest `code`, so it's safe to re-run after editing quest data.
 - `--force` deletes ALL quest definitions (cascades to steps and subscriptions) before reloading. Player quest progress (`player_quests`, `player_quest_steps`) is NOT affected — but orphaned progress rows will reference deleted step IDs.
 - If you get a PostgREST schema cache error, run: `docker exec supabase_db_gb-world-server psql -U postgres -d postgres -c "NOTIFY pgrst, 'reload schema'"` then retry.

.dockerignore

@@ -35,8 +35,8 @@ client
 tests
 docs
 logs
-world-data
-quest-data
+tmp
+data
 .dockerignore
 docker-compose.yml
 

.gitignore

@@ -1,4 +1,5 @@
 world-data/
+tmp/
 logs/
 .env
 .env.*

CHANGELOG.md

@@ -7,6 +7,17 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.6.0] - 2026-05-26
+
+### Changed
+
+- Centralized runtime configuration in `gradientbang.config` using `pydantic-settings`.
+- Repository structure tidy-up and runtime module reorganization under `src/gradientbang/runtime/`.
+- Migrated to the latest Pipecat SubAgents spec — `PipelineWorker`-hosted `Orchestrator`, bus-based `TaskAgent` workers, and the universal wake-up handshake aligned to the current `pipecat-ai-subagents` API.
+- New-player onboarding now keeps the generated mega-port route as session-scoped private TaskAgent startup context for player-ship tasks, controlled by `BOT_NEW_PLAYER_ONBOARDING`.
+- Local player-ship TaskAgents are now one-task workers like local corp-ship TaskAgents; completed player tasks end and remove their worker instead of reusing an idle pipeline.
+- Text input now waits on Pipecat user-mute events via `app_resources`, matching voice turn sequencing.
+
 ## [0.5.6] - 2026-05-21
 
 ### Fixed

CLAUDE.md

@@ -12,24 +12,28 @@ Gradient Bang is an online multiplayer universe where gameplay and systems are d
 
 Most important code in this repo:
 
-- `src/gradientbang/pipecat_server/bot.py` - pipeline wiring, MainAgent (inline), client message handlers
-- `src/gradientbang/pipecat_server/subagents/` - VoiceAgent, EventRelay, TaskAgent, UIAgent
+- `src/gradientbang/bot.py` - Pipecat session entrypoint and voice pipeline wiring
+- `src/gradientbang/runtime/` - Orchestrator, EventRelay, client messages, task agents, BYOA, bus protocol
+- `src/gradientbang/game/` - game API client and event transport adapters
 - `deployment/supabase/functions/` - all game server logic
 - `client/` - web client for the game
 
 ## Bot architecture
 
-`bot.py` creates all components and wires them together:
+Core runtime shape:
 
-- **MainAgent** (inline in `bot.py`) - `BaseAgent` owning transport pipeline (STT/TTS) with `BusBridgeProcessor`
-- **VoiceAgent** (`subagents/voice_agent.py`) - `LLMAgent` with 16 game tools; spawns TaskAgent children per task, broadcasts game events to bus
-- **TaskAgent** (`subagents/task_agent.py`) - `LLMAgent` with 31 game tools; self-contained autonomous agent, receives events via bus
-- **EventRelay** (`subagents/event_relay.py`) - single game event subscriber, declarative routing engine; feeds VoiceAgent which distributes to TaskAgents via bus
-- **UIAgent** (`subagents/ui_agent.py`) - parallel pipeline branch for autonomous UI control (not on bus)
+- The web client connects to the bot over WebRTC. Audio uses the WebRTC transport; RTVI messages flow both ways for client/server events and custom client messages.
+- `bot.py` builds the live Pipecat voice pipeline: transport, STT, voice LLM, TTS, aggregators, and the `player` `PipelineWorker`.
+- The `player` worker owns Pipecat lifecycle and bus identity. The voice LLM runs inline in this pipeline.
+- `Orchestrator` is a plain Python coordinator attached to the `player` worker. It owns session bootstrap, voice tools, client-message routing, event relay integration, task lifecycle, BYOA, and shutdown.
+- `AsyncGameClient` calls Supabase Edge Functions and manages session-scoped pubsub event delivery.
+- Edge Functions mutate database state and emit game events. The database is the source of truth for world state, ships, corporations, tasks, events, and BYOA config.
+- `EventRelay` receives game events and routes them to RTVI, voice LLM context, and the subagent bus.
+- `VoiceRuntime` binds the voice tool schema to Orchestrator handler methods.
+- `TaskAgent` workers are children of the `player` worker and communicate with Orchestrator over bus messages.
+- BYOA agents use the same bus protocol as in-process task agents, but are externally hosted and woken by the runtime.
 
-Tool schemas are defined once in `src/gradientbang/tools/` and shared by VoiceAgent, TaskAgent, and UIAgent.
-
-See `src/gradientbang/pipecat_server/subagents/CLAUDE.md` for detailed architecture docs.
+Tool schemas live in `src/gradientbang/runtime/tool_schema.py`.
 
 ## Local dev (quick)
 
@@ -48,6 +52,7 @@ See `src/gradientbang/pipecat_server/subagents/CLAUDE.md` for detailed architect
 - To run Supabase edge functions: `npx supabase functions serve --workdir deployment --no-verify-jwt --env-file .env.supabase`.
 - To start the bot: `set -a && source .env.supabase && set +a && uv run bot --host 0.0.0.0`.
 - If you need to run edge functions or start the bot, redirect ALL output to a file. Do NOT use `tee`; use `head`, `tail`, `grep`, etc. to inspect log files.
+- All Python env vars are inventoried in `src/gradientbang/config.py`. When adding or removing an env var anywhere in the Python code, keep that file in sync.
 
 ## Testing