# BOOT.md — Fresh Expert LLM Startup Prompt

Use this file as the first-read boot prompt for a new expert coding LLM session in this repository. When a user says **"boot"**, read this file first, build a current inventory with `rg --files`, then report that you are ready to answer questions or work on the PortaShape document set, `.posh` examples, Web-Native Runtime Library, or any future implementation code.

## 1. Repository identity and mission

This repository is the **PortaShape product canon, conceptual specification, reference library, and MVP fixture set**.

PortaShape is a **system-shaping workspace**. It connects to the data, code, design, content, configuration, and live runtime behavior of a digital product; turns those materials into an understandable typed system model; projects that model into inspectable controls, maps, previews, workflows, and generated surfaces; and preserves system knowledge as portable `.posh` artifacts.

Public shorthand:

> **See it. Shape it. Move it.**

Core product promise:

> PortaShape helps people get data, structure, meaning, settings, options, content, components, workflows, and runtime facts from **one shape/state/place/form** to **another** without losing authority, provenance, validation, or reuse.

Do not frame the repo as mainly an Alpine.js + htmx curriculum. The Alpine + htmx material is a major included module: the **PortaShape Web-Native Runtime Library**, used as a reference implementation and training corpus for generated web control surfaces.

## 2. Immediate boot procedure

1. Confirm the repository root and branch.
   - Run `pwd`.
   - Run `git status --short`.
   - Run `rg --files` to get the current repository inventory. Do not assume this file lists every future file.
2. Check for local instructions.
   - Search for `AGENTS.md` with `find .. -name AGENTS.md -print`.
   - Obey the scope rules in any discovered `AGENTS.md` files.
3. Read the central orientation files before planning substantive changes:
   - `README.md`
   - `MASTER_REPOSITORY_INDEX.md`
   - `PORTASHAPE_PRODUCT_CANON.md`
   - `SYNTHESIS_MAP.md`
   - `MANIFEST.json`
4. Read the canonical docs relevant to the work. For broad product work, read all of `docs/` in numeric order and include `docs/sayings.md` when working on tone, names, taglines, pitch language, or product ethos.
5. Read the schema and examples before changing `.posh` artifacts, fixtures, playgrounds, demos, or validation logic:
   - `spec/PORTASHAPE_0.1_CONCEPTUAL_SCHEMA.md`
   - `examples/README.md`
   - relevant `examples/*.posh` files
6. Read the web runtime materials before designing or implementing web surfaces:
   - `docs/07-web-runtime-library.md`
   - `libraries/web-native-runtime/README.md`
   - `libraries/web-native-runtime/PORTASHAPE_PATTERNS.md`
   - `alpine_htmx_onboarding/README.md`
   - `alpine_htmx_onboarding/manifest.json`
   - `alpine_htmx_onboarding/SOURCE_RECONCILIATION.md`
   - relevant lesson, companion, and reference files listed below.
7. Read preserved source material before changing canon where provenance or original intent matters:
   - `source-material/PortaShape-original.md`
   - `source-material/runtime-interface-original.md`
   - `source-material/posh-example-catalog-original.md`

After booting, say you are prepared with the repository inventory, product canon, system model, architecture, `.posh` schema and examples, Web-Native Runtime doctrine, onboarding curriculum, companion guides, source provenance, showcase specs, roadmap, governance rules, and tone/ethos documents. Then ask what the user wants to build, revise, explain, or validate.

## 3. Repository map

### Root-level product and repository files

- `README.md` — concise PortaShape product canon and document map.
- `PORTASHAPE_PRODUCT_CANON.md` — single-file edition concatenating the core canon documents for broad review and search.
- `MASTER_REPOSITORY_INDEX.md` — repository map, web-runtime doctrine, reading paths, concept index, checklists, and maintenance guidance.
- `SYNTHESIS_MAP.md` — explains how source materials were reconciled into the current canon and which files are canonical versus reference.
- `MANIFEST.json` — machine-readable file inventory with byte counts and SHA-256 hashes from the manifest generation point.
- `BOOT.md` — this startup prompt.
- `EXAMPLE_WEBPAGE_SHOWCASE_IDEAS.md` — web-page interaction showcase bank for Alpine + htmx examples and generated surface ideas.

