gal/constructionbot
Watch
2
0
Fork
You've already forked constructionbot
 0
Code Issues 8 Pull requests Projects Releases Packages Wiki Activity Actions

T-3 — New gal services scaffold dynamic-nix from the start #12

New issue
Open
opened 2026-08-21 21:47:42 +00:00 by jsutter · 0 comments
jsutter commented 2026-08-21 21:47:42 +00:00
Owner
Copy link

Labels: infrastructure, convention
Depends on: deepnet/dit-client#90, #91. Independent of T-1/T-2.

Decision to record

Every new dynamic app on the gal tenant scaffolds dynamic-nix. Podman
(dynamic-contained) is reserved for workloads that arrive as OCI images DeepNet
cannot repackage — per spec 012 Scope/Out, podman stays supported but is no
longer the path of choice for apps DeepNet packages itself.

Why this needs a ticket rather than a note

ditc scaffold does not default to nix-native. It content-sniffs: empty dir →
static; flake.nix present → dynamic-nix; Containerfile/Dockerfile
present → dynamic-contained. So a greenfield dynamic app silently lands on
podman if a Containerfile happens to exist. Until that divergence from spec 012
is reconciled upstream, the correct archetype must be passed explicitly:

ditc scaffold <slug> --archetype dynamic-nix --client gal

Immediate application

The planned Python document-intelligence service (Plangrep client — the shared
dependency for roadmap Arcs 2, 4, and 5) scaffolds dynamic-nix on day one.

Two things this buys that the podman path does not:

  • No 512 MB container cap. PyMuPDF and region-alignment work need more headroom,
    and the nix path's limits (once #91 lands) are set per-app rather than
    inherited from a generator default.
  • No language constraint. The dynamic-nix contract is only "emit bin/<slug>,
    bind 127.0.0.1:<derived-port>." The stock ditc scaffold template for this
    archetype is Python. chess proves the Rust path; the Python path is the
    template default.

Acceptance criteria

  • The decision is recorded in docs/spec-registry.md's decision ledger as a
    numbered D- entry.
  • The next app scaffolded on the gal tenant uses --archetype dynamic-nix and
    its manifest.yaml reflects it.
  • The Python service's flake.nix packages its dependencies hermetically — no
    network pip install at build time.
**Labels:** `infrastructure`, `convention` **Depends on:** `deepnet/dit-client#90`, `#91`. Independent of T-1/T-2. ### Decision to record Every new dynamic app on the gal tenant scaffolds `dynamic-nix`. Podman (`dynamic-contained`) is reserved for workloads that arrive as OCI images DeepNet cannot repackage — per spec 012 Scope/Out, podman stays supported but is no longer the path of choice for apps DeepNet packages itself. ### Why this needs a ticket rather than a note `ditc scaffold` does not default to nix-native. It content-sniffs: empty dir → `static`; `flake.nix` present → `dynamic-nix`; `Containerfile`/`Dockerfile` present → `dynamic-contained`. So a greenfield dynamic app silently lands on podman if a Containerfile happens to exist. Until that divergence from spec 012 is reconciled upstream, the correct archetype must be passed explicitly: ditc scaffold <slug> --archetype dynamic-nix --client gal ### Immediate application The planned Python document-intelligence service (Plangrep client — the shared dependency for roadmap Arcs 2, 4, and 5) scaffolds `dynamic-nix` on day one. Two things this buys that the podman path does not: - No 512 MB container cap. PyMuPDF and region-alignment work need more headroom, and the nix path's limits (once #91 lands) are set per-app rather than inherited from a generator default. - No language constraint. The dynamic-nix contract is only "emit `bin/<slug>`, bind `127.0.0.1:<derived-port>`." The stock ditc scaffold template for this archetype is Python. `chess` proves the Rust path; the Python path is the template default. ### Acceptance criteria - The decision is recorded in `docs/spec-registry.md`'s decision ledger as a numbered `D-` entry. - The next app scaffolded on the gal tenant uses `--archetype dynamic-nix` and its `manifest.yaml` reflects it. - The Python service's `flake.nix` packages its dependencies hermetically — no network `pip install` at build time.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
v0.1.2
v0.1.1
v0.1.0
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
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
gal/constructionbot#12
No description provided.