Teach bounded nonempty Foundation Plan authoring

[raghubetina]

Summary

• align create-full-stack-app with the reviewed First Draft Entity and scalar Field importer slices
• document the exact ten supported Field types, retained properties, Primary Descriptor boundary, and atomic unsupported-capability behavior
• replace the obsolete blanket nonempty rejection eval with schema-valid supported and capability-gap cases
• add a subject-ID minting eval so new subjects continue to come only from firstdraft plan subject-id
• bind the prose allowlists, fixtures, diagnostic digest, and exact pointers in repository tests

Stack

• based on Scaffold full-stack application Skill #1
• server transport and Entity/short_text graph: firstdraft/firstdraft#190 at f612eca
• remaining bounded scalar Fields: firstdraft/firstdraft#192 at cd727c8
• CLI plan subject-id: Generate Foundation Plan subject IDs cli#4 at 0681afd

This does not change the bundled sketch/0.19 schema, CLI transport, or accepted discovery metadata.

Current boundary

The reviewed importer accepts empty drafts plus Entities, the ten scalar Field types boolean, date, datetime, decimal, integer, language_code, long_text, short_text, time_zone, and url, and Field or system-Field Primary Descriptors. Defaults, Validations, derivations, settings, other Field types, References, Associations, and remaining Application/Entity capabilities still fail atomically with foundation_plan.import.unsupported_capability.

Verification

• npm ci --ignore-scripts
• sh script/check — 10 tests
• npm audit --audit-level=low — 0 vulnerabilities
• Skill Creator validation — valid
• gh skill publish --dry-run . — validation completed
• live importer probe accepted all ten supported Fields and returned the four exact capability pointers for the unsupported fixture
• forward scenarios covered supported review, unsupported recovery, and missing subject-ID capability
• iterative max-effort local review completed with approval and no material findings

[raghubetina]

Forward dogfood at e868210, using the packed CLI from firstdraft/cli#4 (0681afd) and importer from firstdraft/firstdraft#192 (cd727c8), validates the core behavior in fresh agent contexts.

The first author correctly initialized a Plan, minted 11 UUIDv7s through the CLI, modeled every admitted scalar kind, applied the requested comparison/normalization and privacy semantics, and pushed successfully. It then preserved all identities across an Entity/Field rename. When asked for a mixed supported/unsupported candidate, it preserved the literal default, Validation, enum, and supported addition after the server returned four capability diagnostics, and stopped without retry. A second fresh writer with opaque stale state made a different identity-preserving rename, received 412, and followed the recovery stop exactly.

One reproducible efficacy issue surfaced in both fresh contexts: each loaded the complete 4,961-line schema and searched the local Python/Node/Ruby environment for a Draft 2020-12 validator before proceeding. Neither fabricated validation or installed a dependency, and both reported the evidence boundary accurately, but the work consumed context without producing local validation. I will address that in a small stacked Skill/eval PR by marking the schema as machine input, explicitly routing the no-validator branch, prohibiting wholesale schema loading, and adding a forward case. The schema, provenance, and evidence claims need no change.

[raghubetina]

Follow-up #3 is now open on top of this branch: #3

It resolves the schema-loading inefficiency observed during cross-repository dogfood. Fresh agents had loaded the full 4,961-line schema and probed several language ecosystems when no validator was installed. The follow-up treats the schema as machine input, permits only a named or project-exposed compatible command, covers pass/fail/absent/library-only paths, and keeps validation and server-acceptance claims separate. It does not change the pinned schema bytes or this PR's bounded importer guidance.

[raghubetina]

Stacked follow-up #4 is now open on top of #3: #4

It updates this Skill for the enum importer in firstdraft/firstdraft#196. The earlier dogfood result on this PR remains accurate for API #192: enum was intentionally rejected at that exact head. With #196 included, schema-valid enum Fields, ordered values, and optional ordinality are supported; enum defaults and Validations remain capability gaps. The follow-up adds an accepted example, stable-value-identity guidance, local authoring and server-push evals, and corrects the mixed diagnostic fixture without changing the schema or generic CLI.

[raghubetina]

Stacked follow-up #5 is now open above #4: #5

The earlier dogfood and comments on this PR remain accurate for their pinned API heads. The comment above saying enum defaults remain a capability gap is superseded once firstdraft/firstdraft#200 and #202 are included. #5 updates the Skill, examples, fixtures, and evals for structurally retained Field defaults while keeping semantic default analysis explicitly out of scope.

[raghubetina]

This slice has landed on main through #6, which integrated the complete reviewed Skill stack. This PR remains the focused review history for bounded nonempty Foundation Plan authoring; no implementation was discarded. Closing as superseded by #6.