Repository navigation
feat(gui): one manifest contract for Flavian, Aurelius and Vespasian (#187) - #196
Merged
Merged
Conversation
…187) Slice 1 of the Trajan engine reconciliation (stage 4 of GUI-PLATFORM.md, epic #186). The three GUI forks had let the ProductManifest contract split (ScreenId, ParserKey, CommandDescriptor, ScreenExtras, ProductId, TaskKind all differed); this brings the forks' catalogs back under one contract in this engine, without changing what the Flavian build does. - manifest.ts: ProductId names all five products, ScreenId gains `site`, ScreenExtras gains `frameworks`; ParserKey stays a closed union on purpose (the engine throws on unknown keys at run time, so an open type would only hide typos; the registry test checks every parser a manifest names). - types/task.ts: TaskKind lists the kinds the manifests emit (prereq:*, init, docker:<DockerCommand>, site:<SiteCommand>, pipeline:<PipelineKind>, qa:*) instead of literals nothing used. - aurelius.ts is the fork's real manifest (Aurelius main 86bcc99) in place of the scaffold; vespasian.ts and types/site.ts are ported verbatim from Vespasian main ed0696c. Both are registered in PRODUCTS; ACTIVE_PRODUCT_ID stays flavian, so this build is unchanged. - tests/shared/product/registry.test.mts pins the registry and, for every registered manifest: unique screen and step ids, labels, the prerequisite convention, registered parsers, delegate targets, exit codes, and that the manifest is plain JSON-serializable data. - docs/plans/2026-11-08-trajan-engine-reconciliation-{design,plan}.md hold the measured drift, the decisions taken here, the decisions reserved for the owner (engine home, branded builds vs one app, signing) and the tasks for the remaining slices: the Wix-site screen, the Aurelius additions with a generic step runner, product-neutral transport, the engine's home, fork retirement. GUI-PLATFORM.md points at them. gui lint, typecheck, 81 unit tests, build and smoke pass. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Slice 1 of #187 (stage 4 of
packages/gui/docs/GUI-PLATFORM.md, epic #186). Does not close #187: the remaining slices are planned in this PR.What changes
ProductIdnames all five products,ScreenIdgainssite,ScreenExtrasgainsframeworks(Aurelius's wizard choices) next to Flavian'sthemeStarters.ParserKeystays a closed union on purpose: the engine throws on an unknown key at run time, so(string & {})would only hide typos; the new registry test checks that every parser a manifest names resolves.TaskKindnow lists the kinds the manifests actually emit (prereq:*,init,docker:<DockerCommand>,site:<SiteCommand>,pipeline:<PipelineKind>,qa:*) instead of literals nothing used.aurelius.tsis the fork's real manifest (Aureliusmain86bcc99) in place of the scaffold;vespasian.tsandtypes/site.tsare ported verbatim from Vespasianmained0696c. All three are registered inPRODUCTS.ACTIVE_PRODUCT_IDstaysflavian, so this build's behaviour is unchanged (the existing manifest tests prove it). Selecting the other two would still leave their fork-only screens unrendered until slices 2 and 3 land, and the docs say so.tests/shared/product/registry.test.mts, 26 tests): registry keys match manifest ids; Aurelius and Vespasian expose the screens their forks ship; wizard command kinds per product; and for every registered manifest: unique screen and step ids, labels, the prerequisite convention (prereq-check, parserprereq, exit codes[0, 1]), registered parsers, delegate targets inside the product, success codes include 0, and the manifest survives a JSON round trip (pure data).docs/plans/2026-11-08-trajan-engine-reconciliation-design.mdrecords the drift measured today (per-directory diff lines against both forks, the files only one copy has, where the contract split), goals, non-goals, anti-goals, the decisions taken here and the ones reserved for you.…-plan.mdhas the tasks for the next slices with files, interfaces and the tests that gate them: the Wix-site screen; the Aurelius additions (genericrunStepIPC anduseStep, extra prerequisite steps, the script-backed wizard, manifest-declared pipeline inputs, one QA artifact model,fillTemplatedropping empty sole placeholders); product-neutral transport and build identity; the engine's home; fork retirement.Decisions I'd like you to confirm or overturn
From the design doc: Flavian's copy as the base (the issue's proposal); closed
ParserKey; prefix-typedTaskKind;ScreenExtrasas the union of the forks' extras; porting the fork manifests verbatim and registering them now. The two decisions only you can take (where the engine lives; one app vs branded builds) carry a recommendation each in the design doc and gate slice 5, not slices 2 to 4.Verification
pnpm --filter @flavian/gui lint,typecheck,test(81 pass),build(the three manifests bundle) and the smoke test all pass.🤖 Generated with Claude Code