* docs(skills): split the global Skills into project and installation
nocobase-create-app creates a project to develop; nocobase-app-installer
installs built NocoBase where it runs — a Hub from its template, or an
application's archive — and upgrades it. A Hub is installed, not created,
unless the user will develop the Hub's own code. Both Skills carry the same
routing table, and a request to install NocoBase on a server with no project
makes the agent ask what it is for.
nocobase-create-app also says which template to pick and, at the end, how the
application reaches production. nocobase-app-installer separates the build
machine from the one that runs NocoBase, splits installing into what every
installation needs, an archive and a Hub, and covers several installations on
one machine. skills/README.md and AGENTS.md describe the split.
* refactor(app-installer): stop writing HUB_STORAGE_DIR for a Hub
The release carrying the installer also publishes a Hub that reads
APP_STORAGE_DIR, so the old name the installer wrote beside it for earlier Hub
releases is no longer needed. Installing an earlier Hub is refused with
STORAGE_IN_RELEASE.
* ci: smoke the Hub template from this checkout on pull requests
A pull request can change the installer and the Hub template together, as the
move to APP_STORAGE_DIR did, and the Hub smoke job paired this checkout's
installer with the published Hub, so it failed until a release. The Quality
workflow now starts a local registry from Build's tarballs, tags the packages
resolved by tag, and runs the template smoke with the installer and the Hub
both from this checkout. The published Hub is still installed daily and on
demand by app-installer-smoke.yml, which no longer runs that job on pull
requests. The registry steps live in a new local-registry action; the release
workflows' verify-create-app is left as it is.
* test: cover the app-installer smoke job in the Quality gate test
The test runs the gate's shell with every job's result; it now passes the new
job's result and checks that a failure of it fails the gate.
* fix(templates): align application framework with Default
* fix(templates): address settings access and review gaps
* test(hub): await the real API keys page loader
* fix(hub): start installed hosts in development
* fix(hub): preserve default application identity in generated config
The database is no longer chosen at generation time. Since dialects were
split into @nocobase/db-* packages, a connection may only use a dialect
the application registers in server/config/database.ts, and that file
cannot be overridden from config.yml. Adding a bare driver to
dependencies — what --db-dialect did — produced an application that
failed to start with `Database dialect "postgres" is not registered.`
for every dialect but SQLite.
config.yml is now built from the template's own config.example.yml with
the two secrets filled in, rather than assembled here. The example
documents everything an application can be configured with, and a file
written from scratch carried a fraction of it and went stale whenever
the example grew.
A hub is generated the same way. It owns a database like any other
application, so it gets a config.yml too: without one it started in
install mode on a secret regenerated every boot, invalidating every
session on restart. It also gets its plugin skills synchronized, and no
longer gets the vestigial app-dist/ directory that nothing reads.
The example declares both secrets as live keys so the generator can fill
them in by replacing a value. That leaves one way to run on the
placeholder — copying config.example.yml by hand — so resolveAuthSecret
and resolveAppSessionConfig now refuse it by name.
Also: the release smoke test no longer passes --db-dialect, which strict
parsing would reject; the fallback .gitignore covers .env; and the dead
dialect-tag and driver-version helpers are gone.
PiEgg