# Continue Hearth: prove extensibility through new compositions Continue implementing in this existing session and workspace. This is a new authorized development phase after your completed first delivery. Do not restart the project or stop merely because the original task was completed. Retain all original R01-R30 requirements and accepted design ideas unless a change below explicitly supersedes them. The first delivery is a useful executable architecture: shared component contracts, authority, transactions, automatic structural provenance, terrain adaptation, and paired persistence all work on its finite test set. An external report reran all 134 tests and executed the unchanged library in Pyodide. Eleven browser executions matched native semantic content, principal signatures, and glass queries. Six downloaded artifact pairs also preserved their complete structural nodes. Preserve this functionality and portability. The major remaining weakness is expressive breadth. Most shipped buildings use a small grid-room vocabulary with bays 9/11/13 and bounded gables. Settlement organization is an opposed street with spine/loop paths. Contact adaptation mostly chooses between two strategies. The 18 principal signatures in 24 building samples and 9 successes in 32 stress inputs are useful evidence, not proof of a broadly expressive architecture or distribution. Implement improvements, not just a proposal, more documentation, or more seed samples of the same narrow programs. Code length is not a target. Favor a clear, extensible library, lightweight high-level clients, working validation, and attractive generated results. ## 1. Test the existing abstraction before changing it Record a concise public API baseline and its module hashes before modifying the kernel. Implement new components in a separate extension package using documented public contracts. Use these as concrete probes: - A diagonal bridge with walkable circulation, railings, and endpoint/support adaptation. - A wall or boundary that follows a curve or spline and exposes useful attachment interfaces. - A corridor or walkway connecting two already placed buildings through their public ports, including a composition crossing water or uneven terrain. These are reusable component examples, not three new hardcoded building/environment families. Use shared geometric structures where helpful: splines or polylines, graphs, fields, local frames, spatial indexes, and constraint/effect records are all appropriate. Choose the representation deliberately; do not add structures just to check off their names. Start with the kernel unchanged. If an extension reveals a real missing capability, record the failing composition or contract test first. Then make the smallest coherent, general protocol improvement, documenting the API delta and why extension-only code was insufficient. Do not evade a limitation through private-state access, direct block-store mutation, client geometry repairs, handwritten provenance, or a kernel branch keyed to an example name. A self-authored extension is an extension exercise, not an independent audit. Describe its evidence honestly. The important result is whether clients and other components can use the new behavior through public interfaces without knowing its private geometry. ## 2. Broaden meaningful architectural composition Use these capabilities in lightweight new building and settlement compositions. Move beyond the same opposed street layout: let explicit graphs, environmental observations, public connections, and spatial constraints drive placement and circulation. Demonstrate materially different massing and spatial organization, not just colors, names, transforms, or extra decorations. Extend the shipped architectural vocabulary where needed rather than hiding large one-off generators behind a short wrapper. Keep environments compositional and generic. A flat site, shore, slope, or channel should arise from general operations/parameters rather than an enumerated environment selector. Generate and freeze the relevant environment before placing structures. Respect locked principal intent and edit permissions. Where adaptation fails, improve general contact or connection rules when justified; do not simply widen limits, remove validators, move locked buildings, flatten the whole terrain, or resample away difficult inputs. Keep authority directional and local, preserve existing consumers, maintain whole-object consistency, and validate tentative compositions before committing. New components must participate in automatic instance ownership, typed relationships, precise current-cell queries, transforms, replacement/deletion, and atomic rollback through the same infrastructure. ## 3. Verify and inspect actual results Keep every existing test. Retain the completed first-phase evidence and distinguish new results from it, for example under reports/extension-corpus and samples/extensions. Do not rewrite earlier evidence to make the new implementation look better. Add focused positive and deliberately broken cases for each new capability: disconnected endpoints, incompatible ports/frames, missing support, blocked headroom, permission overflow, stale ownership after replacement, and failed-candidate rollback. Validate actual blocks/NBT and relevant companion records rather than only declared plans. Exercise multiple seeds and independent environment/structure inputs, including parameter boundaries and compositions not used to implement the primitives. State the supported domain and sampling recipe before assessment. Retain all failures, incompatibilities, and budget exhaustion; separate input success from candidate acceptance. Track principal architectural signatures separately from contact adaptations and cosmetic variation. Render and inspect representative complete compositions from several sides and with interior or circulation cutaways. Correct visible problems through reusable rules. Show that bridges and corridors connect usable entrances and that curve-following geometry has coherent joins. Preserve semantic export/reload, deterministic scoped seeds, exact structural inspection, and the original public default and --seed/--output CLI contract. Run the full regression suite and the new assessment before claiming completion. Do not weaken tests to obtain a pass. Update ARCHITECTURE.md, GENERATOR.md, and the requirement/evidence ledger to describe the final implementation and real limitations. End with what improved, which interfaces changed, what still requires private knowledge or remains constrained, and actual test/render results. No new HTML report, viewer, deployment, or reference-generator reuse is needed in this phase.