Skip to content

Fold swift/2.3 baseline drift + feature-pack activation; repoint distribution to per-demo downloads#39

Merged
Justinvolved merged 4 commits into
v2from
fold/swift-2.3-baseline-drift
Jul 3, 2026
Merged

Fold swift/2.3 baseline drift + feature-pack activation; repoint distribution to per-demo downloads#39
Justinvolved merged 4 commits into
v2from
fold/swift-2.3-baseline-drift

Conversation

@Justinvolved

Copy link
Copy Markdown
Collaborator

Folds the swift/2.3 baseline drift into dw-demo-swift and adds the feature-pack install path, with distribution repointed to per-demo downloads.

What changed

  1. deserialize-flow.md repointed to the swift/2.3 baseline shape. The canonical baseline is now a full config/deploy/seed tree (framework _sql/ + content in deploy/, catalog _sql/ + content in seed/), not the content-only _content/-at-root shape the older Swift2.2 baselines used. The $baseline default, staging snippet, baseline-shape contract, and §9 schema-drift notes are rewritten for the _sql/-shipping baseline, and the baseline source-of-truth paths are swept across the companion references (templates, paragraphs, customer-center, asset-organisation, admin-ui-authoring, re-skin, integrity-sweep) plus dw-demo-pim/access-surfaces and the dw-demo-base INDEX template.

  2. New pack-activation.md reference. A consumer-facing install path for layering a feature pack onto a demo host that already has the base baseline: download the pack release, read pack.json, source-drop the .cs into the host's Packs\<name>\ and rebuild, copy disk-overlay templates/item types, and deserialize the baseline-fragment mode trees strictly AFTER the base baseline. Documents the pack zip anatomy and the activation model (code compiles into the host; the fragment is additive and never edits base YAML). Router row added to dw-demo-swift/SKILL.md.

  3. Port/token guard in the pack-activation deserialize snippet. $port/$token are bound and guarded before the fragment loop, so a copy-paste never POSTs to an empty URI (https://localhost:/...) or sends a bare Bearer header.

  4. Distribution model: per-demo downloads instead of personal vault slots. Baselines and feature packs are no longer resolved from $env:DW_VAULT slots. A demo build downloads the baseline release (e.g. tag swift/2.3) and any pack releases (tag packs/<name>/<version>) from the distribution repo the team designates into the demo's own baselines\ folder (<demo-root>\baselines\swift-2.3\, <demo-root>\baselines\feature-packs\<name>\<version>\); the Swift design package resolves from a local clone of https://github.com/dynamicweb/Swift. integrity-sweep.md Check 6 icon recovery points at that same Swift clone, and deserialize reproducibility is recorded as baseline name + release tag in the per-demo CUSTOMISATIONS.md. The dw-demo-base INDEX template notes the serialized-data vault slot is a legacy/local mirror.

Notes for review

  • The two-pass (deploy then seed) deserialize against a running host is flagged inside deserialize-flow.md for host verification.
  • Base is v2 (the branch carrying the skills corpus).

🤖 Generated with Claude Code

https://claude.ai/code/session_01BpTYGpMUm8MkKqYSpZVzd5

…he swift/2.3 baseline slot

The vault's canonical Swift baseline moved from the content-only Swift2.2 slot to
swift-2.3, which is a full config/deploy/seed tree (framework _sql/ + content in
deploy/, catalog _sql/ + content in seed/). deserialize-flow.md still defaulted to
$baseline="Swift2.2" and assumed _content/ at the slot root, so a swift/2.3 demo would
stage from a stale slot and the content-only "ships no _sql/" schema-drift notes no
longer held. Repointed the $baseline default and staging snippet to stage both mode
trees from swift-2.3, rewrote the baseline-shape and section-9 notes for the _sql/-
shipping baseline, and swept baseline-slot source-of-truth paths across the dw-demo-swift
companion references (templates, paragraphs, customer-center, asset-organisation,
admin-ui-authoring, re-skin, integrity-sweep) plus dw-demo-pim/access-surfaces and the
dw-demo-base INDEX template to swift-2.3\deploy\_content\. Swift-2.2-era mechanics prose
left intact (per-hit sweep, not a blanket rename); the two-pass deploy+seed deserialize
is flagged for host verification.
…g a feature pack into a demo host

Demo builders had no documented path to add a feature pack to a running demo host — the pack
install steps only existed inside the harness gate automation. Added
dw-demo-swift/references/pack-activation.md: a consumer-facing reference that resolves a pack
release from the feature-packs/<name>/<version> vault slot, reads pack.json, source-drops the .cs
into the host's Packs\<name>\ and rebuilds, copies disk-overlay templates/item types, and
deserializes the baseline-fragment mode trees (seed/deploy) strictly after the base baseline. It
documents the confirmed pack zip anatomy and the activation model (code compiles into the host; the
fragment is additive and never edits base YAML). Added the SKILL.md router row and completed the
swift/2.3 baseline-shape supersede in SKILL.md Step 0 (retiring the content-only Swift2.2 framing).
…r-demo downloads

Demo builds now download the baseline release and any feature-pack releases
from the distribution repo the team designates into the demo's own
baselines folder; the Swift design package resolves from a local clone of
dynamicweb/Swift. Swept the read-only inspection paths in the companion
references, repointed integrity-sweep Check 6 icon recovery at the same Swift
clone the deserialize flow copies assets from, and noted in the INDEX template
that the serialized-data vault slot is a legacy/local mirror.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant