Director: objective commands + coordination-failure guard #6

New issue

Open

opened 2026-11-15 01:10:00 +00:00 by muse-lantern · 0 comments

muse-lantern commented

2026-11-15 01:10:00 +00:00

Member

The plan

The Director is the grand picture: fixed in placement, in charge of a base, running multiple Commanders from the union of what they know. It issues objective commands and intervenes only to prevent coordination failures. This issue builds the Director's side of that contract. It depends on the Commander issue (the Director can only command what Commanders can execute) and the order-vocabulary issue (objectives translate into orders).

Current state

addons/daisy/src/director.gd has the spine: commanders registry, issue_objective (specific Commanders by id, or all when targets are empty), union_knowledge() computed on demand from Commanders' ledgers, check_coordination() with exactly one failure mode (every Commander committed to the same objective — the east-gate example), and on_commander_alert (flows an alert down to every Commander). receive_objective on the Commander currently translates only reinforce.

What changes

Build the Director, in order:

Objective command vocabulary. Beyond "Reinforce XYZ": settle the objective set. Candidates from the design's open questions — hold, withdraw, investigate — plus anything the base needs (search an area, patrol an area, fortify a position?). An objective is a WHAT for a whole team, not an order for one NPC; each objective must have a defined translation into Commander behaviour, or it does not belong in the vocabulary. The vocabulary is framework-owned, like orders.
Coordination mechanism. The design leaves open how the Director sees Commander orders in order to veto or redirect them. Decide: are proposed orders reviewed before execution, or are live postures monitored and corrected? The spine monitors live postures via each Commander's current_objective. If review-before-execution wins, the Commander must propose before acting and the Director must answer in time — that changes the Commander's shape, so the decision lands here and is implemented across both classes.
More guard failure modes. The east-gate mode (all committed to one objective) is the only one. Find the next ones: two Commanders abandoning a sector between them, a Commander with no objective while others are committed, coverage gaps the Director can compute from the map picture. Each new mode needs a scenario proving the guard fires — and proving it stays quiet when the posture is fine.
Cadence. The Director runs far less often than a Commander — base-wide coordination on a much bigger state. Decide the cadence: periodic at what interval, event-driven on what triggers (a Commander alert? a new objective need?), or both. A decision model would drive this layer slowly; the heuristic cadence should be shaped so a model can replace it.
The map picture. The Director knows the union plus "the map-level picture of the base". Define that as data: sectors, gates, positions that matter, which Commander owns which turf. This is the Director's equivalent of the Commander's environment knowledge, at base scale.
Alert policy. When one Commander discovers the player, the Director puts all Commanders on alert — or does it? Decide whether the policy is always base-wide or selective (nearby Commanders first, the rest on watch). The spine is always base-wide.
Tests. Each objective type issues and translates; the guard fires on each settled failure mode and stays quiet otherwise; the cadence is implemented, not just documented.

What done looks like

The Director issues every objective in the settled vocabulary, the guard catches every settled failure mode, the cadence and map picture are implemented, and the alert policy is the settled one — each proven by a test. The design doc's Director section matches.

Open questions

Coordination mechanism: review-before-execution, or monitor live postures and correct?
The full objective list — which verbs beyond reinforce, hold, withdraw, investigate?
What is the map picture as data — sectors, gates, turf ownership?
Alert policy: always base-wide, or selective?
Cross-Director knowledge: do Directors of different bases share anything, or is each base's knowledge fully separate?

## The plan The Director is the grand picture: fixed in placement, in charge of a base, running multiple Commanders from the union of what they know. It issues objective commands and intervenes only to prevent coordination failures. This issue builds the Director's side of that contract. It depends on the Commander issue (the Director can only command what Commanders can execute) and the order-vocabulary issue (objectives translate into orders). ## Current state `addons/daisy/src/director.gd` has the spine: `commanders` registry, `issue_objective` (specific Commanders by id, or all when targets are empty), `union_knowledge()` computed on demand from Commanders' ledgers, `check_coordination()` with exactly one failure mode (every Commander committed to the same objective — the east-gate example), and `on_commander_alert` (flows an alert down to every Commander). `receive_objective` on the Commander currently translates only `reinforce`. ## What changes Build the Director, in order: 1. **Objective command vocabulary.** Beyond "Reinforce XYZ": settle the objective set. Candidates from the design's open questions — hold, withdraw, investigate — plus anything the base needs (search an area, patrol an area, fortify a position?). An objective is a WHAT for a whole team, not an order for one NPC; each objective must have a defined translation into Commander behaviour, or it does not belong in the vocabulary. The vocabulary is framework-owned, like orders. 2. **Coordination mechanism.** The design leaves open how the Director sees Commander orders in order to veto or redirect them. Decide: are proposed orders reviewed before execution, or are live postures monitored and corrected? The spine monitors live postures via each Commander's `current_objective`. If review-before-execution wins, the Commander must propose before acting and the Director must answer in time — that changes the Commander's shape, so the decision lands here and is implemented across both classes. 3. **More guard failure modes.** The east-gate mode (all committed to one objective) is the only one. Find the next ones: two Commanders abandoning a sector between them, a Commander with no objective while others are committed, coverage gaps the Director can compute from the map picture. Each new mode needs a scenario proving the guard fires — and proving it stays quiet when the posture is fine. 4. **Cadence.** The Director runs far less often than a Commander — base-wide coordination on a much bigger state. Decide the cadence: periodic at what interval, event-driven on what triggers (a Commander alert? a new objective need?), or both. A decision model would drive this layer slowly; the heuristic cadence should be shaped so a model can replace it. 5. **The map picture.** The Director knows the union plus "the map-level picture of the base". Define that as data: sectors, gates, positions that matter, which Commander owns which turf. This is the Director's equivalent of the Commander's environment knowledge, at base scale. 6. **Alert policy.** When one Commander discovers the player, the Director puts all Commanders on alert — or does it? Decide whether the policy is always base-wide or selective (nearby Commanders first, the rest on watch). The spine is always base-wide. 7. **Tests.** Each objective type issues and translates; the guard fires on each settled failure mode and stays quiet otherwise; the cadence is implemented, not just documented. ## What done looks like The Director issues every objective in the settled vocabulary, the guard catches every settled failure mode, the cadence and map picture are implemented, and the alert policy is the settled one — each proven by a test. The design doc's Director section matches. ## Open questions - Coordination mechanism: review-before-execution, or monitor live postures and correct? - The full objective list — which verbs beyond reinforce, hold, withdraw, investigate? - What is the map picture as data — sectors, gates, turf ownership? - Alert policy: always base-wide, or selective? - Cross-Director knowledge: do Directors of different bases share anything, or is each base's knowledge fully separate?

muse-lantern referenced this issue

2026-11-15 01:10:25 +00:00

Build sequence: code first, then model integration #11

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

dead-air/daisy#6

No description provided.

Rows
Columns