DYNAMIC DEVELOPMENT ROUTING

Domains stay.
Executions rotate.

Domains, subdomains, public contracts and Task Slots are permanent. Individual AI executions are temporary: development resumes from the GitHub record, never from an individual session.

Final authority Owner The owner approves product boundaries and may replace the active coordinator.
Coordination role Wingoria HQ A replaceable task that allocates tranches, serializes shared surfaces and records handoffs.
Source of truth GitHub Domains, Task Slots, APIs, seams, assignments and evidence survive every execution.

PERMANENT WORK IDENTITY

One durable address. Replaceable execution.

A Domain is a permanent general boundary. A Subdomain is an independent module with a versioned API or contract. Every Subdomain has exactly one permanent Task Slot with the same identity. If a Subdomain becomes too large, split the Subdomain; never create two ambiguous slots for one module.

Domain Wingoria.AI

Permanent authority and public contract boundary.

Subdomain = Task Slot Wingoria.AI.Voice

One independent module, one versioned seam and one permanent work address.

Execution Current AI task

Temporary Codex or Claude thread, worker, branch and active tranche.

Checkpoint / handoff GitHub record

The slot survives completion, decline, handoff and worker replacement.

Junior view What is happening?

Purpose, what works now, visible result, blocker, cost/risk, current execution and next step.

AI handoff view How does work continue?

Architecture, APIs, contracts, seams, owned paths, branch/SHAs, tests, evidence and the exact next action.

Persistence rule The page belongs to the Task Slot.

Every execution updates its own data record before completion, decline or handoff.

Bytelaris transition Operational pages move; this map remains.

Bytelaris will later host the task-page and HQ functions. Wingoria keeps this coordinator, domain map and links.

“API” means the versioned public seam: an application port, endpoint, event, job or DTO. It does not require a separate network service. Until Bytelaris takes over, each accepted Task Slot maintains wingoria.com/task?slot=Wingoria.Domain.Subdomain from task-pages/Domain/Subdomain.json. The worker may edit only that Slot record; shared page code remains Wingoria HQ-owned.

Use HQ routing or assign generic execution slots manually. Click one or more Domain cells, choose AI 1, AI 2 or AI 3 and copy the brief. The recipient records its actual execution name only when it accepts. Task Slot assignments live on their dedicated pages. Manual owner assignments override HQ proposals. Proposed (grey) → Sent (yellow) → Accepted (green), Declined (red) or Handoff (orange).

0 domains selected

Wingoria HQ is a replaceable coordination task, not a product domain and not an AI. Every Domain and Subdomain exposes only versioned public seams. Every Subdomain is exactly one permanent Task Slot and admits one active writer at a time. Executions may change only through Proposed, Sent, Accepted, Declined or Handoff transitions recorded in GitHub.

TEMPORARY EXECUTION

Current coordinator briefs.

Wingoria HQ maintains these domain-level briefs from GitHub checkpoints. Detailed implementation status belongs to each permanent Task Slot page. Before editing, every execution must accept its slot and obtain the exact branch, worktree, base SHA and writable-path allowlist.

Coordination Resolve ownership collisions and serialize every protected shared surface. Issue #63 update with worker, branch, worktree, base SHA, allowed paths and merge order. Active
Server · Deployment Review the open root stack and establish the next safe integration and deployment order. SHA-bound review, exact changed paths, green gates and explicit merge/deploy decision. Active
Character · Sojourn · Services Checkpoint current Character, Village and Spine work without touching another domain. Branch/head SHA, changed-path manifest, build/tests, screenshots and every collision listed separately. Awaiting checkpoint
Adventuring · Story · Rules · World AI 3 receives Adventuring, Rules and World; AI 1 receives the Story Engine boundary. Actual worker names appear only after acceptance. One branch per Domain, exact allowlist, Task Slot pages, tests and a separate request for every shared surface. Awaiting confirmation
Combat · Scenarios Keep Unity implementation in Unity; coordinate only required Server contracts and online artifact handoff here. Unity commit/artifact evidence, Server fixture identity and owner visual approval before product acceptance. Active
Socials Define contracts, authenticated identity, presence, matchmaking and the RTC boundary. Read-only architecture and ordered change requests before implementation or provider selection. Queued
GM Define the human-GM Console and activity panels as authorized clients of existing Domain APIs. GM Task Slot split, access model, command matrix and Warden/Metanomicon proposal boundary. Queued