BBramaDocs

Brama changelog: released 0.4.46 to 0.4.13

Released 0.4.46 to 0.4.13

Published releases 0.4.46, 0.4.14 and 0.4.13. Each entry describes the contract as it stood when that release was cut. Changes that carry no release coordinate are on current changes and unreleased subscription changes; earlier releases are on 0.2.77 to 0.2.42 and 0.2.5 to 0.2.2.

0.4.46: a gateway signs itself in, and borrowed grants are gone

Brama could take the OAuth grant a coding harness on the same machine already held: subscription held, subscription import and subscription sync, plus the console route POST /v1/admin/subscription-pool/grant. All four are removed, with the harness readers behind them. A provider issues one OAuth pair per sign-in and revokes it when a second holder refreshes, so every borrowed member cost the machine it came from its own session — the operator's own, among them, which then had to be signed in again by hand. It also made a gateway depend on a workstation staying in the fleet and on that workstation running a particular harness at all.

What replaces it is what already existed: a gateway signs itself in. subscription sign-in drives the provider's own login through Weles on the gateway's host, and subscription sign-in-manual (now sign-in --by hand) runs the same OAuth flow a harness runs — same client id, same scopes, same loopback callback, same token endpoint — and mints a pair that belongs to this gateway alone.

Members left over from borrowing are given back with the new subscription disown and its console route POST /v1/admin/subscription-pool/disown: the gateway retires the member and forgets its credential, and the machine that signed the account in keeps its session. A grant written before this release still carries the old borrowed marker and is still never rotated; a grant stored now has the marker stripped, because this gateway owns it.

No configuration, state schema or billing migration is required. A deployment that relied on a sweep importing grants has to sign its accounts in instead.

0.4.14: image-aware best selection

A best request with image content now filters the caller's active pool for advertised image input before applying a preferred route. Buffered and streaming requests use the same rule. No eligible model means a visible refusal, not a text-only substitution or a broader permission.

The real image qualification checks the visible heading through both HTTP response modes and preserves the out-of-scope model refusal. No credential, route, state schema or billing migration is required.

Published to the candidate channel from cbd297df3ed1efd961078b4aa45e7fca8f323b0f for Darwin arm64 and Linux amd64. The deployed gateway reported that exact revision. All three real image qualification cases passed: buffered reading, streamed reading and the unchanged HTTP 403 refusal of an unauthorized route. Weles 0.7.3 separately passed its real text, image and invalid-token cases against this gateway.

0.4.13: Codex imports and concurrent discovery

Released for Darwin arm64 and Linux amd64. The fleet gateway reported that exact revision, ready: true and degraded: false. A completion probe against each imported Codex account returned HTTP 200 and probe.ok: true.

Importing either existing OMP Codex account stored its grant but returned failed because the verification request selected gpt-5.3-codex-spark, which the provider refused for ChatGPT accounts. The same grants served codex/gpt-6-astra through Brama. The Codex probe now uses GPT-6-Astra, including the probe after a CLI or desktop import. It still proves a real completion and never refreshes the borrowed grant during import. An actual provider refusal remains a failed import, with the provider's sentence.

The real held-grant journey uses the existing isolated gateway and Skarbiec fixture, with refresh and usage sweeps disabled. Run cargo test --test subscriptions_harness_grants a_real_held_codex_grant_is_accepted_and_probed -- --nocapture with BRAMA_REAL_HARNESS_HOME and BRAMA_REAL_CODEX_ACCOUNT selecting the existing OMP account. The operator vault and harness store are not written. Receipts, source revision and the persisted pool response remain under target/real-import-evidence/; an unheld account must leave the stored grant unchanged.

The first release build found that a nested build path made all seven real pool journeys fail before opening their vault: GnuPG reported File name too long for its Unix socket. Only these socket-owning fixtures use the workshop's short-root exception, ~/.brama/test-runs/<unique>, with owner-only permissions and removal when the fixture closes. Ordinary test directories and retained evidence still belong under Cargo's target/.

GPT-6-Astra is now also advertised by the Codex catalogue, so a client allowed to use that route receives an available model instead of an empty list. Concurrent first catalogue requests share one discovery per subscription; the real held-grant journey proves six authenticated clients receive the model with one reported credential read, rather than six. The same coalescing covers the startup readiness sweep without weakening its checks or reusing inference credentials.