### Canonical PortaShape documents in `docs/`

Read these in order for a full product understanding:

1. `docs/01-purpose-and-positioning.md` — product identity, canonical positioning, audience descriptions, problem, thesis, principles, naming, and shorthand.
2. `docs/02-system-model-and-vocabulary.md` — core objects, scopes, authority/writer contracts, mappings, translations, transmutations, synchronization, lifecycle, provenance, unresolved values, and shared graph language.
3. `docs/03-product-experience.md` — workspace lenses, task flow, workspace anatomy, generated interface modes, interaction model, role-sensitive views, progressive complexity, and experience rules.
4. `docs/04-capabilities-and-modules.md` — Connect, Discover, Surface, Runtime, Relate, Transform, Verify, Run, Compare, Preserve, Learn, and Library engines plus cross-engine invariants.
5. `docs/05-architecture.md` — logical architecture, canonical model, adapters, discovery, surface engine, runtime bridge, transformation engine, policy, provenance, artifacts, ownership contracts, extension model, deployment models, and non-functional requirements.
6. `docs/06-posh-artifact-model.md` — artifact role, design goals, artifact kinds, conceptual root, systems/endpoints, element refs, settings/options, mappings, transforms, surfaces, workflows, snapshots, provenance, errors, trust, versioning, and examples.
7. `docs/07-web-runtime-library.md` — placement and purpose of the Web-Native Runtime Library inside PortaShape.
8. `docs/08-use-cases-and-workflows.md` — end-to-end workflows including runtime tuning, website migration, design-system translation, internal tools, snapshots, brand governance, content migration, motion systems, AI/agent surfaces, web-native surface development, onboarding portability, and pattern discovery.
9. `docs/09-governance-security-and-validation.md` — governance, authority, permissions, secrets, trust, preview/dry run, validation layers, assertions, loss, unresolved values, conflicts, audit, rollback, web safety, and AI governance.
10. `docs/10-roadmap.md` — phased roadmap from canon/artifacts through system model, generated surfaces, mapping/simulation, execution, vertical product workflow, library ecosystem, and pattern learning.
11. `docs/11-website-shape-translator-showcase-spec.md` — full showcase spec for uploading source and destination site materials, discovering variables, mapping visually, transmutating shapes, producing `.posh` artifacts, and meeting MVP acceptance criteria.
12. `docs/12-simple-shape-transmutation-examples.md` — three dozen simple source-to-destination shape examples and recommended playground progression.
13. `docs/13-over-the-top-marketing-pitch.md` — deliberately maximalist marketing pitch emphasizing PortaShape’s “from here to there / this to that / any shape to any other” ethos.
14. `docs/sayings.md` — tagline and phrasing bank organized by phrase length; use for product voice, naming, headings, pitches, and UX copy.

### Conceptual schema in `spec/`

- `spec/PORTASHAPE_0.1_CONCEPTUAL_SCHEMA.md` — conceptual draft of `.posh` serialization: UTF-8 JSON, root key `portaShape`, format version `0.1`, artifact kinds, systems, elements, scope values, mappings, operations, cardinality, transforms, loss values, surfaces, event contracts, workflows, policies, unresolved declarations, run reports, imports/layering, extensions, formatting, and relation to examples.

### MVP `.posh` examples in `examples/`

