Conversation
…oken trinity-do-create.sh prompted for a Claude subscription token and had first boot register it and assign it to the seeded agents. Connecting Claude is now the onboarding overlay's blocking step (trinity-enterprise#582), which accepts a subscription token or an API key, checks it with Anthropic before saving, and hands it to the agents that have none. The installer's copy was an unchecked duplicate that also forced every operator to run `claude setup-token` before a server existed. The installer now asks three questions (password, region, name). First boot no longer logs in, calls /api/subscriptions or needs jq, and the user-data carries only the admin password. The finish message says Claude is connected after sign-in. PROV-014, the hosted-install flow and the three user docs that described the token prompt are updated to match. New test: the installer reaches the end on three answers plus the confirmation, prints no setup-token prompt, and its user-data registers nothing (red against the previous script). Refs #2380 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Local dev was 156 commits behind origin/dev (three intervening weekly runs never reached origin since dev is protected); re-ran from a fresh branch off origin/dev tip for accurate churn/complexity numbers.
Resolve the two docs conflicts by keeping dev's new DigitalOcean guide links and FAQ question, without the Claude token step the installer no longer has. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The installer stopped prompting for a subscription token, but the DigitalOcean guide still walked operators through claude setup-token, listed the token among the installer's questions, and named a log line the first-boot script no longer writes as the install's success signal. The guide now drops that step and its troubleshooting rows, and sends operators to the Connect Claude step on first sign-in. The install's success signal is the last log line, '=== Trinity is ready at ... ===', which the first-boot script writes only after start.sh succeeds. The docs index card and the single-server cross-link lose the token too. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…indings from Trinity's own starters (#2899) `T-004`/`T-005` failed an ABSENT `resources` block, so every agent created from `scout`/`sage`/`scribe` — the three templates a fresh install seeds as the `acme-*` fleet — opened its Overview tab with a red "2 must-fix" banner. Absence is the supported shape: the agent inherits the admin's fleet-wide default (RES-001), and a template-level block would override both that default and the values a manifest or API caller asked for (`crud._resolve_local_template`). #1908 parked this as a product decision behind a two-check waiver; the decision is INHERIT. * T-004/T-005 pass on an absent/null/empty declaration, naming the default in the message. A declared value is validated by the create path's own `normalize_cpu`/`normalize_memory`, so the check accepts exactly what creation accepts (`4G`, unquoted `cpu: 2`) and rejects exactly what it rejects — T-005's old regex passed `512m`, which `normalize_memory` 400s. Values are `_clip`ped before they reach a message: `template.yaml` is agent-writable. * A non-mapping `resources:` fails T-004 and skips T-005 — one malformed block, one finding. The create path raises AttributeError on it, unguarded. * `_KNOWN_FAILING_CHECKS` is now EMPTY, so the #1908 guard holds every visible bundled template to every HARD static check with nothing exempt. * The generic `PUT /api/settings/{key}` refuses `agent_default_cpu`/ `agent_default_memory`. The dedicated route validates them; unvalidated, a junk default 400s every creation that relies on it. * `X-004` exempts the platform-injected `trinity` server in the template.yaml-only direction; a template shipping its own `trinity` block is still reported. * The panel headline counts must-fix only: "N must-fix compatibility issues" (danger), "No must-fix issues · N recommendations" (neutral — the API still calls that state `issues`, and soft covers S-006/S-008), "Compatible" only at zero. Skipped AI checks collapse to one line per reason; with no Anthropic key that was 30 rows of 89 burying the real findings. Dead `infoCount`/`failing` computeds removed. Docs: validation spec (incl. X-004's type column, which said AI for a STATIC check), agent guide's "resources (required)", requirements §4.1.1, feature flow. Out of scope, filed: #2903 (canary `512m`), #2904 (MCP names declared in three places), Abilityai/cornelius#9 (that template's own findings). Fixes #2899 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
… its git remotes" alert (#2930) The ent#615 sweep decided "could I see this tree?" with one flag, `root_readable`, set by `[ -d .git ] && [ -r ] && [ -x ]`. That fails on EXISTENCE as readily as on permissions, and an agent created from a `local:` template has no repository at all — so every stock starter (`acme-scout`/`sage`/`scribe`) filed an operator alert on every fresh install, and the alert told a first-time operator that the cause was `agent_full_capabilities=off` withholding DAC_OVERRIDE. On the instance this was found on, that setting was unset (defaults to true) and the container held DAC_OVERRIDE: the named cause was not the cause. The sweep now reports two more facts, and the caller splits them: * `root_traversable` — can this exec enter ROOT at all? The capability question, asked about ROOT rather than about the repo, because a missing DAC_OVERRIDE fails the `-d .git` test too and makes "absent" and "unreachable" identical. * `git_present` — is there a repository here? "Nothing to sweep" is not a finding. Traversable + absent → no alarm, one debug line. Everything else alarms exactly as before, so the ent#615 property is untouched: an all-zero report from a tree the sweep could not see is still never an all-clear. A report carrying neither flag parses both as 0 and routes to the alarm, which is the pre-#2930 behaviour. Tests: the real script against a repo-less directory, a real repo, and an unreadable one (positive controls on both flags), plus the four consumer shapes — absent, unreachable ROOT, present-but-unreadable, and an old flagless report. Fixes #2930 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…cean button The Trinity 1-Click is live on the DigitalOcean Marketplace. The README's "Don't want to run it on your laptop?" callout now points to it first, with the sizing and first-login steps from the listing, and keeps the guided installer as the scripted alternative. The button and link carry the Ability AI referral code from the Vendor Portal. Refs #2281 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ted (#1989) (#2847) Operator decision 2026-09-16: the edge adapter wins, not the scope cut. The durable queue carries all traffic including human-interactive chat, and the synchronous push dispatch path is deleted once the two supporting pieces land (#2842 queue priority, #2843 one turn per conversation). Three documents asserted the opposite and would have relitigated this: - TARGET_ARCHITECTURE.md Open Question 7 said "under consideration, not decided" and named the scope cut as the candidate answer. - PULL_MIGRATION_STATUS.md said "everything is pull" is false *by design*, and listed interactive chat as deliberately excluded. - PULL_MIGRATION_TESTING.md described the exclusion as a settled scope cut. All three now state the decision and its reasoning, so the question cannot be reopened from the documents themselves. Two corrections ride along, both measured on eu2 during the #1766 soak: - The starvation argument that favoured the scope cut was overstated. Push does not avoid the wait either — chat already queues in a bounded in-memory FIFO at capacity, and the worst case there is already ~32 minutes. What push avoids is waiting behind queued batch work, which priority ordering restores. Parity is the bar, not instant. - The session-serialization requirement is mutual exclusion per conversation, NOT worker affinity. All workers share one container filesystem, so pinning buys nothing and would make a person wait on a busy worker while others idle. Affinity only matters at replica_count>1. Also adds `retry` to the reach table (#2845) — it is in neither trigger set and is 4.7% of eu2's traffic, which Phase 5 cannot delete around. Based on docs/pull-migration-consolidate rather than dev, because that branch already rewrites all three files. Claude-Session: https://claude.ai/code/session_019Tm7UEkd4G9KQZD5oeLRSa Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Open Question 7 is decided for the queue: the pull pilot's exclusion of interactive turns is a migration state until interactive priority (#2842) and per-conversation exclusion (#2843) land, not the scope-cut design boundary the code comments and test docstrings still described. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This was referenced Sep 21, 2026
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.
Integration surface for #2932, #2923, #2931, #2933, #2867, #2929.
Never merged; members merge individually once green. Assembled off
dev@ 0c470c7, all six members validated READY this run (zero ejections).No closing keywords here by design — the members carry those.