Summary
silico/partition_data.py exists, is wired into deploy_idf.py, has tests (tests/test_partition_data.py), and its own docstring states the intent plainly:
Data-partition assets for language=c deploy (no free-form esptool essay) … silico deploy plans these after the app image and flashes with esptool only after --yes (same confirm manners as the IDF image) — #79.
It appears nowhere in the gcu-c plate. grep -rn "deploy.data\|assets" silico/plates/gcu-c/ returns nothing — not in silico.toml, not in AGENTS.md, not in install/README.md.
What that cost on a real ship
tig/xuss-c streams a multi-MB PCM track from a SPIFFS partition. Its silico.toml has no [[deploy.data]], and install/README.md instructs the operator to hand-run exactly the wall #79 built the feature to delete:
py -3 tools/gen_spiffs_image.py --idf-path %IDF_PATH% --assets assets --out build/spiffs.bin --size 0xE70000
python -m esptool --chip esp32 -p COMx -b 460800 write_flash --flash_size 16MB 0x190000 build/spiffs.bin
That is a two-command wall in operator-facing docs, which Bedside 2 and 4 forbid, on a path silico deploy --verify cannot verify because it never placed the asset.
And it propagated into product behavior. Because the asset is flashed out-of-band, it can plausibly be absent — so the firmware grew a fallback that plays the boot riff in place of the missing song. The product spec (§4.4) requires the opposite: "refuse playback with a clear link status." A discoverability gap in the plate turned into a silent-degradation defect in the product.
Fix
Partly landed in #115 — commented [[deploy.data]] block in the plate's silico.toml and a note in install/README.md saying not to paste raw esptool write_flash into operator docs.
Still open:
Note for whoever picks this up
The general lesson is worth more than the specific fix: on this spine a feature that the plate does not scaffold or name effectively does not exist, no matter how well it is implemented or tested. Shipping a CLI feature is not done until a plate references it.
Summary
silico/partition_data.pyexists, is wired intodeploy_idf.py, has tests (tests/test_partition_data.py), and its own docstring states the intent plainly:It appears nowhere in the gcu-c plate.
grep -rn "deploy.data\|assets" silico/plates/gcu-c/returns nothing — not insilico.toml, not inAGENTS.md, not ininstall/README.md.What that cost on a real ship
tig/xuss-c streams a multi-MB PCM track from a SPIFFS partition. Its
silico.tomlhas no[[deploy.data]], andinstall/README.mdinstructs the operator to hand-run exactly the wall #79 built the feature to delete:That is a two-command wall in operator-facing docs, which Bedside 2 and 4 forbid, on a path
silico deploy --verifycannot verify because it never placed the asset.And it propagated into product behavior. Because the asset is flashed out-of-band, it can plausibly be absent — so the firmware grew a fallback that plays the boot riff in place of the missing song. The product spec (§4.4) requires the opposite: "refuse playback with a clear link status." A discoverability gap in the plate turned into a silent-degradation defect in the product.
Fix
Partly landed in #115 — commented
[[deploy.data]]block in the plate'ssilico.tomland a note ininstall/README.mdsaying not to paste rawesptool write_flashinto operator docs.Still open:
partition_datawas found by accident.board_profile,parts,product_path, andagents_stageare worth the same check.silico doctorhint when alanguage=cproduct has a non-app data partition inpartitions.csvbut no[[deploy.data]]— that combination is almost always a hand-rolled flash step.silico deploy --verifyshould say out loud that it verified the image only when data assets are undeclared.Note for whoever picks this up
The general lesson is worth more than the specific fix: on this spine a feature that the plate does not scaffold or name effectively does not exist, no matter how well it is implemented or tested. Shipping a CLI feature is not done until a plate references it.