Use case
Every project should ship with a useful set of default views (whole-graph diagram, per-layer table, context digest) without the user authoring queries and views first. The owner direction is to deliver this through the existing pack mechanism rather than a runtime special case.
Verified feasibility (real binary, 2026-07-22)
- Type-agnostic queries are legal and work: selector absence means unrestricted (ldl-language-specification.md §16.2); a query naming no entity/relation types selected all 9 entities and 12 relations across all types and materialized diagram/table/context.
- A pack-exported view (
select {} based) materializes against entities of types defined by the installing project. Constraint: pack modules cannot name consumer-defined types (§6.2 — pack imports must not reference consumer install names), so typed views only apply to pack-bundled types.
Suggested shape
- A
layerdraw/standard pack containing type-agnostic queries and views (overview diagram, per-layer table, context digest, validation-oriented views), versioned and published like any pack.
- Project creation templates pre-install it: pinned entry in
layerdraw.resolved.json written at bootstrap. No implicit engine/runtime injection — determinism requires the resolved tree to be explicit; the pack must be visible, updatable through the normal previewable pack-update transaction, and removable.
- Typed convenience views stay in domain packs that bundle their own EntityTypes.
Constraints
- No engine or runtime special-casing for "default" packs.
- Standard pack views must remain type-agnostic; adding a type-referencing view to it is a design error.
Dependency
Post-milestone. Depends on Registry install flows (#164-#166, shipped) and template-based creation.
Renderer extensibility decision (owner, 2026-07-22)
Packs never ship renderer/UI code. The shape set is owned by core and grows through RFCs driven by demonstrated demand; packs and views only declare what slice of the graph to show (query), in which core shape, with declarative render hints and assets. Arbitrary renderer plugins are explicitly deferred (security, determinism, cross-delivery parity) and would require their own RFC.
Use case
Every project should ship with a useful set of default views (whole-graph diagram, per-layer table, context digest) without the user authoring queries and views first. The owner direction is to deliver this through the existing pack mechanism rather than a runtime special case.
Verified feasibility (real binary, 2026-07-22)
select {}based) materializes against entities of types defined by the installing project. Constraint: pack modules cannot name consumer-defined types (§6.2 — pack imports must not reference consumer install names), so typed views only apply to pack-bundled types.Suggested shape
layerdraw/standardpack containing type-agnostic queries and views (overview diagram, per-layer table, context digest, validation-oriented views), versioned and published like any pack.layerdraw.resolved.jsonwritten at bootstrap. No implicit engine/runtime injection — determinism requires the resolved tree to be explicit; the pack must be visible, updatable through the normal previewable pack-update transaction, and removable.Constraints
Dependency
Post-milestone. Depends on Registry install flows (#164-#166, shipped) and template-based creation.
Renderer extensibility decision (owner, 2026-07-22)
Packs never ship renderer/UI code. The shape set is owned by core and grows through RFCs driven by demonstrated demand; packs and views only declare what slice of the graph to show (query), in which core shape, with declarative render hints and assets. Arbitrary renderer plugins are explicitly deferred (security, determinism, cross-delivery parity) and would require their own RFC.