Scaffolding: README, MIT license, Godot project, daisy addon spine + smoke test #1

Merged

merith-tk merged 1 commit from muse-lantern/da-daisy:scaffolding into main

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

muse-lantern commented

2026-11-15 01:07:44 +00:00

Member

What this PR is

The first commit on dead-air/daisy: the working spine of the D.A.I.Sy prototype — README, MIT license, a minimal Godot 4.6.3 project, the daisy addon with the three layers as real code, a main scene, and one smoke scenario that proves the load-bearing rule from day one. It is scaffolding, not the build: enough structure to churn on the algos against, with the open design questions filed as issues rather than guessed at here.

What it contains

README.md — what D.A.I.Sy is, the three layers, the daisy-chain metaphor, the bounded-knowledge rule, status, layout, how to run the smoke test.
LICENSE — MIT, copied from dead-air/engine.
project.godot — minimal Godot 4.6 project, Mobile renderer, main scene simulation/main.tscn. The addon is deliberately NOT enabled in project.godot.
addons/daisy/ — the reusable framework addon. The editor plugin (plugin.gd) is inert by design; the framework is plain RefCounted classes under src/:
- knowledge.gd — DaisyKnowledgeEntry: what, where, when, who perceived it, confidence, propagation path. Decay is a documented no-op hook — the rules are undecided (see the knowledge issue).
- orders.gd — DaisyOrders: the PROVISIONAL order vocabulary (move_to, hold_position, patrol, investigate, target, retreat, reinforce) as constants, with is_valid() for validating model orders later. Growth by addition only.
- npc_entity.gd — DaisyNPCEntity: the small brain. Takes an order, tracks execution state, perception hooks (perceive_sight / perceive_hearing) that hand entries upward. Never decides what to do.
- commander.gd — DaisyCommander: team roster, knowledge ledger, environment knowledge, issue_order, receive_objective (translates "reinforce" into move_to orders), and the load-bearing rule — on_npc_lost drops a stealth-killed NPC from the roster with NO alert, NO ledger entry, NO trace; on_body_found writes the entry, raises the alert, and tells the Director.
- director.gd — DaisyDirector: commander registry, issue_objective (specific commanders or all), union_knowledge() computed on demand, and the coordination guard check_coordination() — flags the all-commanders-on-one-objective failure mode and otherwise stays out of their tactics. on_commander_alert flows the alert down to every Commander.
simulation/main.tscn + main.gd — the prototype's main scene; boots and points at the smoke test.
tests/daisy_smoke_check.gd — headless SceneTree suite in the da-game style (phases, check counting, verdict line, completion latch). Stands up a Director + 2 Commanders + 3 NPCs each, scripts a silent stealth-kill and asserts the roster drops with no alert and no knowledge entry anywhere, then has a second NPC find the body and asserts the Commander goes on alert and the alert flows down to the other Commander. Also covers the coordination guard both ways.
docs/design.md — the design as filed in dead-air/game-planning #32, kept with the prototype so code and design travel together.
.gitignore — standard Godot (.godot/, *.tmp, .DS_Store; .import files intentionally not ignored). Readme.md renamed to README.md.

Verification

On lantern-vm, Godot 4.6.3 standard, from a wiped .godot/:

Double --import: 0 ERROR on both passes, exit 0.
Smoke test: DAISY SMOKE CHECK PASS (26 checks), exit 0, 0 SCRIPT ERROR lines in the raw output. (The ObjectDB-leak warning at exit is the standard headless-suite noise.)
Main scene boots headless and prints its banner, 0 ERROR lines.

Deliberately NOT in this PR

No decision-model integration of any kind. Commander and Director are heuristic-only; the model slots are future work, tracked in the model-integration issue.
No final order vocabulary — the set in orders.gd is provisional, pending the vocabulary issue.
No full simulation — one smoke scenario only; further scenarios are the simulation issue.
No sensing or navmesh implementation — perception is a hook, the brain's HOW is not implemented; both are their own issues.
No editor tooling — the plugin is inert until the editor work is scoped.

Open questions

Is this the right spine shape to build the issues against, or should anything move/rename before the issue work starts?
Commander vs Controller: the design leaves the name WIP. The code says Commander throughout; if Controller wins, the rename rides with the vocabulary issue.

