Repository navigation
feat(onboarding): the hardening card's second step — the Cloudflare Tunnel #2380 asked for - #2564
Merged
Merged
Conversation
Two decisions on top of the card-UX change, both about a step being spent
without anyone seeing it.
1. THE CARD ADVANCES AT `https-domain` INSTEAD OF RETIRING.
The guide advises two steps and said outright that they stack — then
disappeared after the first, because `installTlsPosture === 'https-domain'`
was the retirement condition. Step two was mentioned once, on the only
surface that raises it, and then never again. A Cloudflare Tunnel is also
invisible to that condition by construction (the posture is pure string
parsing of the advertised URL; nothing probes a socket), so no amount of
verification would have brought the card back.
`https-domain` now selects a STAGE rather than hiding: the card keeps its
slot, swaps to the tunnel step, and a dismissal is what ends it. The tunnel
stage carries no primary button — the last move is `TUNNEL_TOKEN` in `.env`
under a compose profile, on the host — so the remaining step is named on the
card FACE, not only behind the disclosure, and the copy says plainly that
dismissing is a fine answer. Step one's block and the stacking sentence are
`v-if`'d off once the domain exists; there is no point advising a step that
is already done.
Dismissal is per stage, and that is load-bearing rather than tidy: one key
would let "you are on a bare IP" silently consume tunnel advice the operator
has never been shown. The address stage keeps the original key, so an
existing dismissal keeps holding and nothing migrates.
2. THE WARM ASK IS SPENT ONLY ONCE IT HAS BEEN SEEN.
Same failure one card over, and this one was introduced by the stacking rule
in the previous commit. `.onboarding-stack` hides with CSS, so a hidden card
still MOUNTS — and `FinishSetupCard` marked ent#437's one-shot warm re-ask
shown the moment `consentVisible` flipped. On a marketplace install the
hardening guide holds the slot, so the warm ask was burned invisibly and the
operator later met the weaker cold copy, if they met one at all. That ask
exists precisely because a cold ask at first login converts badly; spending
it behind another card is worse than not having it.
It now marks itself shown from an IntersectionObserver on the card root.
That is the right instrument rather than a `display` check: the card becomes
visible when a SIBLING is dismissed, which changes no state this component
can watch. Intersecting is necessary and not sufficient — the callback
re-checks that the section still wants to render and is still the warm
variant.
Verified in a browser against a live stack, forcing each posture:
· `https-ip` card renders, `Add a domain` present
· `https-domain` card renders, zero primary buttons, "Domain set" badge,
Cloudflare named on the face; expanded shows the tunnel
block and omits step one and the stacking sentence
· address dismissed, then a domain configured → the tunnel stage still renders
· dismiss at the tunnel stage → card retires, queue advances, and only the
tunnel key is written
· warm ask: `trinity_telemetry_warm_ask_shown` is absent while the card sits
hidden behind the guide, and written only once the card is really on screen
Tests: hardeningGuide.spec.js pins the advance, the per-stage keys, the
face-level naming of the remaining step, and that `success` is reserved for the
one posture that completed a step; onboardingStack.spec.js pins that the warm
ask is not spent from the visibility watcher. Both new guards fail when the old
behaviour is restored. 84 files / 1839 tests pass; check:tokens clean.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01G3FfTmxVyfmLNWtAXxMSQ1
…2380) The POSTURE_COPY docblock closed with "There is deliberately no `https-domain` entry — that posture never renders", sitting directly above the `https-domain` entry the tunnel-stage commit added. That sentence was correct while the card retired itself the moment a domain was set; it stopped being correct in the same commit that gave the card a second stage, and a reader trusting it would conclude the entry below was dead code. Replaced with what the posture now does: it is the one posture that speaks only to step two. Comment-only — no behaviour change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01F2q1Xs3GtLLQemND1PgD99
vybe
approved these changes
Sep 7, 2026
vybe
left a comment
vybe
left a comment
Contributor
There was a problem hiding this comment.
Validated via /validate-pr. Closes #2380 (P2 feature). 7 new unit tests incl. non-happy-path (per-stage dismissal scoping, in-session advance). Security scans clean, design-token check passes, e2e + frontend build green.
One doc gap, non-blocking: docs/memory/feature-flows/install-provenance.md still states the card retires at posture https-domain with no client state involved, and describes dismissal as a single localStorage key. Both are superseded by the tunnel stage and dismissKeyForStage(). Filing a follow-up.
This was referenced Sep 7, 2026
obasilakis
added a commit
that referenced
this pull request
Sep 11, 2026
… TLS gate (#2380) /validate-pr on #2707 found the branch shipping new capability without the requirements and feature-flow updates CLAUDE.md requires. Written from the code at this commit, not from the PR body. Requirements (docs/memory/requirements/infrastructure.md): - Corrected: HOST-010 and the section 8.10 description, PROV-006 (flags now carry hardening_guide_eligible), PROV-009 (the second path has been a Cloudflare Tunnel since #2564, not a VPN), PROV-010 (a two-stage card gated on hardening_guide_eligible, with a domain field), PROV-011 (start.sh --provision now writes TRINITY_INSTALL_SOURCE). - Added: PROV-012 one provisioning implementation, three callers; PROV-013 the portless container firewall and the metadata-service block; PROV-014 the prompting installer and do-script provenance; PROV-015 the on-demand TLS ask gate. Feature flows: install-provenance (two-stage card, do-script, hardening_guide_eligible, the domain field and ask gate; fixes both stale claims in #2593), hosted-install (a Provision Layer section), telemetry-sharing (the IntersectionObserver gate from #2593), and their index rows. Stale sentences in agent-lifecycle.md, backend.md, api-endpoints.md and DEPLOYMENT.md corrected. Fixes #2593 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PdRMazCDYVoxqLFw6uKm3a
vybe
pushed a commit
that referenced
this pull request
Sep 13, 2026
…er, and a domain that gets a certificate (#2380) (#2707) * feat(deploy): one installer provisions the machine, three callers use it (#2380) Provisioning a bare cloud VM for Trinity existed in three copies: the Packer bakery, the Packer first-boot script, and a hand-written script pasted into the DigitalOcean deploy doc. They had already drifted — one carried a DOCKER-USER DROP list missing 8081, so the login page answered plain HTTP past the certificate and past the http->https redirect, on the image whose headline design note is that everything reaches users through Caddy on 80/443. `start.sh --provision --cloud <name>` is now the only implementation, in two phases because a snapshot-based image splits them: `--machine-only` (packages, pinned Caddy with the IP-certificate floor asserted, ufw, the firewall unit) is bakeable; `--site-only` (the instance's own IP, the .env keys, the Caddyfile, the certificate) is per-instance. The bakery calls the first, first boot calls the second and continues into the install, and a doc-driven install calls both. firstboot.sh drops from 230 lines to 118 and 01-provision.sh from 176 to 99. It is off by default and refuses unless it is root on Linux with a cloud metadata service answering, so it stays inert on a developer laptop. An ADMIN_PASSWORD in the environment is now written through to .env, so an install script does not have to hand-roll its own .env writer. The firewall rule is inverted rather than enumerated. Everything entering a container from off-box is dropped whatever the port, with two RETURNs ahead of it: replies to connections a container opened (without which agents lose outbound internet), and traffic from Docker's own bridges. Naming what is inside rather than which interface is outside also covers DigitalOcean's private eth1. There is no list left to drift, so the test that policed the list is replaced by one that pins the ordering and the absence of a fourth copy. Also widens the first-run hardening guide to doc-driven DigitalOcean installs, which #2380's author amended their own acceptance criterion to require. The installer records `do-script` — honest, because it refuses to run at all unless DO's metadata service answers — and `hardening_guide_eligible` is a separate gate from `marketplace_install` rather than a widening of it, so the guide reaches these installs without anyone claiming a vendor listing they never came from. Deliberately still provenance and never TLS state: the managed fleet runs plain HTTP behind a tunnel with no domain and a 100.x address, so a posture-based gate would fire on every paying client forever. The https-ip copy gains the renewal caveat, hedged the way that block's own acceptance criterion requires: a ~6-day certificate renewed only while the machine runs is a property of the profile such an install is known to use, so it is stated as what happens after a long shutdown, never as a claim about this instance's live certificate. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QvfFoqB2v2zPyXJXeyBGbP * feat(deploy): a prompting DigitalOcean installer, not a file to edit (#2380) The deploy doc's flow was eight manual steps in DigitalOcean's web console, one of which is "paste this script into a textarea after editing three lines". Seven of those eight can be a script, and the one that cannot — open the URL and sign in — is the human's job anyway. A console click-path also cannot satisfy this work's own acceptance criterion that every command in the doc has been executed verbatim at least once: nobody can execute "tick Advanced Options", so the most error-prone step is the one that ships permanently untested. It prompts rather than shipping a file to edit. "Download this and change four lines" fails the audience the doc exists for, and it puts two secrets in a file on disk; `read -rs` keeps both off the terminal, out of shell history, and out of every file but the droplet's own user-data. Checks come before questions, so a missing doctl is never discovered after collecting two credentials. The password is asked twice because it is the credential for a server that does not exist yet — a typo is not recoverable by retrying, it is a rebuild — and the paid resource is confirmed before it is created. Prompts still read from a pipe, so the whole flow stays drivable in a test: printf 'pw\npw\ntoken\n\n\ny\n' | bash scripts/deploy/trinity-do-create.sh The droplet-side half is unchanged and stays one copy: clone, then `start.sh --provision --cloud digitalocean --hosted --unattended`, the same installer the Packer image runs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QvfFoqB2v2zPyXJXeyBGbP * fix(deploy): containers cannot read the instance metadata service (#2380) A cloud instance serves its own user-data verbatim from link-local, for the life of the machine, to anything that can reach it — and on a script-installed droplet that user-data carries the Trinity admin password and the operator's Claude subscription token. Agent containers could reach it. An agent running untrusted model-authored code is precisely the case that must not be able to read the credential that owns the box. Dropped outbound from containers as the RFC 3927 range rather than the well-known 169.254.169.254 host: the property being blocked is "link-local, host-adjacent, not routable", and every cloud publishes its metadata endpoint somewhere in that range, so the single address would have been a DigitalOcean- shaped fix to a general problem. Position is load-bearing and is what the test pins. The DROP sits after the conntrack RETURN (so only the opening packet of a metadata connection is ever evaluated, which is enough — it never establishes) and BEFORE the two bridge RETURNs. Behind them it would be decoration: container-originated traffic RETURNs out of the chain before reaching it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QvfFoqB2v2zPyXJXeyBGbP * feat(deploy): make "add a domain" actually work, not just be advertised (#2380) The hardening card's step one told the operator to point DNS at the server and set the Public URL in Settings, then said "whatever terminates TLS in front of it picks up the name". Nothing does. `public_chat_url` is a display and webhook-base setting, and the card's own source comment says so — no code reads it and reconfigures a proxy, a listener or a certificate. On every install this card is shown to, Caddy is holding a single `https://<IP>` site block written at provision time. So the sequence the card produced was: operator sets the URL, install_tls_posture flips to `https-domain` by string-parsing that setting, the card treats step one as complete and advances to the tunnel step, and the domain serves a certificate error because the web server still answers only to the IP. The card retired on a state it had helped break, and the instance was worse off than before it gave the advice. `scripts/deploy/set-domain.sh` does the job the card was describing. It refuses unless DNS already points at this machine — that check is first, before anything is touched, because issuance validates over the name and a stale A record is what turns a working instance into a broken one. Then it rewrites the Caddyfile for the name (no `shortlived` profile: a real name earns an ordinary ~90-day certificate, which is the upgrade being made), validates, reloads, waits for the certificate against the real hostname with the system trust store, and only then tells Trinity its new address. Every failure after the rewrite restores the previous config and reloads, so a bad run ends where it started. The bare IP is kept as a redirect rather than dropped, with its short-lived certificate, so links handed out before the domain existed keep working — a redirect that cannot complete a handshake is not a redirect. It runs on the server because it has to: Trinity is in a container with no host privileges, so it can neither write /etc/caddy/Caddyfile nor reload Caddy. The card now says that, names the command, and keeps every honest claim the previous copy made — it only moves the actor from "whatever is out there, somehow" to something the operator can actually run. That constraint is the same one that already keeps the tunnel step to prose, so the card is now consistent about it. `set_env_key` moves to scripts/deploy/env-file.sh, sourced by both writers: a .env writer that disagrees with itself corrupts credentials silently, and this branch exists because two copies of provisioning logic drifted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QvfFoqB2v2zPyXJXeyBGbP * fix(onboarding): the card's one action is the one that works (#2380) Walking the journey a real operator takes found the previous fix had covered the wrong half. The card said the right thing in its disclosure and still pointed its primary button at the trap. The operator who HAS a domain — exactly who the button was for — clicked "Add a domain", landed on Settings → General → Public URL (a bare input, a Save button, no guard, placeholder `https://your-domain.com`), typed their domain and saved. That sets the name Trinity hands out and reconfigures nothing: Caddy still held only the `https://<IP>` site written at provision time, so the domain served a certificate error while the old IP link kept working and the instance looked fine. `install_tls_posture` then flipped to `https-domain` by string-parsing their own input, the card advanced to the tunnel stage, and the address section carrying the command that would have fixed it — `v-if` on that stage — disappeared. The UI congratulated them on a step it had just helped them break, and removed the way back. So the face carries the command now, not a link to the field. There is no navigation button because there is nowhere useful to navigate: `set-domain.sh` sets the Public URL itself, and setting it by hand is not enough on its own. `select-all` on the block so one click takes the whole line. The disclosure keeps the reasoning, including the sentence saying explicitly that the settings field alone does not do it. The three tests that pinned the old shape are updated rather than deleted, each carrying why the assertion inverted — "links to Settings → General" was a true description of a defect. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QvfFoqB2v2zPyXJXeyBGbP * feat(deploy): adding a domain is a settings field, not a shell command (#2380) The last two attempts at this both ended with an operator needing a root shell on the droplet, which a non-engineer following a deploy guide does not have. The constraint that forced it was real — Trinity is containerised and can neither rewrite /etc/caddy/Caddyfile nor reload Caddy — but it was the wrong thing to work around. Inverting the direction removes it entirely: Caddy asks Trinity whether a hostname is allowed, Trinity answers from what an admin saved, and no privilege moves into the container. The provisioned Caddyfile gains a catch-all site with on-demand TLS and an `ask` gate at /api/public/tls-allowed. Save a domain in Settings, point its A record here, and the first visit obtains the certificate. That is the whole step, which is what this card claimed from the beginning. The gate carries the entire security model, so it allows exactly one name: the host of the saved public_chat_url, parsed with urlparse and compared for equality. Substring matching would hand `evil-example.com` a certificate request from a server configured for `example.com`. It fails closed on an unset URL and on a failed settings read — `on_demand` without a working gate turns the instance into a certificate requester for anyone who points DNS at its address, until the ACME account is rate-limited and the operator's own renewals start failing. Executed rather than grepped in the tests: a static check cannot tell an exact match from a substring one, and that difference is the whole of it. set-domain.sh is deleted. It was written for this job two commits ago and is now a second way to do something that works from the browser; keeping it as a "fallback" would have been keeping a path nobody tests for a case that no longer exists. Caddyfile syntax verified against the 2.11.x docs rather than memory: `interval` and `burst` are removed from on_demand_tls, `ask` receives ?domain= and authorises on 2xx. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QvfFoqB2v2zPyXJXeyBGbP * fix(deploy): attach the account's SSH keys to the droplet it creates (#2380) Without this the droplet has no key on it, DigitalOcean emails a root password to the account owner, and the only way to a shell is the browser console. That is fine until something needs looking at, which on a first deploy is exactly when it happens. Attaches keys that already exist on the account — the operator's own, on the operator's account, going onto the operator's server. Nothing is created, uploaded or generated, and an account with no keys behaves exactly as before. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QvfFoqB2v2zPyXJXeyBGbP * fix(deploy): portable mktemp in the DigitalOcean installer (#2380) `mktemp -t trinity-user-data` takes a bare prefix on macOS/BSD, but GNU coreutils reads the same argument as a template and requires the trailing X's — so on Ubuntu (i.e. every Linux operator) the installer died with "mktemp: too few X's in template" immediately after collecting both secrets and confirming the create. Use a full path template instead: portable on both, and it keeps the umask-077 0600 mode the user-data file needs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LgRv6koYJKzor7ZHoRkGYS * test(deploy): the X-DO-MARKETPLACE guard reads start.sh, where the Caddyfile is written now #2680's guard pinned the header inside firstboot.sh's Caddyfile heredoc; #2380 moved that heredoc into `start.sh --provision --site-only`, so the merge left the test asserting a file that no longer writes a Caddyfile. Point it at start.sh and also pin that the header is keyed on the do-marketplace provenance, since the same function serves the doc install. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015owqMKD5QDjzZrUTF2Joht * test(deploy): restore the two firewall guards the port-list rewrite dropped (#2380) 6104b0e deleted test_2281_firstboot_port_exposure.py because the DOCKER-USER rule no longer enumerates ports, so the tests that policed the list had nothing left to check. Two of its five tests were never about the list, and they went with the file: - ufw and iptables-persistent are never both installed. ufw Breaks iptables-persistent, so installing it to persist the rules makes apt remove ufw, and the install dies later at `ufw --force reset`. - the firewall rules are re-applied on every boot. Without iptables-persistent, trinity-docker-firewall.service is the only thing that survives a reboot; without it every Docker-published port reopens after the first restart (#2281 review I1). Both are back in test_2380_provision_single_source.py, pointed at where the code lives now: start.sh --provision installs ufw and writes the unit as a heredoc, so the tests read that heredoc instead of a shipped unit file. Each was checked against a mutation of start.sh (iptables-persistent added, the enable line removed, After=docker.service removed) and fails on each. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PdRMazCDYVoxqLFw6uKm3a * fix(deploy): snap doctl cannot read /tmp, and an apostrophe kills first boot (#2380) (#2683) * fix(deploy): snap doctl cannot read /tmp, and an apostrophe kills first boot (#2380) Two fixes to the DigitalOcean installer, found QA'ing it across macOS and Linux. Neither is visible on the machine it was written on. **A snap-installed doctl has a private /tmp.** On most Linux distributions doctl comes from snap, and a snap runs in its own mount namespace — a file written to the real /tmp is not there when doctl opens it, so it fails on a file that demonstrably exists: Error: open /tmp/trinity-user-data.XXXXXX: no such file or directory Snap's `home` interface can read non-hidden paths under $HOME, so a snap doctl gets the file there instead; everyone else keeps TMPDIR. The name stays visible because that interface denies dotfiles too, `umask 077` still makes it 0600, and the EXIT trap still removes it. Reported by dolho, who hit it on Linux. The `mktemp -t` half of his finding is already on this branch (aaa3de5). A snap doctl with no usable $HOME now fails at that point with an explanation, rather than at the droplet-create call with a path error, after both prompts. **A single quote in either secret breaks the droplet's first boot.** Both are interpolated into single-quoted assignments in the user-data, so a `'` inside one closes the string early: export ADMIN_PASSWORD='Tr0ub4dor's!Horse' bash: unexpected EOF while looking for matching `'' Not a hypothetical input — the password rules require a special character and `'` is one, so that password passes this script's own check and the backend's. The failure is expensive out of proportion to the typo: the droplet is created and billing before first boot runs, the operator watches a 15-minute progress bar end in a timeout, and the cause is invisible without reading the install log. Both secrets now go through `_shquote` (the portable `'\''` idiom). Verified on both platforms rather than reasoned about — macOS bash 3.2 and ubuntu:24.04 bash 5.2 / GNU coreutils 9.4, driving the real prompt flow with a stubbed doctl and diffing the generated user-data: - `mktemp -t trinity-user-data` → macOS OK, Linux `too few X's in template` - the full template → both OK, mode 0600 - snap-detection truth table → identical on both - password round-trip → 7/7 both platforms, including apostrophes, backticks, backslashes, tabs and non-ASCII; the unfixed script fails the apostrophe cases with a syntax error `tests/unit/test_2380_installer_portability.py` pins all three. The round-trip guard is executed, not pattern-matched — it runs the script's own `_shquote` and lets a shell parse the result back, so it catches any breakage rather than the one spelling that was wrong. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011sj48trT3XmyaSus4GUtXB * test(deploy): the installer's default tag must track VERSION (#2380) `trinity-do-create.sh` hardcodes the release it installs: TRINITY_IMAGE_TAG="${TRINITY_IMAGE_TAG:-v0.9.5-rc2}" That default IS what operators get — the guide tells them to run the script straight off a tag with no environment set. So on the day `v0.9.5` is cut, a script fetched from the v0.9.5 tag still clones and pulls `v0.9.5-rc2` unless someone remembers this one line. Nothing catches it today. It is not a syntax error, the rc2 images still exist and still pull, and the install SUCCEEDS — it just installs the previous release candidate. The operator cannot tell, and neither can CI: the release checklist's "VERSION match" step compares the VERSION file to the tag, not this script to either. The guard ties them together. It passes now (VERSION `0.9.5-rc2`, default `v0.9.5-rc2`) and fails the moment VERSION is bumped for the cut — which is exactly when someone needs telling. Verified by mutation: setting VERSION to `0.9.5` produces AssertionError: trinity-do-create.sh installs v0.9.5-rc2 but VERSION says 0.9.5. A second case pins the `v` prefix. One string feeds both `git clone --branch` (needs the git ref) and `docker pull` (published under both spellings), so only the `v` form works for both — the #2471 failure, where `v0.9.5-rc1` shipped without its v-prefixed image alias and left no tag value able to build the marketplace snapshot. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011sj48trT3XmyaSus4GUtXB * fix(deploy): refuse before the prompts, quote the tag, and test the installer by running it (#2380) Addresses review I1-I3 on #2683. I1: the snap-doctl-without-$HOME refusal ran after both secret prompts, breaking the script's own "checks first, questions second" rule. The USER_DATA_DIR decision moves into the pre-flight block beside `doctl account get`; mktemp stays where it was. I2: TRINITY_IMAGE_TAG was the third single-quoted interpolation in the user-data heredoc and the only unquoted one. It now goes through _shquote, and the static guard asserts the rule (every '${...}' in the heredoc is a _Q value) instead of two spellings of it. I3: the guards grepped for the quoted spelling and never ran the script. New tests run the real installer against a stub doctl (package and snap paths, apostrophes and shell metacharacters in the password, token and tag), then `bash -n` the captured user-data and evaluate its real export lines and subscription call in context, and assert a snap doctl without $HOME is refused before any question. Running it found a fourth defect: under `set -u`, bash < 4.4 (macOS's /bin/bash is 3.2) treats an empty "${SSH_ARGS[@]}" as unbound, so an account with no SSH keys died at "Creating the droplet...", after both secrets were typed. Expanded as ${SSH_ARGS[@]+"${SSH_ARGS[@]}"}. Each fix was checked by reverting it: the tests fail on every revert. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PdRMazCDYVoxqLFw6uKm3a --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> * docs(deploy): describe the provisioning path, installer, firewall and TLS gate (#2380) /validate-pr on #2707 found the branch shipping new capability without the requirements and feature-flow updates CLAUDE.md requires. Written from the code at this commit, not from the PR body. Requirements (docs/memory/requirements/infrastructure.md): - Corrected: HOST-010 and the section 8.10 description, PROV-006 (flags now carry hardening_guide_eligible), PROV-009 (the second path has been a Cloudflare Tunnel since #2564, not a VPN), PROV-010 (a two-stage card gated on hardening_guide_eligible, with a domain field), PROV-011 (start.sh --provision now writes TRINITY_INSTALL_SOURCE). - Added: PROV-012 one provisioning implementation, three callers; PROV-013 the portless container firewall and the metadata-service block; PROV-014 the prompting installer and do-script provenance; PROV-015 the on-demand TLS ask gate. Feature flows: install-provenance (two-stage card, do-script, hardening_guide_eligible, the domain field and ask gate; fixes both stale claims in #2593), hosted-install (a Provision Layer section), telemetry-sharing (the IntersectionObserver gate from #2593), and their index rows. Stale sentences in agent-lifecycle.md, backend.md, api-endpoints.md and DEPLOYMENT.md corrected. Fixes #2593 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PdRMazCDYVoxqLFw6uKm3a * chore(deploy): drop references to set-domain.sh, which no longer exists (#2380) 0423e6c replaced scripts/deploy/set-domain.sh with a Settings field, but two comments still named it as env-file.sh's second caller, and the provisioning test kept an unused path constant pointing at it. start.sh is now the only script that sources env-file.sh; the comments say so. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PdRMazCDYVoxqLFw6uKm3a * test(deploy): pin the on-demand site block and reach the ask gate through FastAPI (#2380) Review follow-ups on #2707, all mechanical. The Caddyfile guard asserted `"on_demand" in body`, which the global `on_demand_tls` option already satisfies: deleting the catch-all `https:// { tls { on_demand } }` site — the entire "add a domain" feature — passed every test. It now extracts the heredoc and asserts that site as a block, and that the bare-IP site still asks for a short-lived certificate. Checked by deleting the block: the test fails. Nothing reached GET /api/public/tls-allowed through FastAPI. The decision (exact hostname, fail closed) is proved by exec-slicing the function, which cannot see the route's path, its query parameter, or whether it gained an auth dependency — and Caddy holds no credential, so a 401 there would refuse every certificate with the failure visible only in a live handshake. A new test mounts the real router and calls the real URL. Settings' install-source label map had no entry for `do-script`, so a script-installed droplet showed the raw value. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PdRMazCDYVoxqLFw6uKm3a --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Oleksii Dolhov <oleksii.dolhov@gmail.com>
vybe
pushed a commit
that referenced
this pull request
Sep 14, 2026
…ials without a terminal (trinity-enterprise#580, #581, #582) (#2715) * feat(deploy): one installer provisions the machine, three callers use it (#2380) Provisioning a bare cloud VM for Trinity existed in three copies: the Packer bakery, the Packer first-boot script, and a hand-written script pasted into the DigitalOcean deploy doc. They had already drifted — one carried a DOCKER-USER DROP list missing 8081, so the login page answered plain HTTP past the certificate and past the http->https redirect, on the image whose headline design note is that everything reaches users through Caddy on 80/443. `start.sh --provision --cloud <name>` is now the only implementation, in two phases because a snapshot-based image splits them: `--machine-only` (packages, pinned Caddy with the IP-certificate floor asserted, ufw, the firewall unit) is bakeable; `--site-only` (the instance's own IP, the .env keys, the Caddyfile, the certificate) is per-instance. The bakery calls the first, first boot calls the second and continues into the install, and a doc-driven install calls both. firstboot.sh drops from 230 lines to 118 and 01-provision.sh from 176 to 99. It is off by default and refuses unless it is root on Linux with a cloud metadata service answering, so it stays inert on a developer laptop. An ADMIN_PASSWORD in the environment is now written through to .env, so an install script does not have to hand-roll its own .env writer. The firewall rule is inverted rather than enumerated. Everything entering a container from off-box is dropped whatever the port, with two RETURNs ahead of it: replies to connections a container opened (without which agents lose outbound internet), and traffic from Docker's own bridges. Naming what is inside rather than which interface is outside also covers DigitalOcean's private eth1. There is no list left to drift, so the test that policed the list is replaced by one that pins the ordering and the absence of a fourth copy. Also widens the first-run hardening guide to doc-driven DigitalOcean installs, which #2380's author amended their own acceptance criterion to require. The installer records `do-script` — honest, because it refuses to run at all unless DO's metadata service answers — and `hardening_guide_eligible` is a separate gate from `marketplace_install` rather than a widening of it, so the guide reaches these installs without anyone claiming a vendor listing they never came from. Deliberately still provenance and never TLS state: the managed fleet runs plain HTTP behind a tunnel with no domain and a 100.x address, so a posture-based gate would fire on every paying client forever. The https-ip copy gains the renewal caveat, hedged the way that block's own acceptance criterion requires: a ~6-day certificate renewed only while the machine runs is a property of the profile such an install is known to use, so it is stated as what happens after a long shutdown, never as a claim about this instance's live certificate. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QvfFoqB2v2zPyXJXeyBGbP * feat(deploy): a prompting DigitalOcean installer, not a file to edit (#2380) The deploy doc's flow was eight manual steps in DigitalOcean's web console, one of which is "paste this script into a textarea after editing three lines". Seven of those eight can be a script, and the one that cannot — open the URL and sign in — is the human's job anyway. A console click-path also cannot satisfy this work's own acceptance criterion that every command in the doc has been executed verbatim at least once: nobody can execute "tick Advanced Options", so the most error-prone step is the one that ships permanently untested. It prompts rather than shipping a file to edit. "Download this and change four lines" fails the audience the doc exists for, and it puts two secrets in a file on disk; `read -rs` keeps both off the terminal, out of shell history, and out of every file but the droplet's own user-data. Checks come before questions, so a missing doctl is never discovered after collecting two credentials. The password is asked twice because it is the credential for a server that does not exist yet — a typo is not recoverable by retrying, it is a rebuild — and the paid resource is confirmed before it is created. Prompts still read from a pipe, so the whole flow stays drivable in a test: printf 'pw\npw\ntoken\n\n\ny\n' | bash scripts/deploy/trinity-do-create.sh The droplet-side half is unchanged and stays one copy: clone, then `start.sh --provision --cloud digitalocean --hosted --unattended`, the same installer the Packer image runs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QvfFoqB2v2zPyXJXeyBGbP * fix(deploy): containers cannot read the instance metadata service (#2380) A cloud instance serves its own user-data verbatim from link-local, for the life of the machine, to anything that can reach it — and on a script-installed droplet that user-data carries the Trinity admin password and the operator's Claude subscription token. Agent containers could reach it. An agent running untrusted model-authored code is precisely the case that must not be able to read the credential that owns the box. Dropped outbound from containers as the RFC 3927 range rather than the well-known 169.254.169.254 host: the property being blocked is "link-local, host-adjacent, not routable", and every cloud publishes its metadata endpoint somewhere in that range, so the single address would have been a DigitalOcean- shaped fix to a general problem. Position is load-bearing and is what the test pins. The DROP sits after the conntrack RETURN (so only the opening packet of a metadata connection is ever evaluated, which is enough — it never establishes) and BEFORE the two bridge RETURNs. Behind them it would be decoration: container-originated traffic RETURNs out of the chain before reaching it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QvfFoqB2v2zPyXJXeyBGbP * feat(deploy): make "add a domain" actually work, not just be advertised (#2380) The hardening card's step one told the operator to point DNS at the server and set the Public URL in Settings, then said "whatever terminates TLS in front of it picks up the name". Nothing does. `public_chat_url` is a display and webhook-base setting, and the card's own source comment says so — no code reads it and reconfigures a proxy, a listener or a certificate. On every install this card is shown to, Caddy is holding a single `https://<IP>` site block written at provision time. So the sequence the card produced was: operator sets the URL, install_tls_posture flips to `https-domain` by string-parsing that setting, the card treats step one as complete and advances to the tunnel step, and the domain serves a certificate error because the web server still answers only to the IP. The card retired on a state it had helped break, and the instance was worse off than before it gave the advice. `scripts/deploy/set-domain.sh` does the job the card was describing. It refuses unless DNS already points at this machine — that check is first, before anything is touched, because issuance validates over the name and a stale A record is what turns a working instance into a broken one. Then it rewrites the Caddyfile for the name (no `shortlived` profile: a real name earns an ordinary ~90-day certificate, which is the upgrade being made), validates, reloads, waits for the certificate against the real hostname with the system trust store, and only then tells Trinity its new address. Every failure after the rewrite restores the previous config and reloads, so a bad run ends where it started. The bare IP is kept as a redirect rather than dropped, with its short-lived certificate, so links handed out before the domain existed keep working — a redirect that cannot complete a handshake is not a redirect. It runs on the server because it has to: Trinity is in a container with no host privileges, so it can neither write /etc/caddy/Caddyfile nor reload Caddy. The card now says that, names the command, and keeps every honest claim the previous copy made — it only moves the actor from "whatever is out there, somehow" to something the operator can actually run. That constraint is the same one that already keeps the tunnel step to prose, so the card is now consistent about it. `set_env_key` moves to scripts/deploy/env-file.sh, sourced by both writers: a .env writer that disagrees with itself corrupts credentials silently, and this branch exists because two copies of provisioning logic drifted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QvfFoqB2v2zPyXJXeyBGbP * fix(onboarding): the card's one action is the one that works (#2380) Walking the journey a real operator takes found the previous fix had covered the wrong half. The card said the right thing in its disclosure and still pointed its primary button at the trap. The operator who HAS a domain — exactly who the button was for — clicked "Add a domain", landed on Settings → General → Public URL (a bare input, a Save button, no guard, placeholder `https://your-domain.com`), typed their domain and saved. That sets the name Trinity hands out and reconfigures nothing: Caddy still held only the `https://<IP>` site written at provision time, so the domain served a certificate error while the old IP link kept working and the instance looked fine. `install_tls_posture` then flipped to `https-domain` by string-parsing their own input, the card advanced to the tunnel stage, and the address section carrying the command that would have fixed it — `v-if` on that stage — disappeared. The UI congratulated them on a step it had just helped them break, and removed the way back. So the face carries the command now, not a link to the field. There is no navigation button because there is nowhere useful to navigate: `set-domain.sh` sets the Public URL itself, and setting it by hand is not enough on its own. `select-all` on the block so one click takes the whole line. The disclosure keeps the reasoning, including the sentence saying explicitly that the settings field alone does not do it. The three tests that pinned the old shape are updated rather than deleted, each carrying why the assertion inverted — "links to Settings → General" was a true description of a defect. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QvfFoqB2v2zPyXJXeyBGbP * feat(deploy): adding a domain is a settings field, not a shell command (#2380) The last two attempts at this both ended with an operator needing a root shell on the droplet, which a non-engineer following a deploy guide does not have. The constraint that forced it was real — Trinity is containerised and can neither rewrite /etc/caddy/Caddyfile nor reload Caddy — but it was the wrong thing to work around. Inverting the direction removes it entirely: Caddy asks Trinity whether a hostname is allowed, Trinity answers from what an admin saved, and no privilege moves into the container. The provisioned Caddyfile gains a catch-all site with on-demand TLS and an `ask` gate at /api/public/tls-allowed. Save a domain in Settings, point its A record here, and the first visit obtains the certificate. That is the whole step, which is what this card claimed from the beginning. The gate carries the entire security model, so it allows exactly one name: the host of the saved public_chat_url, parsed with urlparse and compared for equality. Substring matching would hand `evil-example.com` a certificate request from a server configured for `example.com`. It fails closed on an unset URL and on a failed settings read — `on_demand` without a working gate turns the instance into a certificate requester for anyone who points DNS at its address, until the ACME account is rate-limited and the operator's own renewals start failing. Executed rather than grepped in the tests: a static check cannot tell an exact match from a substring one, and that difference is the whole of it. set-domain.sh is deleted. It was written for this job two commits ago and is now a second way to do something that works from the browser; keeping it as a "fallback" would have been keeping a path nobody tests for a case that no longer exists. Caddyfile syntax verified against the 2.11.x docs rather than memory: `interval` and `burst` are removed from on_demand_tls, `ask` receives ?domain= and authorises on 2xx. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QvfFoqB2v2zPyXJXeyBGbP * fix(deploy): attach the account's SSH keys to the droplet it creates (#2380) Without this the droplet has no key on it, DigitalOcean emails a root password to the account owner, and the only way to a shell is the browser console. That is fine until something needs looking at, which on a first deploy is exactly when it happens. Attaches keys that already exist on the account — the operator's own, on the operator's account, going onto the operator's server. Nothing is created, uploaded or generated, and an account with no keys behaves exactly as before. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QvfFoqB2v2zPyXJXeyBGbP * fix(deploy): portable mktemp in the DigitalOcean installer (#2380) `mktemp -t trinity-user-data` takes a bare prefix on macOS/BSD, but GNU coreutils reads the same argument as a template and requires the trailing X's — so on Ubuntu (i.e. every Linux operator) the installer died with "mktemp: too few X's in template" immediately after collecting both secrets and confirming the create. Use a full path template instead: portable on both, and it keeps the umask-077 0600 mode the user-data file needs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LgRv6koYJKzor7ZHoRkGYS * test(deploy): the X-DO-MARKETPLACE guard reads start.sh, where the Caddyfile is written now #2680's guard pinned the header inside firstboot.sh's Caddyfile heredoc; #2380 moved that heredoc into `start.sh --provision --site-only`, so the merge left the test asserting a file that no longer writes a Caddyfile. Point it at start.sh and also pin that the header is keyed on the do-marketplace provenance, since the same function serves the doc install. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015owqMKD5QDjzZrUTF2Joht * test(deploy): restore the two firewall guards the port-list rewrite dropped (#2380) 6104b0e deleted test_2281_firstboot_port_exposure.py because the DOCKER-USER rule no longer enumerates ports, so the tests that policed the list had nothing left to check. Two of its five tests were never about the list, and they went with the file: - ufw and iptables-persistent are never both installed. ufw Breaks iptables-persistent, so installing it to persist the rules makes apt remove ufw, and the install dies later at `ufw --force reset`. - the firewall rules are re-applied on every boot. Without iptables-persistent, trinity-docker-firewall.service is the only thing that survives a reboot; without it every Docker-published port reopens after the first restart (#2281 review I1). Both are back in test_2380_provision_single_source.py, pointed at where the code lives now: start.sh --provision installs ufw and writes the unit as a heredoc, so the tests read that heredoc instead of a shipped unit file. Each was checked against a mutation of start.sh (iptables-persistent added, the enable line removed, After=docker.service removed) and fails on each. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PdRMazCDYVoxqLFw6uKm3a * feat(onboarding): browser admin claim, one first-run overlay, credentials without a terminal Abilityai/trinity-enterprise#580 — marketplace admin claim A DigitalOcean 1-Click first boot no longer generates an admin password. With no user-data password, ADMIN_PASSWORD stays blank and ADMIN_PASSWORD_SOURCE= browser tells start.sh that is deliberate, so the first browser visitor creates the admin at /setup (email, password, product-updates consent). The MOTD prints the URL to claim, never a password. An operator-supplied password (cloud-init user-data, including trinity-do-create.sh) still pre-provisions the admin and keeps the wizard closed. The prod/hosted compose files move from `:?` to `?`: an unset password still refuses to render; an explicitly blank one is the claim path. The backend already handled a blank password; only docstrings change. The accepted risk (the window before the first visit) is written down in DEPLOYMENT.md -> Security Recommendations. Abilityai/trinity-enterprise#581 — one first-run overlay Replaces the dashboard card ladder (HardeningGuide, FinishSetupCard, FrontDeskPanel, OnboardingWizard) with one blocking, teleported overlay: a rail over a conditional step registry (firstRunSteps.js, pure and unit-tested), steps secure / email / claude / keys / agent / sharing, welcome and done panels, the schematic illustrations, and TrinityMark.vue shared with /setup. Completion is derived from existing state, and only skips and "Finish later" persist. Unlike the spec, `keys` and `agent` never open the overlay on their own, so an established fleet does not see it on every new browser. ActivationChecklist stays inline. /setup logs the operator in after the claim. Re-runnable from Settings -> General and ?onboarding=1. Abilityai/trinity-enterprise#582 — credentials inside first-run The Claude step (the only required step) takes a subscription token or an API key, validates it with Anthropic before saving, and names the fix on bad input. The first credential is connected to the agents that had none, so the starter fleet can run immediately. Optional GitHub, Resend and Gemini keys persist through the encrypted secret-settings path (ent#435) with admin-only endpoints, and runtime reads resolve the saved setting before the env. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PdRMazCDYVoxqLFw6uKm3a * fix(onboarding): close the claim paths review found outside the marketplace Pre-landing review and a diff-scoped security audit of the previous commit. Claim path (Abilityai/trinity-enterprise#580): - docker-compose.prod.yml is back to `${ADMIN_PASSWORD:?}`. Neither start.sh nor the marketplace uses it, so relaxing it only let a source build that forgot its password boot with an open /setup. - docker-compose.hosted.yml passes ADMIN_PASSWORD_SOURCE (default `unset`) to the backend, and /api/setup/admin-password refuses a blank-password claim unless the source is `browser`. The #2381 existing-admin check still runs first; the dev compose (variable absent) keeps its wizard. - start.sh decides a blank password with env_value, so `ADMIN_PASSWORD=""`, `''` or a trailing space no longer count as set, and writes a generated password with set_env_key. First credential (Abilityai/trinity-enterprise#582): - Agents come from the DB rather than a Docker listing that swallows errors. Agents with a successful execution are skipped, so fleets that authenticate per agent keep their own key. Agents with a running execution are not restarted. The responses carry an int `connected_agents`, and seeding re-runs the idempotent connect so agents created during the save are not missed. - Gemini-runtime agents resolve the saved Gemini key before the env. - subscriptions router gains its `# mcp:` header. Overlay (Abilityai/trinity-enterprise#581): - Auto-login after /setup uses the claimed email, not a hardcoded 'admin'. - The Claude step reports the real connected count and says a re-paste replaces the saved credential. - setup_started is recorded only when the overlay opens on its own and the claude or agent step applies. - Exports orphaned by the absorbed components are deleted; docs that still described them now point at FirstRunOverlay / firstRunSteps.js. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PdRMazCDYVoxqLFw6uKm3a * chore(release): 0.9.5-rc3 Release candidate cut from feature/ent580-582-first-run so the marketplace browser-claim, the first-run overlay and the in-browser credential steps (Abilityai/trinity-enterprise#580, #581, #582) can be tested on a real 1-Click snapshot before their PR opens. rc1 and rc2 were cut from feature/2380-do-provision the same way; rc2 stays immutable. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PdRMazCDYVoxqLFw6uKm3a * fix(deploy): snap doctl cannot read /tmp, and an apostrophe kills first boot (#2380) (#2683) * fix(deploy): snap doctl cannot read /tmp, and an apostrophe kills first boot (#2380) Two fixes to the DigitalOcean installer, found QA'ing it across macOS and Linux. Neither is visible on the machine it was written on. **A snap-installed doctl has a private /tmp.** On most Linux distributions doctl comes from snap, and a snap runs in its own mount namespace — a file written to the real /tmp is not there when doctl opens it, so it fails on a file that demonstrably exists: Error: open /tmp/trinity-user-data.XXXXXX: no such file or directory Snap's `home` interface can read non-hidden paths under $HOME, so a snap doctl gets the file there instead; everyone else keeps TMPDIR. The name stays visible because that interface denies dotfiles too, `umask 077` still makes it 0600, and the EXIT trap still removes it. Reported by dolho, who hit it on Linux. The `mktemp -t` half of his finding is already on this branch (aaa3de5). A snap doctl with no usable $HOME now fails at that point with an explanation, rather than at the droplet-create call with a path error, after both prompts. **A single quote in either secret breaks the droplet's first boot.** Both are interpolated into single-quoted assignments in the user-data, so a `'` inside one closes the string early: export ADMIN_PASSWORD='Tr0ub4dor's!Horse' bash: unexpected EOF while looking for matching `'' Not a hypothetical input — the password rules require a special character and `'` is one, so that password passes this script's own check and the backend's. The failure is expensive out of proportion to the typo: the droplet is created and billing before first boot runs, the operator watches a 15-minute progress bar end in a timeout, and the cause is invisible without reading the install log. Both secrets now go through `_shquote` (the portable `'\''` idiom). Verified on both platforms rather than reasoned about — macOS bash 3.2 and ubuntu:24.04 bash 5.2 / GNU coreutils 9.4, driving the real prompt flow with a stubbed doctl and diffing the generated user-data: - `mktemp -t trinity-user-data` → macOS OK, Linux `too few X's in template` - the full template → both OK, mode 0600 - snap-detection truth table → identical on both - password round-trip → 7/7 both platforms, including apostrophes, backticks, backslashes, tabs and non-ASCII; the unfixed script fails the apostrophe cases with a syntax error `tests/unit/test_2380_installer_portability.py` pins all three. The round-trip guard is executed, not pattern-matched — it runs the script's own `_shquote` and lets a shell parse the result back, so it catches any breakage rather than the one spelling that was wrong. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011sj48trT3XmyaSus4GUtXB * test(deploy): the installer's default tag must track VERSION (#2380) `trinity-do-create.sh` hardcodes the release it installs: TRINITY_IMAGE_TAG="${TRINITY_IMAGE_TAG:-v0.9.5-rc2}" That default IS what operators get — the guide tells them to run the script straight off a tag with no environment set. So on the day `v0.9.5` is cut, a script fetched from the v0.9.5 tag still clones and pulls `v0.9.5-rc2` unless someone remembers this one line. Nothing catches it today. It is not a syntax error, the rc2 images still exist and still pull, and the install SUCCEEDS — it just installs the previous release candidate. The operator cannot tell, and neither can CI: the release checklist's "VERSION match" step compares the VERSION file to the tag, not this script to either. The guard ties them together. It passes now (VERSION `0.9.5-rc2`, default `v0.9.5-rc2`) and fails the moment VERSION is bumped for the cut — which is exactly when someone needs telling. Verified by mutation: setting VERSION to `0.9.5` produces AssertionError: trinity-do-create.sh installs v0.9.5-rc2 but VERSION says 0.9.5. A second case pins the `v` prefix. One string feeds both `git clone --branch` (needs the git ref) and `docker pull` (published under both spellings), so only the `v` form works for both — the #2471 failure, where `v0.9.5-rc1` shipped without its v-prefixed image alias and left no tag value able to build the marketplace snapshot. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011sj48trT3XmyaSus4GUtXB * fix(deploy): refuse before the prompts, quote the tag, and test the installer by running it (#2380) Addresses review I1-I3 on #2683. I1: the snap-doctl-without-$HOME refusal ran after both secret prompts, breaking the script's own "checks first, questions second" rule. The USER_DATA_DIR decision moves into the pre-flight block beside `doctl account get`; mktemp stays where it was. I2: TRINITY_IMAGE_TAG was the third single-quoted interpolation in the user-data heredoc and the only unquoted one. It now goes through _shquote, and the static guard asserts the rule (every '${...}' in the heredoc is a _Q value) instead of two spellings of it. I3: the guards grepped for the quoted spelling and never ran the script. New tests run the real installer against a stub doctl (package and snap paths, apostrophes and shell metacharacters in the password, token and tag), then `bash -n` the captured user-data and evaluate its real export lines and subscription call in context, and assert a snap doctl without $HOME is refused before any question. Running it found a fourth defect: under `set -u`, bash < 4.4 (macOS's /bin/bash is 3.2) treats an empty "${SSH_ARGS[@]}" as unbound, so an account with no SSH keys died at "Creating the droplet...", after both secrets were typed. Expanded as ${SSH_ARGS[@]+"${SSH_ARGS[@]}"}. Each fix was checked by reverting it: the tests fail on every revert. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PdRMazCDYVoxqLFw6uKm3a --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> * docs(deploy): describe the provisioning path, installer, firewall and TLS gate (#2380) /validate-pr on #2707 found the branch shipping new capability without the requirements and feature-flow updates CLAUDE.md requires. Written from the code at this commit, not from the PR body. Requirements (docs/memory/requirements/infrastructure.md): - Corrected: HOST-010 and the section 8.10 description, PROV-006 (flags now carry hardening_guide_eligible), PROV-009 (the second path has been a Cloudflare Tunnel since #2564, not a VPN), PROV-010 (a two-stage card gated on hardening_guide_eligible, with a domain field), PROV-011 (start.sh --provision now writes TRINITY_INSTALL_SOURCE). - Added: PROV-012 one provisioning implementation, three callers; PROV-013 the portless container firewall and the metadata-service block; PROV-014 the prompting installer and do-script provenance; PROV-015 the on-demand TLS ask gate. Feature flows: install-provenance (two-stage card, do-script, hardening_guide_eligible, the domain field and ask gate; fixes both stale claims in #2593), hosted-install (a Provision Layer section), telemetry-sharing (the IntersectionObserver gate from #2593), and their index rows. Stale sentences in agent-lifecycle.md, backend.md, api-endpoints.md and DEPLOYMENT.md corrected. Fixes #2593 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PdRMazCDYVoxqLFw6uKm3a * chore(deploy): drop references to set-domain.sh, which no longer exists (#2380) 0423e6c replaced scripts/deploy/set-domain.sh with a Settings field, but two comments still named it as env-file.sh's second caller, and the provisioning test kept an unused path constant pointing at it. start.sh is now the only script that sources env-file.sh; the comments say so. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PdRMazCDYVoxqLFw6uKm3a * fix(subscriptions): run the narrowed first-credential connect before the #2572 sweep The merge put dev's #2572 credential-less sweep ahead of ent#582's connect_agents_to_first_credential. The sweep has no notion of an agent that already authenticates some other way, so running first it would assign and restart agents ent#582 deliberately skips (any agent with a successful execution, and any agent mid-execution), and leave the first-run step reporting `connected_agents: 0` because nothing was left to connect. Swapped: the narrow pass runs first and reports its count, and the sweep then picks up whatever is genuinely credential-less. Also rewrites the first-run section of the setup guide, which #2746 synced while describing the card stack ent#581 retires ("at most one first-run card", "Not now snoozes for two weeks"). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PdRMazCDYVoxqLFw6uKm3a * fix(ci): linear from-address parser (CodeQL ReDoS) and stub get_gemini_api_key in telegram backfill test - platform_keys_service.from_address_domain: replace the single regex that CodeQL flagged as py/polynomial-redos with partition + single-class fullmatch; same accept/reject set, pinned by a parametrized test and a hostile-input timing check. - test_telegram_webhook_backfill: the settings_service stub lacked get_gemini_api_key, which routers/settings.py now imports (ent#582). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011y53gTcB3fTAHhJc3xxpkx --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Oleksii Dolhov <oleksii.dolhov@gmail.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
2 participants
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.
What
#2531 landed the card-stack fix and the address stage. This carries the part of #2380 that was still missing: the hardening card does not retire itself the moment a domain is set — it advances to a tunnel stage.
Two commits:
f018463— the two-stage card.hardeningStage()maps posture → stage,dismissKeyForStage()gives each stage its own localStorage key, andhttps-domaingains aPOSTURE_COPYentry (badgeDomain set, no primary button, Cloudflare named on the card face).FinishSetupCardgets an IntersectionObserver so the ent#437 warm telemetry ask is only marked shown when the card is really on screen, not while it sits hidden behind another card in the stack.28294b0— comment-only. ThePOSTURE_COPYdocblock still ended with "There is deliberately nohttps-domainentry — that posture never renders", directly above thehttps-domainentry the first commit added.Why the two stages don't share a dismissal
trinity_hardening_guide_dismissedandtrinity_hardening_guide_tunnel_dismissedare separate keys on purpose. Dismissing the address stage is "I know about domains"; it must not silently consume an answer to a question the operator has not been shown yet.Verification
npx vitest run tests/unit/hardeningGuide.spec.js tests/unit/onboardingStack.spec.js→ 2 files, 46 tests, all passTRINITY_INSTALL_SOURCE=do-marketplace).GET /api/settings/feature-flagsreportedinstall_source: "do-marketplace",marketplace_install: true,install_tls_posture: "https-ip"— the derivation the card depends on, confirmed against a real marketplace-shaped install rather than forced flags.Not
Closes #2380— that issue's other acceptance criteria are still unsettled, same call as #2531.🤖 Generated with Claude Code
https://claude.ai/code/session_01F2q1Xs3GtLLQemND1PgD99