Split out of #9308, which scoped four stock seed fixtures for examples/app-showcase/**. Three landed. This one did not, because measurement showed it is not seed data and cannot be made into seed data, so guessing at it inside that card would have smuggled a design decision into a fixture PR.
What is blocked
automation.rollup-summary-filter (P2), acceptance clause 5:
"the child-row filter is settable via the visual editor on a writable package" (oracle: screenshot)
blocked.by: fixture, ref: #3358 (editor half needs a writable-package summary field fixture). The item's other four clauses — the recompute half — are runnable on stock today and unaffected. The item's knownGaps and blocked block are deliberately left untouched by #9308.
Why it is not a seed addition — measured, not assumed
A writable package is a DB-backed package, and the showcase is definitionally not one.isWritablePackage (packages/metadata-protocol/src/package-writability.ts) returns false for a booted code package — one that registered a manifest into the engine at startup — and the showcase is exactly that. There is no flag, no allowOrgOverride route around it: the registry declares object as allowOrgOverride: false, allowRuntimeCreate: true (packages/spec/src/kernel/metadata-plugin.zod.ts), so a showcase object cannot be edited by overlay, and a runtime-created one needs a writable base to live in.
sys_packages is not reachable from defineSeed. It is a raw SQL table created by service-package's own DDL (CREATE TABLE IF NOT EXISTS sys_packages …), not an ObjectQL object, so the stack's declarative data: block cannot address it. Provisioning one means playing the admin's part imperatively at boot — protocol.installPackage plus protocol.saveMetaItem — in the shape bind-position-sets.ts and seed-approval-demo.ts already use for other bootstraps.
A roll-up needs TWO objects, not one. A summary field lives on the parent and aggregates a child that carries the relationship back. No existing showcase child can serve, because each already points at its own parent (showcase_expense_line at showcase_expense_report). So the fixture is a boot-time metadata-authoring bootstrap that mints two new tables on every fresh boot of the reference app.
Why it is a design call rather than a bigger chore
Shipping a permanent writable base changes what the reference app is, in ways that reach past this one item:
access-security.readonly-package-locks-studio (P2) uses the showcase as the read-only side of a two-sided gate and needs "a WRITABLE (draft/app-local) object" as its contrast — so a stock writable base would also serve that item. That is an argument in favour, and it is precisely why the decision is not local to the rollup item.- Studio's package selector, the
/meta state routes, and the schema-sync path all gain a second, mutable metadata home on every boot. - Today the platform's designed path for a writable base is on demand (ADR-0033 zero-package app building: the AI blueprint flow auto-creates one). Nothing consumes a pre-seeded one, so shipping one is capability surface with no measured pull.
Recommendation
Decide the question before building anything: should the stock showcase boot with a project-scoped writable package?
- If yes — provision it once, imperatively, alongside the existing
kernel:bootstrapped bootstraps, with a minimal parent/child pair whose only job is to carry one filtered summary field. That closes automation.rollup-summary-filter clause 5 and gives access-security.readonly-package-locks-studio its contrast side in the same move, and both items should be revised together. - If no — say so on the two items and retarget them at a run-time step (the runner duplicates the showcase base into a writable one via
POST /packages/:id/duplicate, which is the platform's own supported path) rather than leaving them carrying a fixture blocker nobody intends to pay.
Either way it wants a maintainer/showcase-owner ruling first; the implementation is small once the question is answered.
Context
Split out of #9308, which scoped four stock seed fixtures for
examples/app-showcase/**. Three landed. This one did not, because measurement showed it is not seed data and cannot be made into seed data, so guessing at it inside that card would have smuggled a design decision into a fixture PR.What is blocked
automation.rollup-summary-filter(P2), acceptance clause 5:blocked.by: fixture,ref: #3358 (editor half needs a writable-package summary field fixture). The item's other four clauses — the recompute half — are runnable on stock today and unaffected. The item'sknownGapsandblockedblock are deliberately left untouched by #9308.Why it is not a seed addition — measured, not assumed
A writable package is a DB-backed package, and the showcase is definitionally not one.
isWritablePackage(packages/metadata-protocol/src/package-writability.ts) returnsfalsefor a booted code package — one that registered a manifest into the engine at startup — and the showcase is exactly that. There is no flag, noallowOrgOverrideroute around it: the registry declaresobjectasallowOrgOverride: false, allowRuntimeCreate: true(packages/spec/src/kernel/metadata-plugin.zod.ts), so a showcase object cannot be edited by overlay, and a runtime-created one needs a writable base to live in.sys_packagesis not reachable fromdefineSeed. It is a raw SQL table created byservice-package's own DDL (CREATE TABLE IF NOT EXISTS sys_packages …), not an ObjectQL object, so the stack's declarativedata:block cannot address it. Provisioning one means playing the admin's part imperatively at boot —protocol.installPackageplusprotocol.saveMetaItem— in the shapebind-position-sets.tsandseed-approval-demo.tsalready use for other bootstraps.A roll-up needs TWO objects, not one. A
summaryfield lives on the parent and aggregates a child that carries the relationship back. No existing showcase child can serve, because each already points at its own parent (showcase_expense_lineatshowcase_expense_report). So the fixture is a boot-time metadata-authoring bootstrap that mints two new tables on every fresh boot of the reference app.Why it is a design call rather than a bigger chore
Shipping a permanent writable base changes what the reference app is, in ways that reach past this one item:
access-security.readonly-package-locks-studio(P2) uses the showcase as the read-only side of a two-sided gate and needs "a WRITABLE (draft/app-local) object" as its contrast — so a stock writable base would also serve that item. That is an argument in favour, and it is precisely why the decision is not local to the rollup item./metastate routes, and the schema-sync path all gain a second, mutable metadata home on every boot.Recommendation
Decide the question before building anything: should the stock showcase boot with a project-scoped writable package?
kernel:bootstrappedbootstraps, with a minimal parent/child pair whose only job is to carry one filteredsummaryfield. That closesautomation.rollup-summary-filterclause 5 and givesaccess-security.readonly-package-locks-studioits contrast side in the same move, and both items should be revised together.POST /packages/:id/duplicate, which is the platform's own supported path) rather than leaving them carrying a fixture blocker nobody intends to pay.Either way it wants a maintainer/showcase-owner ruling first; the implementation is small once the question is answered.
Context
FOLLOW-UPS.mdsection 6 records the split).docs/qa/platform-checklist/areas/automation.json→automation.rollup-summary-filter.docs/qa/platform-checklist/areas/access-security.json→access-security.readonly-package-locks-studio.