Move theme and manifest validation to theme validate, add config validate
Three artifacts share the word "config", and refrakt validate currently validates the two that belong to theme authors under a name that reads like a site author's command:
Three artifacts share the word "config", and refrakt validate currently validates the two that belong to theme authors under a name that reads like a site author's command:
Tracking started Sep 20 — check back for trends.
a911cc4theme group, and not something newbin.ts:23-29 dispatches five noun groups — theme, template, plugins, config, reference. Subcommands are this CLI's general shape for "acting on a named thing", not a plugin convention. theme already holds install, info and list; theme validate slots in beside them. config migrate already exists, so config validate does too.
Being a core concern does not argue against a group — config is as core as anything in the product and has one.
Part A — the vacation. No dependencies; land this first.
refrakt theme validate runs validateThemeConfig and validateManifest, taking the paths --config / --manifest take today--config and --manifest are gone from the bare refrakt validate, not aliased through a deprecation windowrefrakt theme validate with no arguments reports what it found no input for, rather than validating baseConfig and printing successtheme validate as theme-authoring and refrakt validate as site-authoringPart B — config validate. Needs WORK-578's resolution layer to exist.
refrakt config validate runs the config-resolution layer alone, through the same function WORK-578 calls — not a second implementationMostly a relocation: the two validators already exist in @refrakt-md/transform and the command already calls them. The work is dispatch, help text, and deciding what each command does when handed nothing.
Part A can land before WORK-578, and should. It has no dependency on validateContent — it only needs to vacate the bare command. Doing it first makes WORK-578 a smaller diff, since the bare command is then empty rather than being rewritten around existing flags.
Part B cannot, because there is no resolution layer for config validate to call until WORK-578 builds one, and building a second implementation is exactly what its criterion forbids. Hence the split above: this item ships in two commits, with Part B landing after WORK-578 rather than the whole item waiting on it.
That split is why there is no ## Blocked by here — a whole-item edge would hide Part A, which is unblocked, simple, and makes the next item easier. Do not start Part B before WORK-578 is done.
Retire rather than alias. Pre-1.0, and today's zero-argument behaviour is close to a no-op, so nobody can be meaningfully depending on it. An alias would keep the audience confusion alive for no one's benefit.
theme group, and the alternatives rejected), D1 (the three artifacts)packages/cli/src/bin.ts — the noun-group dispatch at :23-29packages/cli/src/commands/validate.ts — what movespackages/transform/src/validate.ts — validateThemeConfig