75f9b27687fdb0c30a50051fa91f0c3117c81f57
3 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
| 3c179e3338 |
fix(release): ship server/commands, and check that the bundle is complete
v1.0.0 installed and then died on every boot:
module "uo" failed to load — {"stage":"register","reason":"Cannot find
module './commands/guild.command'"}
`server/commands/` arrived with the Teams cutover (
|
|||
| 8ec21086b5 |
ci(release): derive the version from commit subjects, and add a manual backdoor
A bundle used to cost a second pull request whose entire content was a number. The workflow published only when a merge to `main` left `module.json` at a version with no release yet, so a merge that did not touch that line released nothing. Measured rather than argued: v0.3.0 (2026-08-12) is the only release this repo has ever cut, while the nine Teams phases and the cutover landed on `main` in the week since. Adopt the engine `link` and `installer` already run - feat!/BREAKING CHANGE -> major, feat -> minor, fix|perf -> patch, nothing releasable -> no release. The number that ships is the tag, and CI writes it into the `module.json` inside the bundle, with an assertion that the rewrite happened: a bundle carrying the wrong version would install under a number that is not the one it was released as. `module.json`'s version is kept as a floor rather than deleted - a version above the newest tag still releases at that version - so the declared model survives as the special case it always was, and is still how a `coreApi` bump overrules the subjects. `workflow_dispatch` covers what the rules cannot reach: leave `version` blank to bump the newest tag by `bump`, or name an exact version. Where the log and the input disagree the larger bump wins, because a button pressed on a log full of `feat:` would otherwise publish its `patch` default over a minor's worth of work. Two things carried over from `link` at the same time: a tag pushed without a release behind it is now recovered rather than making that state permanent, and the changelog moved into the plan step (so the assemble step clears `$OUT`, not `dist/`, which now holds it). On this repo's `main` the engine computes v0.4.0. The workflow still never writes to a branch. Co-Authored-By: Claude <noreply@anthropic.com> |
|||
| 5cdcf0fbb6 |
feat(release): ship an OpenAPI fragment, a frozen manifest and a bundle (phase 3, slice 5)
The three artifacts that make this module installable and checkable, closing
phase 3's extraction. Nothing about what the module serves changes: the same 72
URLs, the same behaviour.
**The OpenAPI fragment (MODULE_API.md §2.8, §6.1a) was never built, on either
side.** The 417 `#swagger` annotations came across in slice 1 and went nowhere,
and core's /api/docs.json merged nothing — so every route this module serves was
in no spec at all, which is core's standing rule ("never ship a route that isn't
in the spec") being broken by the extraction rather than by a route.
`server/scripts/swaggerFragment.js` generates it. The prefixes are DERIVED: the
script runs the module's own `register()` against a recording api and asks
`require.cache` which file each router came from, so a mount prefix exists in one
place — `server/index.js` — and not in a table beside it. The 31 schemas moved
here from core's swagger.js, namespaced `Uo…` because core wins every key
collision in the merge; `Error` and `ValidationError` stay referenced by core's
names, since they resolve in the merged document.
**The frozen route manifest (§5.3)** is derived too, and by subtraction: CI
clones core at the ref pinned in ci/core-ref.json, generates its manifest without
this module and then with it, and the difference is what this module serves. That
buys the half of §5.3 that matters most for free — a module that shadowed or
displaced one of core's routes shows up as a REMOVAL, not merely as an addition
elsewhere. The same job checks the fragment against ground truth: every route
must have an operation and every operation must be a route.
**The release workflow** publishes `module-uo-<version>.tar.gz` plus a manifest
carrying its sha256. The version is declared in module.json rather than computed
from commit subjects, and the workflow never writes to a branch — it tags and
publishes — so `main` needs no push exception. The bundle is assembled from an
include list, because an exclude list ships whatever it forgot.
Four annotation defects, inherited from core and never visible until something
generated a spec from these files: two `requestBody` literals a brace short (the
route documented with an empty body), and two descriptions whose inner quoting
swagger-autogen cannot survive — it re-quotes `"` and a backtick to `'` before
evaluating, so either inside a single-quoted description ends the string early
and the annotation is dropped. It reports each one and then prints Success in
green, so the generator now captures its diagnostics and makes them fatal.
Also fixed while writing it: passing one shared `doc` to swagger-autogen six
times. It renders components.schemas from an EXAMPLE object and writes the result
back into what it was handed, so each pass re-wrapped the last and the fragment
came out at 484 MB.
- 409 server tests (+21), 40 client tests unchanged
- swagger-fragment.json: 69 paths covering all 72 routes
- routes.manifest.json: 72 routes; core's own surface unchanged, 0 removals
- verified end to end by assembling the bundle exactly as CI will, unpacking it
into a real core and regenerating the manifest
Refs: docs/website/MODULE_SYSTEM.md §2.7.1, MODULE_API.md §2.8, §5.3, §6.1a
Co-Authored-By: Claude <noreply@anthropic.com>
|