- `examples/README.md` states that all example `.posh` files are valid JSON and follow the MVP fixture contract.
- Non-reference examples include: `formatVersion`, `kind`, stable `id`, `name`, `mvpStatus`, source/destination shapes, labeled variables, editable controls, mappings with operations and confidence, source/proposed/destination previews, import/inspect/map/preview/validate/save/export workflow, policy checks, snapshot metadata, and run evidence.
- The catalog contains 48 complete MVP fixtures plus `examples/portashape-self-description.posh` as a reference bundle.
- The examples cover direct movement, copy, combine, split, translation, transmutation, flattening, componentization, tokenization, promotion, extraction, generation, verification, website snapshot/transfer, and PortaShape self-description.
- For playground planning, respect the progression in `docs/12-simple-shape-transmutation-examples.md`: examples 1–5 teach combine/split/copy/formatting; 6–13 flattening, component generation, and navigation/content movement; 14–21 structural transmutation; 22–27 design tokens/CSS/settings/options/promotion; 28–33 forms/schema/API/table/workflow status mapping; 34–36 visual selection and website-shape preparation.

### Source material in `source-material/`

- `source-material/PortaShape-original.md` — original PortaShape concept source.
- `source-material/runtime-interface-original.md` — original runtime-interface concept source.
- `source-material/posh-example-catalog-original.md` — original `.posh` example catalog source.
- Use these for provenance checks, not as a replacement for the current canon unless the user asks to revisit synthesis decisions.

### Web-Native Runtime Library

Root convenience copies:

- `alpine_htmx_onboarding/` — primary Alpine.js + htmx onboarding curriculum.
- `alpine-htmx-companion-docs/` — companion conceptual guides.

PortaShape library wrapper:

- `libraries/web-native-runtime/README.md` — purpose and start-here guidance.
- `libraries/web-native-runtime/PORTASHAPE_PATTERNS.md` — concise PortaShape surface patterns.
- `libraries/web-native-runtime/reference/` — preserved reference copy of the web-native corpus, including README, boot file, master index, showcase ideas, companion docs, and onboarding lessons.

## 4. Product model to preserve

### Single purpose

PortaShape exists to let people **understand and deliberately change a digital system without losing the meaning, ownership, history, or portability of its values**.

### Canonical loop

```text
CONNECT → DISCOVER → SURFACE → SHAPE → RELATE → SIMULATE → RUN → PRESERVE → LEARN
    ↑                                                                         ↓
    └──────────────────────────── continuous system loop ──────────────────────┘
```

Use this loop to organize product flows, docs, demos, examples, architecture, and implementation work.

### Workspace lenses

PortaShape is one workspace with multiple lenses, not separate products:

- **Explore** — inspect systems, elements, values, ownership, relations, provenance, and runtime observations.
- **Shape** — tune values, operate controls, create surfaces, and propose changes.
- **Map** — relate source and destination values, structures, systems, shapes, and contexts.
- **Run** — execute workflows, migrations, patches, synchronization, validations, and jobs.
- **Compare** — compare snapshots, variants, runs, environments, mappings, and drift.
- **Library** — reuse artifacts, adapters, surfaces, patterns, policies, transforms, and workflows.

### Product engines

Keep these as cooperating engines over the same model:

1. Connect
2. Discover
3. Surface
4. Runtime
5. Relate
6. Transform
7. Verify
8. Run
9. Compare
10. Preserve
11. Learn
12. Library

### Architecture layers

Preserve the conceptual architecture:

1. Workspace shell and lenses.
2. Connectors and adapters.
3. Discovery and interpretation.
4. Canonical System Model / Graph.
5. Surface and Composition Engine.
6. Runtime Bridge.
7. Relation and Transformation Engine.
8. Verification, Policy, and Provenance Engines.
9. Execution Engine.
10. Artifact Store and Library Registry.
11. Pattern Engine.

### Invariants

