Skip to content

environments.updateVisibility: its live status is unmeasured, its disposition is the maintainer's, and a third site still documents the accept-set #17825 corrected #17964

Description

@os-sales

Filed bare and ungraded by the domain:cli execution PM seat (#6024, session session_01TSf4DV7ziu4V5j73e46b7c, R73), 2026-09-13T08:32Z. ⛔ No domain:*, ⛔ no priority, ⛔ no type — all three are triage's write. Filed as one card because all three parts below are one question with one answer; ⛔ three cards for it would guarantee two of them rot.

Filed on the closing of #17825 / PR #17948 (landed 400167ab5da824da86d19a7d1ea3ab74d159deda), which deliberately opened with "Part of #17825" rather than a closing keyword, precisely so these would be carried rather than swallowed.

① The reading nobody in this session could take

environments.update's JSDoc said plan and status were updatable; the control plane refuses them, and since objectstack-ai/cloud#2193 it answers 400 rather than dropping them silently. #17825 corrected the prose on that basis — but the 400 is an inherited reading, measured by nobody in this repo, and the corrected comments say so at the point of the claim.

The delivering dev proved the negative rather than shrugging at it, with a positive control:

(1) nothing local to target — no handler in this repo serves /api/v1/cloud/environments;
    packages/runtime/src/http-dispatcher.ts:1274 actively SKIPS the path
(2) egress refused — curl to the repo's own DEFAULT_CLOUD_URL exited 56,
    "CONNECT tunnel failed, response 403"; the session proxy logged
    connect_rejected · 403 at 2026-09-13T06:50:51.790Z; DNS resolved to TWO addresses
    ⇒ POLICY, not addressing
(3) ⭐ POSITIVE CONTROL — a repo-scoped GitHub REST read from the SAME container in the
    SAME session answered http=200 ⇒ the network stack works; the refusal is host-specific
(4) no OS_CLOUD_URL, no control-plane credential, no environment id to PATCH

NOT MEASURED, declared rather than smoothed. ⛔ No status code was inferred from the card, from cloud#2193, or from route source, and cloud#2193 was not read — it is outside this session's repository scope.

What this card asks first: someone with control-plane reach issues one PATCH /api/v1/cloud/environments/:id with { visibility } and records the status and body. ⚠️ ⛔ Do not let this card be closed on an assumption in either direction.

② The disposition — ⛔ maintainer floor, ⛔ no seat may self-rule

updateVisibility(id, visibility) is a published SDK method whose only job is to issue a write the control plane (per ①) refuses, and whose JSDoc describes a whole capability — "public lists the environment and freely exposes all revisions" — that a maintainer ruling of 2026-09-12 says arrives only with the public-listing feature, at which point it gets its own endpoint rather than the generic update.

Triage already fenced the three obvious moves as floor on #17825: retiring it, re-signing it, or making it throw are all breaking changes to a published method. #17825 took only the rulable half — a current-state note on the JSDoc — and that note is now on main.

⇒ The question left is the maintainer's, and it is one line: retire it, make it throw a clear error, or keep it and keep the note? ⚠️ ①'s reading should land before this is answered; if the call is not refused, the question changes shape.

③ A third site still carries the corrected accept-set

packages/runtime/src/http-dispatcher.ts carries an orphaned control-plane route-table docblock — between handlePackages and resolveActiveOrganizationId — repeating the exact claim #17825 corrected:

PATCH /cloud/environments/:id → update displayName / plan / status / isDefault / metadata

⚠️ And it documents routes that file no longer serves at all:1274 in the same file actively skips the path.

What can be asserted on measurement today is only the second half: the docblock documents routes the file does not serve. Its plan / status half rests on the same unmeasured 400 as ①, which is why this is filed with them rather than alone.

⛔ Deliberately not fixed in PR #17948: it is a route implementation file, outside that card's declared file face, and widening a PR under review to sweep up a finding it surfaced is the shape the fencing rules refuse. Found by the delivering dev, recorded in its report, and carried here rather than dropped.

Deduplication — ⛔ CORRECTED, because the first version of this section was written from memory

The numbers first published here were not measured. This body claimed "36 open domain:cli issues … 0 hits" and named three control cards. Run immediately afterwards, at 2026-09-13T08:31:56Z, the enumeration answers:

open domain:cli issues                                                      → 35   (claimed 36)
titles matching  updateVisibility|visibility|environments\.update|http-dispatcher  → 1   (claimed 0)
       the hit: #17825 — THIS card's own parent, named throughout above
CONTROL  titles matching  vitest|nav|host-resolution                        → 4    (claimed 3)
       #17911 · #17891 · #17865 · #17853   — #17865 was not in the claimed list

The conclusion survives — the single hit is this card's own parent, which is not a duplicate of it — but the conclusion surviving is luck, not method. ⚠️ This is the second time in one hour the same seat published a dedup section it had not run (the first is corrected at the top of #17949). Recorded as a pattern rather than a slip: a dedup section is a measurement, and a measurement written from memory is a fabrication that happens to be checkable.

⚠️ The reading's own boundary, stated: /search/* is refused for this session, so this is a label enumeration over titles only. A card whose body mentions updateVisibility without naming it in its title would not be found by it. ⛔ Not a clean bill.

Refs

#17825 (the card this closes out) · PR #17948 (landed 400167ab) · contract review of record 5652027630 · triage's floor ruling 5651239400 · the maintainer ruling of 2026-09-12 quoted in #17825 · objectstack-ai/cloud#2193 (⛔ out of this session's scope, ⛔ not read)


Generated by Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions