Host Awareness and the CLI domain

Write this so someone with no background can follow.

What do I need?

PlayTime (the Scriptbook engine) plus this Equivalence Engine for two different jobs.

Two jobs, not one loop

When Job

Build (CI)

The engine is a compiler. It reads host-probe rules and writes an ordered cascade into PlayTime (probes.generated.json). Pin the rules git revision.

Run (play time)

PlayTime walks that baked cascade and fills a Host Identity Record. Only then may it call this engine for cli.install and other intents.

Forbidden: PlayTime calls this engine to learn family so that it can call this engine. That never starts.

Deadlock cycle crossed out; snapshot then Equivalence Engine bind
Figure 1. Snapshot, then dereference

Wanted growth loop: catalogs get richer → CI bakes a better cascade → PlayTime wakes up on more machines → people write more playbooks → they register more intents and probes → the next bake is richer.

Rules to CI bake to shipped PlayTime to more playbooks back to new catalog rows
Figure 2. Ratchet at build time

Canonical write-up: scriptbook spec/host-awareness.adoc.

family / inherits on filesystem context.sdl files must stay aligned with that record.

CLI domain is a catalog, not a rewrite DAG

--domain code walks version hops and rewrites files.

--domain cli looks up a tool id and returns command rows. --to is a host alias such as windows/winget. Never --to windows/pwsh/msi.

Catalog table versus a forbidden path-segment lattice
Figure 3. Columns, not a cube
argv box for winget install; dashed shell coats are not needed
Figure 4. One suitcase, no costumes

List every compatible row (do not only pick one):

equivalence-engine --domain cli --list gh --rules-dir /path/to/catalog

Optional --to still picks one. Optional format filter is --format winget (a facet), not a path segment.