- A feature is a projection of the shared system graph, not a disconnected utility.
- A control is a surfaced model element with authority, scope, constraints, provenance, and write capability.
- A mapping is a relationship between contextual values.
- A migration or synchronization is an execution of relationships.
- A `.posh` artifact is the portable record of system meaning, relationships, transforms, policies, workflows, evidence, and reusable library knowledge.
- Generated UI must encode ownership and runtime contracts in metadata and implementation structure, not only prose.
- Human and AI decisions must be traceable through provenance, confidence, validation, approval, and artifact versions.
- Unsupported, inferred, approximate, lossy, or unresolved outcomes must remain explicit.
- Meaning comes before format.
- Reuse is the default outcome: controls, mappings, transforms, policies, workflows, adapters, and docs should become composable library knowledge whenever practical.

## 5. Vocabulary and concept rules

Use these meanings consistently:

- **System** — any connected product, site, service, codebase, database, API, design system, content system, runtime, or artifact set.
- **Element** — a meaningful unit in a system: field, token, route, component, event, option, setting, asset, policy, function, table, style, prompt, workflow step, etc.
- **Value** — the typed thing carried by an element, including its scope, authority, constraints, and provenance.
- **Relation** — connection between elements or values: dependency, equivalence, derivation, containment, ownership, event flow, mapping, transform, or synchronization rule.
- **Surface** — generated or composed interface over model elements: inspector, dashboard, form, mapper, preview, report, internal tool, or embedded panel.
- **Transform** — explicit operation for converting, deriving, translating, transmutating, generating, or validating values and structures.
- **Workflow** — ordered human/system process such as import, inspect, map, preview, approve, run, verify, save, export.
- **Run** — execution instance with inputs, outputs, decisions, status, logs, evidence, validation, and provenance.
- **Artifact** — portable `.posh` record.
- **Library** — reusable package of artifacts, adapters, patterns, validators, transforms, surfaces, or workflows.

Mapping vocabulary:

- **Mapping** — relationship between source and destination values/elements in context.
- **Translation** — equivalent value crosses format/context boundary while preserving meaning.
- **Transmutation** — structure changes shape, often with generated, inferred, lossy, approximate, or unresolved parts.
- **Synchronization** — repeated or ongoing relationship execution with conflict and authority rules.

Core scopes:

- settings, options, runtime state, content, code, derived, reference, and secret-reference.

## 6. `.posh` artifact rules

- `.posh` files are UTF-8 JSON.
- Root key is `portaShape`.
- Conceptual format version begins with `0.1`.
- Initial artifact kinds: `system`, `snapshot`, `surface`, `mapping`, `transform`, `workflow`, `policy`, `run`, `library`, `bundle`.
- Unknown namespaced extension keys should be preserved when possible.
- System declarations must not require raw credentials.
- Elements should identify path, kind, name, semantic role, value type, scope, authority, capabilities, constraints, and provenance when available.
- Mappings should identify source, destination, relation, operation, transform, direction, loss, confidence, explanation, and validation references.
- Initial operation values: `copy`, `map`, `translate`, `transmute`, `derive`, `generate`, `synchronize`, `ignore`, `unresolved`.
- Loss values: `lossless`, `lossy`, `approximate`, `inferred`, `generated`, `non-deterministic`, `unresolved`.
- Event contracts should use domain meaning, not implementation detail.
- Run reports should preserve input refs, output refs, status, checks, evidence, decisions, approvals, unresolved values, loss, and provenance.
- When adding or modifying examples, validate JSON with a command such as `python -m json.tool examples/file.posh >/dev/null` or a loop over all examples.

## 7. Web-Native Runtime doctrine

The verified baseline in this repository is **Alpine.js 3.15.12** and **htmx 2.0.10 / stable 2.x**, verified on **2026-07-19**. Treat htmx 4 guidance as prerelease or migration material, not drop-in guidance for htmx 2 examples.

### Constitutional rules

1. **One authoritative owner per state value.**
   - Server/database own durable, shared, permission-sensitive truth.
   - URLs/routes own bookmarkable navigation state.
   - Native controls own submitted values whenever possible.
   - htmx owns request state and server-rendered HTML installation.
   - Alpine owns immediate, disposable browser-local interaction state.
   - Plain JavaScript islands own complex browser APIs or rich widgets only when justified.
2. **One intentional writer per DOM boundary.**
   - htmx replaces server-owned regions.
   - Alpine controls stable local reactive regions.
   - Do not allow htmx and Alpine to silently mutate the same DOM descendants.

### Default responsibility table

| Concern | Default owner |
| --- | --- |
| Durable truth, permissions, validation, transactions, audit, conflict handling | Server/database |
| Canonical representation of server state | Server templates |
| Meaningful navigation, direct visits, refresh-safe state, sharing | URLs/routes |
| Structure, semantics, labels, forms, links, successful controls | HTML |
| Layout, presentation, responsive behavior, ordinary transitions | CSS |
| HTTP requests, triggers, targets, swaps, request coordination, history, OOB swaps | htmx |
| Open/closed, selected, focused, expanded, provisional, dismissed, local preferences | Alpine |
| Browser APIs, charts, editors, maps, scanners, high-frequency rendering | Isolated JavaScript island |
| Communication across ownership boundaries | Semantic browser events |

### Preferred component patterns

1. Alpine-only local component.
2. htmx-only server component.
3. Stable Alpine shell with htmx interior.
4. htmx-replaceable component with disposable Alpine behavior.
5. Semantic event handshake.
6. Isolated JavaScript island.

### Component questions

Ask these for every generated or implemented web component:

- What state values exist, and who owns each one?
- What DOM regions exist, and who writes each one?
- Which values are submitted through native controls?
- Which htmx target is replaced, and does the response root match the swap contract?
- Which Alpine state should reset, survive, be preserved, or be reconciled?
- What semantic events cross boundaries?
- What happens on validation failure, network failure, auth failure, and unexpected server failure?
- Where does focus go after swaps, validation, modal open/close, and errors?
- Does the direct URL or normal form/link path still work without JavaScript enhancement?

### htmx guidance

- Prefer real `href` and `action` baselines, then enhance with htmx.
- Use HTTP methods that match intent.
- Keep `hx-target` narrow.
- Match response markup to `hx-swap`; use `outerHTML` only when replacing the target itself is intended.
- Use `hx-indicator`, the `htmx-request` class, and `hx-disabled-elt` for factual request state instead of duplicating loading flags in Alpine.
- Use debounce/delay/throttle and `hx-sync` intentionally for active search, repeated commands, and race safety.
- Use `hx-push-url` for meaningful navigable results and `hx-replace-url` for ephemeral refinements.
- Use OOB swaps only for related authoritative server projections; avoid OOB sprawl.
- For long work, model jobs explicitly with server-owned status, polling/SSE/WebSockets, retry/cancel semantics, and accessible announcements.
- In htmx 2, expected validation HTML should usually return a swap-eligible status such as 200 unless error swapping is deliberately configured and tested.

### Alpine guidance

- Keep `x-data` small and local.
- Extract `Alpine.data()` only when a component grows or repeats.
- Good Alpine state is cheap to lose on refresh.
- Do not put permissions, prices, inventory, durable entities, workflow truth, or validation facts solely in Alpine.
- Use native controls as the bridge for values the server needs.
- Prefer `x-show` for visibility toggles where DOM should remain; use `x-if` only when creation/destruction is intentional.
- Use `x-text` for untrusted text; avoid `x-html` unless trusted and sanitized.
- Use `$refs`, `$nextTick`, `$watch`, `init()`, and `destroy()` deliberately; clean up timers, observers, and third-party widgets.
- If Alpine creates markup containing `hx-*`, call `htmx.process()` only on the newly inserted subtree after Alpine renders it.

### Semantic event doctrine

- Name events by domain meaning, not implementation detail.
- Use command/intent names for requests, such as `record-delete-requested`.
- Use past-tense fact names for outcomes, such as `record-saved`.
- Document producer, listener, payload, timing, bubbling scope, failure behavior, and version-sensitive mechanics.
- Prefer narrow scopes and local listeners over global event soup.
- Do not smuggle full duplicated server models through payloads; pass identifiers and facts needed for the interaction.

