Context
@stackbilt/scaffold-core was extracted from stackbilt-web (PR #219). During the stackbilt-web migration (PR #182), three API gaps were discovered that block a clean drop-in replacement.
Gaps
1. Pattern name vocabulary mismatch
The package classifier maps multi-tenant SaaS intentions to worker (confidence 0.9), but stackbilt-web's internal classifier returns workers-saas. This breaks domain fixture tests in stackbilt-web.
Fix: Add workers-saas as a first-class PatternName in types.ts (or alias it in the classifier) and update classify logic to prefer it over the generic worker pattern when multi-tenancy traits are present.
2. LocalScaffoldResult missing fields
stackbilt-web's API routes depend on fields that don't exist in the package's LocalScaffoldResult:
traits — pattern trait array (already on ClassifyResult, should be promoted to top-level or accessible)tier2_recommended — boolean flag for upgrade promptsoutput — raw generation output stringpromptContext — prompt template context object
Fix: Add these fields to LocalScaffoldResult (optional where appropriate), or document the migration path to read them from result.classification.*.
3. materializeScaffold signature mismatch
- Package:
materializeScaffold(facts: ScaffoldFacts): MaterializerResult
- stackbilt-web local:
materializeScaffold(facts: Record<string, unknown>, intention: string)
The second intention argument was used to inject the raw intention string into generated file content. The package version pulls it from facts.intention.
Fix: Verify facts.intention is populated before materializer is called in buildScaffold — it already is (intention: classification.enrichedIntention). stackbilt-web callers need to move to the ScaffoldFacts shape; a migration guide in the README would help.
Related
Priority
Medium — downstream consumers are unblocked via shims. Fix before deprecating the local copies in consuming repos.
Context
@stackbilt/scaffold-corewas extracted fromstackbilt-web(PR #219). During the stackbilt-web migration (PR #182), three API gaps were discovered that block a clean drop-in replacement.Gaps
1. Pattern name vocabulary mismatch
The package classifier maps multi-tenant SaaS intentions to
worker(confidence 0.9), but stackbilt-web's internal classifier returnsworkers-saas. This breaks domain fixture tests in stackbilt-web.Fix: Add
workers-saasas a first-classPatternNameintypes.ts(or alias it in the classifier) and update classify logic to prefer it over the genericworkerpattern when multi-tenancy traits are present.2.
LocalScaffoldResultmissing fieldsstackbilt-web's API routes depend on fields that don't exist in the package's
LocalScaffoldResult:traits— pattern trait array (already onClassifyResult, should be promoted to top-level or accessible)tier2_recommended— boolean flag for upgrade promptsoutput— raw generation output stringpromptContext— prompt template context objectFix: Add these fields to
LocalScaffoldResult(optional where appropriate), or document the migration path to read them fromresult.classification.*.3.
materializeScaffoldsignature mismatchmaterializeScaffold(facts: ScaffoldFacts): MaterializerResultmaterializeScaffold(facts: Record<string, unknown>, intention: string)The second
intentionargument was used to inject the raw intention string into generated file content. The package version pulls it fromfacts.intention.Fix: Verify
facts.intentionis populated before materializer is called inbuildScaffold— it already is (intention: classification.enrichedIntention). stackbilt-web callers need to move to theScaffoldFactsshape; a migration guide in the README would help.Related
feat/scaffold-module-split— in-flight refactor, should be sequenced before migration)feat/classify-command(uses local shim, will swap once gaps resolved)Priority
Medium — downstream consumers are unblocked via shims. Fix before deprecating the local copies in consuming repos.