Repository navigation
Start with Terminal, Files and themes, and pick more extensions in the setup assistant - #363
Conversation
…presets for PORTAL_DEFAULT_EXTENSIONS Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… hand Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…p and the new PORTAL_DEFAULT_EXTENSIONS values Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 27 minutes. View limit details
No actionable comments were generated in the recent review. Walkthrough
Merge Risk:
|
…ns or ends during the read
The overview took a row's update entry before it looked at the container's
image and asked whether there was one after: an update that began or ended
in between came out as an empty update ({}), which the page and the update
test read as one that had ended. The entry is now read once, after the look.
The fake Docker can hold the answer to an inspect, and a new test begins an
update while the page reads; it fails on the old code with {}. The update
test that failed now and then on CI (main d9082d5, #363) failed 6 of 168
runs on one CPU before, 0 of 120 after.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ns or ends during the read
The overview took a row's update entry before it looked at the container's
image and asked whether there was one after: an update that began or ended
in between came out as an empty update ({}), which the page and the update
test read as one that had ended. The entry is now read once, after the look.
The fake Docker can hold the answer to an inspect, and a new test begins an
update while the page reads; it fails on the old code with {}. The update
test that failed now and then on CI (main d9082d5, #363) failed 6 of 168
runs on one CPU before, 0 of 120 after.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Let a mode set model parameters, sent with every request of its chats
A mode the person made can set the temperature, top P, top K, min P and the
maximum answer length. They are kept on the mode (schema 17), read at each
request of a chat in it, and put on pi's stream options so that each API's
adapter sends them where its request has them. The model's own sampling
parameters in models.json stay for every field the mode leaves unset;
compactions and summaries are not touched.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* Set a mode's model parameters in Settings → Modes, and show them in the chat
The mode's page gets a Model parameters section with a field each for the
temperature, Top P, Top K, Min P and the longest answer, saved when the field
is left. The menu above the message box and the mode in the header name the
parameters a mode sets. The guide says what each field does, how it merges
over the model's own settings, and which services ignore which.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* Fix what the first review of the mode parameters found
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* Let a mode set the temperature only, and keep the schema at 16
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* Show a container's update whole on the Docker page, also when it begins or ends during the read
The overview took a row's update entry before it looked at the container's
image and asked whether there was one after: an update that began or ended
in between came out as an empty update ({}), which the page and the update
test read as one that had ended. The entry is now read once, after the look.
The fake Docker can hold the answer to an inspect, and a new test begins an
update while the page reads; it fails on the old code with {}. The update
test that failed now and then on CI (main d9082d5, #363) failed 6 of 168
runs on one CPU before, 0 of 120 after.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
Closes #304. A new portal starts with Terminal, Files and the theme pack only. Git, Canvases and Media become opt-in. The first-run setup assistant gets an Extensions step where you pick a preset or choose by hand.
What changes
Default set:
extensions/defaults.jsonis["terminal", "files", "themes"].Presets (
core/server/src/default-extensions.ts, served atGET /api/extensions/presets):The setup assistant is now Provider, Model, Extensions, Agent.
POST /api/packages.PORTAL_DEFAULT_EXTENSIONStakes:off;onordefault;Extensions they need are installed first. A value that is none of these is refused whole: the log says why, and the default set is installed, so a typo cannot leave a new portal without a terminal.
No two writers to pi's settings:
POST /api/packageswaits for the start install, so the step and the first start never write pi's settings at once.Docs:
extensions.md(What a portal starts with),deploying.mdand its environment table,configuration.md,upgrading.md,models.md,extension-ui.md. Alsogit.md,canvases.md,media.md,features.mdand the README, which said Git, Canvases and Media come with a new portal. German texts are added.How the issue's "To settle" points are built
default_extensions_installedrecord is untouched. Tests pin a portal that recorded the old six and one with Git installed by hand.off, a preset or a list.Checks
npm run buildandbuild:extensions: ok.Web
npx tsc -b: ok.npm test -w core/server: 1610 pass, 0 fail.Root
npm test: 2106 pass, 0 fail.tests/i18n: 17/17.Playwright under the flock (
settings,extension-bundled,extensions-settings,extension-requires): 69 passed. Among them are 10 new specs for the step:Old code: with
defaults.jsonback at six, the extension-packages and real-list tests fail. The three review-fix specs fail with the old components, and the lock test fails without the wait.A real local portal with a fresh data folder:
The step itself was not clicked through in that portal, because it had a provider set already. The Playwright specs cover it.
One review round (correctness, security, spec): 5 findings, all fixed. The medium one was stale "installed on first start" wording in five docs pages.
Also: an empty update on the Docker page (#360)
CI failed on
extensions/docker/test/update.test.mts, the same test that had failed once on main (d9082d5). The cause is a race in Docker for extensions' overview, not in this PR's code:update: {}, which the page and the test read as one that had ended.The fix:
{}.On one CPU, the update test failed 6 of 168 runs before and 0 of 120 after.
Owner decisions (2026-11-03)
All kept as built: a portal coming straight from 0.1.0 starts with the three; a refused
PORTAL_DEFAULT_EXTENSIONSinstalls the default set; Everything stays as wide as it is; onlyPOST /api/packageswaits for the start install.What was asked
upgrading.mdand not installed automatically. Should a used portal with no record get the old six on its first start instead? That would be a small change.PORTAL_DEFAULT_EXTENSIONS: it logs and installs the default set. The alternatives are to install nothing (likeoff) or to refuse to start.core/web/src/shipped-extensions.ts) with German entries, because the packages' own descriptions are long and English only. A new extension that comes with Pithagoras falls back to its package description until it is added there.POST /api/packageswaits for the start install.POST /packages/update,DELETE /packagesandPUT /extensions/enabledalso write pi's settings and do not wait. Extend the wait to them?🤖 Generated with Claude Code