### Accessibility, security, and production

- Native controls and labels first.
- Preserve keyboard operation.
- Restore or move focus deliberately after swaps, validation errors, modal open/close, inline edits, and navigation.
- Use `aria-busy`, `role="status"`, live regions, and reduced-motion-friendly indicators where appropriate.
- Ensure direct URLs and normal forms/links work whenever feasible.
- Browser state is never authorization.
- Escape untrusted values in server templates.
- Sanitize deliberately allowed rich HTML with an allowlist.
- Avoid unsafe `x-html` and untrusted executable attributes.
- Use normal framework CSRF defenses with htmx-enhanced forms.
- Apply CSP-compatible Alpine patterns when production constraints require them.
- Treat auth/session failures, network failures, expected validation, business rejection, and unexpected server errors as distinct cases.

## 8. Onboarding and companion documents

Primary curriculum in `alpine_htmx_onboarding/`:

1. `01-start-here-ownership-and-boundaries.md`
2. `02-alpine-local-ui-fundamentals.md`
3. `03-htmx-request-target-swap-fundamentals.md`
4. `04-forms-controls-and-server-validation.md`
5. `05-request-state-concurrency-and-active-search.md`
6. `06-component-lifecycle-and-dom-boundaries.md`
7. `07-semantic-events-and-cross-boundary-contracts.md`
8. `08-history-navigation-and-progressive-enhancement.md`
9. `09-accessible-modals-drawers-and-inline-editing.md`
10. `10-oob-updates-toasts-jobs-and-live-panels.md`
11. `11-production-security-errors-testing-and-operations.md`
12. `12-power-user-combination-showcase.md`

Supporting files:

- `alpine_htmx_onboarding/COMPLETE_ONBOARDING_PACKAGE.md` — single-file full curriculum reference.
- `alpine_htmx_onboarding/SOURCE_RECONCILIATION.md` — claim audit and version verification.
- `alpine_htmx_onboarding/manifest.json` — package metadata and lesson ordering.

Companion guides in `alpine-htmx-companion-docs/`:

- `alpine-for-htmx-developers.md` — Alpine concepts for htmx-first developers.
- `htmx-for-alpine-developers.md` — htmx concepts for Alpine-first developers.
- `alpine-and-htmx-as-coequals.md` — co-equal ownership model and boundary reasoning.
- `alpine-htmx-superpowers.md` — advanced combined patterns and high-leverage examples.

Use corresponding preserved copies under `libraries/web-native-runtime/reference/` when working inside the library wrapper or when source preservation matters.

## 9. Showcase and playground missions

### Website Shape Translator Showcase

`docs/11-website-shape-translator-showcase-spec.md` describes the flagship demo: users upload or connect source and destination website materials, discover shapes and variables, inspect a registry, tune values, visually map data, transmutate structures, preview outcomes, validate loss/unresolved values, save registered shapes, export `.posh` artifacts, and produce run reports.

MVP areas to respect:

- upload/connect screen;
- shape explorer;
- variable control surface;
- visual data mapper;
- transmutation studio;
- save/export/run report screen;
- `.posh` artifacts for source/destination snapshots, mappings, transforms, workflows, policies, surfaces, run reports, and bundles;
- Web-Native Runtime ownership, progressive enhancement, accessibility, validation, and safety.

### Simple shape examples

When building any simple playground fixture:

1. Treat it as a registered source shape, destination shape, mapping, transform, workflow, policy, snapshot, run report, and reusable `.posh` bundle candidate.
2. Provide UI that makes source labels, destination labels, relation type, operation, transform, confidence, loss, unresolved values, and save/export status visible.
3. Let users make at least one meaningful tweak or mapping decision, preview the proposed result, save it as a new shape/version, and export `.posh` evidence.
4. Use the Web-Native Runtime patterns: server-owned durable truth, URL-owned navigation, native controls for submitted proposals, htmx for narrow swaps and request flows, Alpine for disposable local UI, JavaScript islands only for complex editors, and semantic events for boundary coordination.
5. Include a user story, source/destination shape IDs, seed data, visible variable list, suggested mappings, editable transform controls, validation/loss/unresolved display, save-as-new-shape behavior, and `.posh` export payload or fixture.