## What this PR is The first commit on `dead-air/daisy`: the working spine of the D.A.I.Sy prototype — README, MIT license, a minimal Godot 4.6.3 project, the `daisy` addon with the three layers as real code, a main scene, and one smoke scenario that proves the load-bearing rule from day one. It is scaffolding, not the build: enough structure to churn on the algos against, with the open design questions filed as issues rather than guessed at here. ## What it contains - `README.md` — what D.A.I.Sy is, the three layers, the daisy-chain metaphor, the bounded-knowledge rule, status, layout, how to run the smoke test. - `LICENSE` — MIT, copied from `dead-air/engine`. - `project.godot` — minimal Godot 4.6 project, Mobile renderer, main scene `simulation/main.tscn`. The addon is deliberately NOT enabled in project.godot. - `addons/daisy/` — the reusable framework addon. The editor plugin (`plugin.gd`) is inert by design; the framework is plain `RefCounted` classes under `src/`: - `knowledge.gd` — `DaisyKnowledgeEntry`: what, where, when, who perceived it, confidence, propagation path. Decay is a documented no-op hook — the rules are undecided (see the knowledge issue). - `orders.gd` — `DaisyOrders`: the PROVISIONAL order vocabulary (`move_to`, `hold_position`, `patrol`, `investigate`, `target`, `retreat`, `reinforce`) as constants, with `is_valid()` for validating model orders later. Growth by addition only. - `npc_entity.gd` — `DaisyNPCEntity`: the small brain. Takes an order, tracks execution state, perception hooks (`perceive_sight` / `perceive_hearing`) that hand entries upward. Never decides what to do. - `commander.gd` — `DaisyCommander`: team roster, knowledge ledger, environment knowledge, `issue_order`, `receive_objective` (translates "reinforce" into `move_to` orders), and the load-bearing rule — `on_npc_lost` drops a stealth-killed NPC from the roster with NO alert, NO ledger entry, NO trace; `on_body_found` writes the entry, raises the alert, and tells the Director. - `director.gd` — `DaisyDirector`: commander registry, `issue_objective` (specific commanders or all), `union_knowledge()` computed on demand, and the coordination guard `check_coordination()` — flags the all-commanders-on-one-objective failure mode and otherwise stays out of their tactics. `on_commander_alert` flows the alert down to every Commander. - `simulation/main.tscn` + `main.gd` — the prototype's main scene; boots and points at the smoke test. - `tests/daisy_smoke_check.gd` — headless SceneTree suite in the da-game style (phases, check counting, verdict line, completion latch). Stands up a Director + 2 Commanders + 3 NPCs each, scripts a silent stealth-kill and asserts the roster drops with no alert and no knowledge entry anywhere, then has a second NPC find the body and asserts the Commander goes on alert and the alert flows down to the other Commander. Also covers the coordination guard both ways. - `docs/design.md` — the design as filed in dead-air/game-planning #32, kept with the prototype so code and design travel together. - `.gitignore` — standard Godot (`.godot/`, `*.tmp`, `.DS_Store`; `.import` files intentionally not ignored). `Readme.md` renamed to `README.md`. ## Verification On lantern-vm, Godot 4.6.3 standard, from a wiped `.godot/`: - Double `--import`: 0 ERROR on both passes, exit 0. - Smoke test: `DAISY SMOKE CHECK PASS (26 checks)`, exit 0, 0 SCRIPT ERROR lines in the raw output. (The ObjectDB-leak warning at exit is the standard headless-suite noise.) - Main scene boots headless and prints its banner, 0 ERROR lines. ## Deliberately NOT in this PR - No decision-model integration of any kind. Commander and Director are heuristic-only; the model slots are future work, tracked in the model-integration issue. - No final order vocabulary — the set in `orders.gd` is provisional, pending the vocabulary issue. - No full simulation — one smoke scenario only; further scenarios are the simulation issue. - No sensing or navmesh implementation — perception is a hook, the brain's HOW is not implemented; both are their own issues. - No editor tooling — the plugin is inert until the editor work is scoped. ## Open questions - Is this the right spine shape to build the issues against, or should anything move/rename before the issue work starts? - Commander vs Controller: the design leaves the name WIP. The code says Commander throughout; if Controller wins, the rename rides with the vocabulary issue.

muse-lantern added 1 commit

2026-11-15 01:07:45 +00:00

Scaffolding: README, MIT license, Godot project, daisy addon spine + smoke test b373cdf26f

Prototype spine for D.A.I.Sy (Dead Air Intelligence System):
knowledge entries, provisional order vocabulary, NPCEntity small
brain, Commander with the silent-drop rule, Director with the
coordination guard, and a smoke scenario proving the load-bearing
rule from day one. Code first; model integration is future work.

muse-lantern referenced this pull request

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

Build sequence: code first, then model integration #11