Both goals flip proposed->active at user direction. Activation-freshness
overlap surveys (goals_xref score) recorded as Related: notes: G-024 gains
G-127/G-131/G-137 pointers, G-115 gains G-127/G-141 pointers (goals drafted
since the 2026-07-24 overlap reviews).
Assisted-by: harness=claude; primary-model=claude-fable-5; api-location=anthropic.com
Goal: the runtime-to-vfs-to-executable build mapping moves from the custom line format of src/runtime/mapvfs.config to a toml file parsed with the tomlish package - still supporting explicit per-executable mappings (runtime, vfs folder, output name, kit type) while also expressing generative schemes like the G-023 versioned naming in a single succinct declaration.
Acceptance: a mapvfs toml file parsed via tomlish (no ad-hoc toml parsing) drives the build: every mapping currently active in mapvfs.config is expressible and at least one existing target builds identically from the toml; the G-023 versioned/dev/release-gated output scheme is declared in one entry that expands to its outputs without enumerating versions; malformed or unresolvable entries fail the build with a clear message naming the entry; the legacy .config format is either fully migrated (old parser removed) or explicitly deprecated with documented precedence between the two files.
@ -86,6 +86,12 @@ with the G-014 direction of toml + tomlish for declared configuration.
grammars in one toml family (shared conventions, not two dialects); G-115's
vendorlib_vfs.toml fold/supersede decision should cite this goal's scheme format.
- G-121 (archived) delivered the shared parsed-mapping reader (::punkboot::lib::mapvfs_parse + mapvfs_kit_outputs): the bake kit machinery, bakelist and the bake/bakelist argdoc kit-name choices all consume the model, never the file format - this goal's toml conversion swaps the reader implementation underneath that surface, and bakelist is where its per-entry validation errors surface (runtime/vfs missing rows) - see goals/archive/G-121-bakelist-selective-bake.md
- Related (activation overlap survey 2026-07-31, goals_xref score): G-127 - pairing one vfs
definition with several targets is this format's cross-target consumer (its Scope names the
mapping surface); G-131 - if container becomes a bake-time choice, a mapvfs entry naming a
kit type stops implying a particular runtime (simplification landing on this format);
G-137 - reads punkproject.toml fields at the same bake seam the versioned scheme reads the
project version from.
- G-133 (archived) landed the interim per-kit smoke-require declaration as a 5th
mapvfs.config entry element (list of packages the built kit must plain-require);
the toml conversion is its designated schema home, alongside the verification-set
Scope: src/make.tcl (vfs assembly); src/runtime/vendorlib_vfs.toml (existing per-package declaration surface - fold/supersede settled in the work); src/vfs/ (per-.vfs declaration files + README); punk::mix machinery as touched; src/project_layouts (seeding for derived projects); coordinates with G-067 (artifact sources); G-006 (consent); G-004 (binary-free committed tree)
Goal: a .vfs folder's payload can be DECLARED in a toml definition (sources: suite build products, punkbin runtime/library artifacts via the consent-gated channels, vendor trees) and materialized into the folder by the build - while the folder remains the operative assembly area: undeclared dropped-in files (binary libs/modules included) are preserved with documented precedence, so derived projects with permissive binary policies and gitignored test .vfs folders keep drop-in simplicity with no declaration required.
Acceptance: a punkshell kit .vfs (or demonstration .vfs) builds from a toml declaration reproducing its payload on a clean tree, with declared binary content arriving via consented retrieval or local build products; an undeclared dropped-in file survives re-materialization per the documented precedence; a .vfs with NO declaration builds exactly as today (pure drop-in mode unchanged); the declaration format and precedence rules are documented; the vendorlib_vfs.toml relationship is settled with rationale; the layout store seeds the convention for derived projects.
@ -60,3 +60,9 @@ for telling the two apart).
external content) - G-065's upstreams feed the sources, this goal's declarations
materialize the folder. Keep the schemas aligned.
- G-121 (archived) noted per-kit payload detail as a candidate later addition to bakelist's per-kit view (name filtering doubles as detail) once this goal's declaration surface exists - see goals/archive/G-121-bakelist-selective-bake.md
- Related (activation overlap survey 2026-07-31, goals_xref score): G-127 - owns the platform
axis for payload declarations (whichever of the two lands second adopts the other); this
goal's format lands without a platform axis and records the extension point. G-141 - its
libfetch target derivation consumes whichever declaration surface is current; if this goal
supersedes vendorlib_vfs.toml the derivation reads the successor surface (recorded in its