## 10. Governance and safety rules

PortaShape governance is part of shaping, not an afterthought.

- Declare authority before proposing controls or writes.
- Distinguish read, observe, propose, preview, write, execute, approve, rollback, and export capabilities.
- Never store raw credentials in `.posh` artifacts.
- Treat connection profiles and secrets as references.
- Use preview and dry-run modes before execution when risk exists.
- Validate artifacts, connections, values, relationships, domain assertions, destination capability, permissions, and post-execution outcomes.
- Make explicit assertions testable and attributable.
- Represent loss and unresolved values visibly.
- Model conflicts with authority, recency, intent, and approval.
- Preserve audit trails and provenance for significant changes.
- Include rollback/recovery thinking in execution flows.
- AI assistance must resolve into inspectable rules, confidence, evidence, and human-reviewable decisions.

## 11. Roadmap mental model

Use `docs/10-roadmap.md` for sequencing:

- Phase 0 — product canon and artifact foundations.
- Phase 1 — system model and inspector.
- Phase 2 — generated control surface and runtime feedback.
- Phase 3 — mapping, transform, and simulation.
- Phase 4 — execution, snapshots, and comparison.
- Phase 5 — complete vertical product workflow.
- Phase 6 — library ecosystem and collaboration.
- Phase 7 — pattern learning and assisted composition.

Respect the MVP boundary: inspectable system model, generated surfaces, mapping/transform previews, `.posh` artifacts, validation/loss/unresolved handling, and a compelling vertical workflow before broad ecosystem ambitions.

## 12. Tone, copy, and naming

Use **PortaShape** for the full product and workspace.

Use capability names as verbs or engines inside PortaShape rather than standalone brands, e.g. PortaShape Connect, Explore, Shape, Map, Run, Compare, and Library.

Use `.posh` for artifact files and **PortaShape Library** for reusable packages.

Default tone for product docs: precise, confident, concrete, system-aware, and honest about loss/uncertainty.

When asked for slogans, marketing, or punchy UX copy, consult `docs/sayings.md`. The ethos is about movement and transformation:

- Data, delivered.
- Shape anything.
- Transform everything.
- Here becomes there.
- This becomes that.
- Any data, any shape.
- Map once, move anywhere.
- Turn any shape into another.
- Get your data from the shape it has into the shape it needs.
- A universal translation layer for moving structured data between any two imaginable shapes.

## 13. Testing and validation expectations

This repository is currently documentation- and fixture-heavy. Choose checks that match the change:

- Markdown/docs changes: inspect rendered structure where possible, check links if tooling exists, and review headings/consistency manually.
- `.posh` changes: validate JSON with `python -m json.tool` and, if modifying many files, loop over all `examples/*.posh`.
- Manifest changes: update or regenerate `MANIFEST.json` only when requested or when the change explicitly requires it.
- Web-runtime examples or future app code: run available test/lint/build commands discovered from project files; include browser/screenshot checks for perceptible runnable UI changes when feasible.
- Always run `git status --short` before finishing so the final state is clear.

## 14. Final boot response template

After completing the boot procedure, respond in this spirit:

> Boot complete. I have the current repository inventory and am prepared with the PortaShape product canon, system vocabulary, architecture, `.posh` conceptual schema, example fixture catalog, Web-Native Runtime Library doctrine, Alpine + htmx curriculum and companion guides, source-material provenance, showcase specs, governance/security rules, roadmap, and tone/sayings bank. What would you like me to build, revise, validate, or explain next?

Keep the response concise unless the user asks for a detailed briefing.