Context
Surfaced by the new check:skill-examples gate (#3094 / #3215's sibling PR #3224). When tagging self-contained skill examples for type-checking, the feature-flags example in skills/objectstack-platform/SKILL.md failed to compile against @objectstack/spec. Unlike the other drifts fixed in that PR (simple wrong import paths), this one is a deeper, structural problem, so the block was deliberately left as-authored and untagged rather than shipping a guessed correction. This issue tracks the real fix.
The example (paraphrased)
import { defineStack } from '@objectstack/spec';
export default defineStack({
featureFlags: [
{
name: 'experimental_ai_copilot',
enabled: true,
strategy: 'percentage',
conditions: { percentage: 25 },
environment: ['production'],
},
// ...
],
});
Why it's wrong (three concrete problems)
-
featureFlags is not a key on the defineStack input. ObjectStackDefinitionInputSchema (in packages/spec/src/stack.zod.ts) has no featureFlags (nor features) top-level key. A consumer copying this hits TS2353: 'featureFlags' does not exist in type 'ObjectStackDefinitionInput'.
-
The only related schema is not an authoring input. features: z.array(FeatureFlagSchema) lives inside KernelCapabilitiesSchema → mounted at ObjectStackCapabilitiesSchema.system (packages/spec/src/stack.zod.ts). But ObjectStackCapabilitiesSchema is a runtime capabilities descriptor — it's exported only as a type and is not referenced by ObjectStackDefinitionInputSchema. So feature flags currently have no authoring home in objectstack.config.ts via this path. Renaming featureFlags → features does not fix it (verified: features is not a top-level input key either).
-
environment shape/value is also wrong. FeatureFlagSchema.environment (packages/spec/src/kernel/feature.zod.ts) is a single enum z.enum(['dev','staging','prod','all']).default('all') — not an array, and 'production' is not a valid value ('prod' is). The example writes environment: ['production'].
What a fix needs to decide (not a mechanical rename)
The core question is a product/spec decision: how (or whether) feature flags are authored in a stack. Options include:
- Add a real top-level (or nested) authoring key to
ObjectStackDefinitionInputSchema that accepts FeatureFlagSchema[], then rewrite the example against it; or
- If feature flags are not author-declared (only a runtime descriptor), remove/replace the example with the actual mechanism (e.g. how flags are seeded/registered at runtime).
Whoever owns the feature-flags surface should confirm the intended authoring path before the example is rewritten.
Definition of done
- The
skills/objectstack-platform/SKILL.md feature-flags example compiles against @objectstack/spec (correct key, correct environment scalar, valid enum value), or is replaced with the real mechanism.
- Re-add the
<!-- os:check --> marker above the block so check:skill-examples covers it going forward.
Refs: PR #3224 (the gate + the deferral note in its description).
Context
Surfaced by the new
check:skill-examplesgate (#3094 / #3215's sibling PR #3224). When tagging self-contained skill examples for type-checking, the feature-flags example inskills/objectstack-platform/SKILL.mdfailed to compile against@objectstack/spec. Unlike the other drifts fixed in that PR (simple wrong import paths), this one is a deeper, structural problem, so the block was deliberately left as-authored and untagged rather than shipping a guessed correction. This issue tracks the real fix.The example (paraphrased)
Why it's wrong (three concrete problems)
featureFlagsis not a key on thedefineStackinput.ObjectStackDefinitionInputSchema(inpackages/spec/src/stack.zod.ts) has nofeatureFlags(norfeatures) top-level key. A consumer copying this hitsTS2353: 'featureFlags' does not exist in type 'ObjectStackDefinitionInput'.The only related schema is not an authoring input.
features: z.array(FeatureFlagSchema)lives insideKernelCapabilitiesSchema→ mounted atObjectStackCapabilitiesSchema.system(packages/spec/src/stack.zod.ts). ButObjectStackCapabilitiesSchemais a runtime capabilities descriptor — it's exported only as a type and is not referenced byObjectStackDefinitionInputSchema. So feature flags currently have no authoring home inobjectstack.config.tsvia this path. RenamingfeatureFlags→featuresdoes not fix it (verified:featuresis not a top-level input key either).environmentshape/value is also wrong.FeatureFlagSchema.environment(packages/spec/src/kernel/feature.zod.ts) is a single enumz.enum(['dev','staging','prod','all']).default('all')— not an array, and'production'is not a valid value ('prod'is). The example writesenvironment: ['production'].What a fix needs to decide (not a mechanical rename)
The core question is a product/spec decision: how (or whether) feature flags are authored in a stack. Options include:
ObjectStackDefinitionInputSchemathat acceptsFeatureFlagSchema[], then rewrite the example against it; orWhoever owns the feature-flags surface should confirm the intended authoring path before the example is rewritten.
Definition of done
skills/objectstack-platform/SKILL.mdfeature-flags example compiles against@objectstack/spec(correct key, correctenvironmentscalar, valid enum value), or is replaced with the real mechanism.<!-- os:check -->marker above the block socheck:skill-examplescovers it going forward.Refs: PR #3224 (the gate + the deferral note in its description).