fix: preserve verified feature flag failures

[3mdistal]

Summary

Analytics lets workspace operators manage feature flags owned by other workspace apps.

Previously, an owning app could save a flag change while Analytics reported failure because its confirmation request timed out. The fleet panel could then replace that useful failure with a generic “workspace directory unavailable” message. Operators could not tell whether discovery, permission, the write, persistence, or confirmation had failed.

This PR makes Analytics report success only after it reads the saved flag state back from the owning app.

What changes

Analytics now handles a cross-app flag change in two steps:

1. Send the change to the owning app exactly once.
2. Read the flag back to confirm what was saved.

A temporary network failure—including an interrupted or timed-out response body—can retry the confirmation read once with fresh read authority. The write is never retried because it may already have succeeded.

Failures before any request is sent remain safe to retry. This includes delegated-token signing failures: they return a retryable setup error and issue zero target requests. Failures once the mutation request may have been issued stop the agent from repeating a write that may have persisted.

The shared action transport now preserves two fields that action authors explicitly mark safe:

• errorCode: a stable failure category
• details: small, sanitized context; Analytics sends only the failure phase

Agent-only toolResult data is never sent to the browser, and ordinary internal errors remain generic.

Safety and rollout

• Existing HTTP behavior and browser retry rules remain compatible.
• The new response fields are optional, so old and new versions can coexist during rollout.
• Invalid JSON and non-success HTTP statuses retain their previous classification.
• No database migration, credential change, Content data mutation, or Slack canary is included.
• The tracked plan uses only a designated test operator; live identity and rollout audit details remain in the access-controlled operational record.

The repaired path remains behind analytics.verified-fleet-flag-mutations. The rollout must remain Off before merge, with stored-rule and evaluated-value read-back evidence. After deployment, acceptance will use Content''s content.a2a-receiver-ownership flag as a representative case: enable for the designated test operator → read back “Enabled for you” → turn it off → read back “Off.”

Verification

On exact head bcf6fa91ca4f0a602808fee1b35869028cbf60d1 after merging current main:

• 39 focused Analytics tests pass, covering one write, one optional confirmation retry, response-body interruption, cross-realm JSON parse failures, fresh delegated read authority, distinguishable failure phases, and retryable signing failure with zero requests.
• 153 focused Core tests pass, covering safe server serialization, browser reconstruction, unchanged agent behavior, and exclusion of agent-only data.
• Analytics and Core typechecks pass.
• The Core build passes, including distribution import checks.
• All 64 repository guards pass.
• GitHub CI and exact-head independent review are pending.

Local verification ran on Node 22.21.1 and emitted the repository engine warning requiring Node 22.22.0 or newer; GitHub CI is the supported-runtime gate.

Review focus

• Are browser-visible error fields limited to explicitly safe information?
• Can any transport, response-body, or signing failure issue the write more than once?
• Are failures before the request retryable while mutation-uncertain and post-write failures stop?
• Do malformed JSON, non-success statuses, and mixed framework/app versions preserve existing behavior?

[github-actions]

Here's a visual recap of what changed:

Open the full interactive recap

[builder-io-integration]

Builder reviewed your changes and found 2 potential issues 🟡

Review Details

Code Review Summary

This incremental review covers the latest Analytics response-body retry repair, Core action-error transport, and the expanded tracked plan/documentation changes. The previously reported response-body retry issue is fixed: successful-response body-read failures now reach the timeout/network classifier and verification retries once, while mutation-response failures remain write-uncertain and are not retried. Core continues to preserve explicitly safe metadata without exposing toolResult.

Key Findings

🟡 MEDIUM — Pre-write delegated-token failures are still treated as non-retryable

signA2AToken runs before the target mutation request, but its failure is converted to TargetCallFailure and then to WorkspaceFeatureFlagFailure, which is now an AgentActionStopError. A transient signing outage can therefore stop the agent from retrying a write that is known not to have been sent.

🟡 MEDIUM — Tracked plan exposes internal operator identity and rollout state

The newly tracked plan includes a real employee email and current/unknown rollout state. Replace those details with a generic designated test operator and acceptance requirement; keep live operational audit data in an access-controlled record.

Risk level: standard. The response-body retry implementation and its regression tests are otherwise well covered, and the docs table edits are formatting-only.

🧪 Browser testing: Blocked — the dev server was healthy, but browser-test executors lacked Chrome automation tools; the fleet mutation path also has no configured org-directory apps in this environment.