Fold demo-build learnings: hosted lying-success API traps + Swift 2.4 authoring recipes

[Justinvolved]

Folds a hosted-demo polish session's learnings. Version 4.11.5.

Hosted lying-success (dw-demo-base/references/online-mode.md)

• IndexBuilderSave round-trips status: ok while the /Files/System/Repositories/** XML write is ACL-denied — assert the IndexBuilderByName readback, not the ok. Added to the hosted failure-mode list with a mandatory read-after-write on repository-config saves.
• Full BuildIndex reads EcomGroupProductRelation through an app-lifetime cache — after a relation write the canonical order is recycle-first, then Full build; the rebuild alone no-ops and reads as "API index builds are dead on this host".
• changeversion.txt fires on a CHANGED token, not on presence (restart ladder rung 3) — re-uploading the current value is a silent no-op; write a distinct value every time.

Commerce shop reads (foundational/commerce-catalog.md)

• GetShopById returns a {id,name,permission} stub — the full model comes only from the namespaced GetShopByIdQuery; saving the stub clobbers the omitted fields.
• ShopSave without an explicit UsageType defaults ShopType=0 (none), hiding the shop from every typed admin list. Pointer added from dw-demo-pim canonical-setup-order step 2.

Scheduled tasks (dw-extend-scheduled-tasks/SKILL.md)

• RunSqlScheduledTaskAddIn is write-only — no resultset, no message text, empty lastException even for SELECT 1/0. Read-verify with assertion SQL (IF <cond> RAISERROR).

Swift 2.4 authoring

• Facet sidebar is a 2-column grid row, not a Layout-field toggle (foundational/swift-building.md §3).
• Repeater children live in ItemType_*_Item rows via ItemList/ItemListRelation (storage-shape truth retained), and are created + edited through POST /Admin/Api/ParagraphSave — see the Correction section below (foundational/content-modelling.md §2).
• Conditional-collapse CSS must use flat sibling :has()/:not(:has()) pairs — nested :has() is invalid and silently dropped — and needs !important to beat the Swift grid attribute-selector specificity floor (dw-demo-swift/re-skin.md).

Validator: python3 scripts/validate-skills.py → 0 errors, 0 warnings. Sanitize grep packs (names/hosts/keys, session-time, customer paths) clean across the staged diff and the commit message.

---

Correction — #20 repeater-child edit path (empirically re-proven)

The original "Repeater children … unreachable through the Management API — editable only by guarded SQL plus a recycle" claim (Foundry issue #20) was wrong and has been corrected.

Proven end-to-end on the Foundry harness host (Swift 2.4 baseline restored, DW 10.28.1): the admin Visual Editor's slide editor is a SPA client of /Admin/Api. Captured its save call and replayed it headlessly (Bearer token, no browser) to CREATE a Swift-v2_Slider child slide and then EDIT it in place — no SQL, no recycle — and the storefront rendered both changes on the next GET.

Proven recipe — POST /Admin/Api/ParagraphSave?Query.Type=GetParagraphById (Bearer):

• Parent list field ContentItem|Swift-v2_Slider|General|Items[] carries child entries.
• Child identity is ItemId: "" creates, an existing id (e.g. "1") edits in place (verified count-stable).
• Field values ride in the ModelRawData JSON string keyed RelationItem|Swift-v2_Slider_Item|General|<Field>; RelationItem.Groups is sent empty.
• No recycle — the save fires DW's cache invalidation.
• ParagraphSave is a lying-success surface for this shape (a malformed child returns ok, creates nothing, and can zero the parent list pointer) → round-trip-verify.

Doctrine change — retire the SQL-via-scheduled-task / SQL-direct content motion

Eradicated the "escape to SQL (direct, or via RunSqlScheduledTaskAddIn) when the API gets hard" reflex from the demo corpus. The admin UI is API-first — capture the UI's /Admin/Api call and replay it (MCP → Management API); file a learning rather than reaching for SQL.

• dw-demo-swift/references/sql-direct-seeding.md → deprecation stub (file kept; validator green).
• dw-demo-swift/SKILL.md → dropped the "SQL-direct content seeding" trigger; routing rewritten (manifest regenerated).
• foundational/data-access.md "SQL-direct content seeding" → reframed as forensic/teardown reference, not an authoring recipe.
• dw-extend-scheduled-tasks/SKILL.md → kept the RunSql write-only / assertion-SQL platform truth as a developer diagnostic; added a guard that demo/content editing must not use it.
• Scope note: the ERP DB-mock's between-demo RESET fixture task (dw-demo-erp) is a deliberate state-reset, not a content-authoring escape hatch — left intact.

Commits: 1d6778a (Phase B, #20 fix) · cc1b147 (Phase C, doctrine sweep).