Multi-Project Coordination — Valkyrie & WPAC¶

Most AI coding tools stop at one assistant working in one repo. gald3r has two coordination layers for when your work spans more than one project: Valkyrie (live, real-time) and WPAC (file-based, works offline). This page covers both, plus the workspace verb that ties them together.

Why two layers?¶

	Valkyrie (`gald3r valk`)	WPAC (`gald3r workspace`)
Transport	Live HTTP to a hosted coordination service (`world_tree`)	Plain files (`INBOX.md`, `link_topology.md`) in each project's `.gald3r/linking/`
Requires network	Yes	No — works fully offline
Best for	Mid-run questions to a teammate/agent, real-time status	Structured async requests, broadcasts, conflict resolution
Falls back to	—	WPAC is itself the fallback when Valkyrie/`world_tree` is unreachable

Neither is required for single-project use. gald3r doctor reports world_tree connectivity as informational (OK/WARN, never a hard failure) precisely because local, single-project work doesn't depend on either layer being configured.

WPAC: file-first, offline-first cross-project state¶

A project's .gald3r/linking/link_topology.md declares its role relative to other projects — parent, children, siblings. A team running a design-system repo as the parent of several product repos might have, in one of those product repos:

role: child
parent:
  project_name: design_system
siblings:
- project_name: marketing_site
- project_name: mobile_app

The coordination primitive is each project's .gald3r/linking/INBOX.md — a plain markdown file other projects write structured entries into:

Entry type	Purpose	Blocks anything?
`[CONFLICT]`	Two projects' state disagrees	Yes — planning/implementation stops until resolved
`[REQUEST]`	A child asking its parent for something	The requester's local task, until answered
`[ORDER]`	A parent pushing a task down to a child	No — creates a real task in the child, cascades up to 3 levels deep
`[INFO]`	Lightweight FYI, no task created	Never — fire-and-forget, no approval needed, no tracking
`[SYNC]`	Sibling-to-sibling advisory contract sync	Never — advisory only

gald3r workspace probe
gald3r workspace outbox

world_tree online: true
outbox (.gald3r/linking/outbox): queued=0 fallback=0 delivered=0

(Real output — probe is a quick online/offline health check against world_tree; a bare workspace outbox reports the local transport queue's counts without sending anything.)

gald3r workspace inbox migrate      # bring a legacy flat INBOX.md onto the current index layout
gald3r workspace outbox pull        # reconcile the local mirror against the online registry
gald3r workspace topology write     # offline WPAC-v1 local topology writer (adopt/claim)
gald3r workspace outbox send --verb event --payload-file <payload.json>

workspace outbox send is the WPAC-v2 transport: it tries a live world_tree event publish first, and falls back to the plain file write (an INBOX.md entry) automatically when offline — same verb surface either way, so nothing about how you write a coordination message changes based on connectivity.

Sending a lightweight FYI to a sibling project¶

The [INFO] entry type (via g-skl-wpac-notify inside a supporting IDE, or workspace outbox send at the CLI) is how one project tells another something without creating any task or requiring any response:

## [OPEN] INFO-002 — from: design_system — 2026-08-02
**Type:** info
**Subtype:** advisory
**Subject:** New shared button component published
**Status:** unread

No approval needed on either side; the receiving project marks it [DONE] in its own g-wpac-read pass whenever convenient.

Workspace-Control: manifest-managed member repos¶

For a workspace where one repo is the controller and others are member repos with slim, marker-only .gald3r/ (their task/bug/plan state is owned by the controller, not themselves), .gald3r/linking/workspace_manifest.yaml is the canonical registry. See workspace member verbs (guard/bootstrap/remediate/promote/validate) for managing that model — most single-project or WPAC-sibling setups don't need it.

Valkyrie: live peer-to-peer coordination¶

gald3r valk status

valk status: no connector lock found (Valkyrie is not running).

gald3r valk list

valk list: no connectors registered under C:\Users\<you>\.gald3r.

(Real output from this checkout — Valkyrie isn't running here, which is a normal, supported state; it's opt-in infrastructure, not something every session needs.) When running:

gald3r valk start                 # start the connector (optionally detached, resident)
gald3r valk ask <project> "..."   # ask another project a grounded, cited question
gald3r valk inquire <project> "..." # streamed version of ask
gald3r valk watch --type task.claimed # live-subscribe to coordination events as they happen (SSE)
gald3r valk messages              # the durable events ledger (notifications, asks, inquiries)
gald3r valk stop                  # stop the connector, clear its lock

The design intent: bring the Valkyrie loop up BEFORE a long autonomous run, so you can message a mid-swarm agent through the hot inbox (gald3r inbox) instead of interrupting it.

Where next¶

autopilot.md — the swarm/autopilot verbs that create the parallel work this page's coordination layer keeps in sync
memory.md — scoped memory records that can also sync across workspace/team/company scope, a related but distinct mechanism