The pool-fleet migration is complete: the control-plane harness plus the
prod workers (deployed 2026-06-19, HARNESS_ROLE=worker, pool count 2) now
cover every probe dimension the interim `harness-legacy` fleet-migration
bridge was holding live, so `harness-legacy` is dead config.
This is the code-side cleanup only:
- Remove the `harness-legacy` entry from the railway-envs SSOT and the
now-dead `key === "harness-legacy"` special-case in computePromoteClosure.
- Regenerate railway-envs.generated.json (41 -> 40 services).
- Drop harness-legacy from the golden snapshot, the gateIgnore expectation
sets, the promote-notify fixtures, and the redeploy-env doc comments;
update the service-count assertions (41 -> 40).
- Fix the stale "STAGING-ONLY" harness-workers comment: prod workers are
live on Railway, though this SSOT entry still models the staging
instance only (no prod env backfilled here yet).
The live Railway `harness-legacy` service is torn down separately as a
follow-up infra step.
Promote-notify Slack message: name the promoted AND failed services (one
Failed: header + bullets), legible "(N): <names>" count, real wall-clock
elapsed (integer-coerced), and drop the constant verify-prod legend line.
Durable healthcheckPath: track it per-service/env in the SSOT (railway-envs),
re-assert it on the promote pin path (omit-when-absent, never null), and route
deploy-to-railway provisioning through isTrackedService/resolveProvisionHealthcheck
so a tracked-null service omits the healthcheck while an untracked one keeps the
/api/health default — fixing the silent prod-healthcheck drift that refused aimock.
Tests: ruby pin-reassert spec + deploy-to-railway healthcheck spec + emit/golden/accessor.
## Summary
- Add a dedicated `shell-docs-primary-cta` style for the hero quickstart
link so it keeps the primary CTA color inside reference content.
- Cover the new class usage in the hero and framework overview tests.
## Testing
- Updated unit tests to verify the quickstart CTA class and the matching
global CSS override.
- Updated unit tests to verify the framework overview markup includes
the primary CTA class.
The ag2 declarative-gen-ui route pointed its HttpAgent at the root
catch-all mount (agents/agent.py) instead of the dedicated
/declarative-gen-ui mount (a2ui_dynamic.py), and generate_a2ui declared
a required context arg that the model emits as {}. pydantic rejected
every call with "context Field required" and AG2 retried without bound —
a 630-iteration hot loop per pill that flooded logs and starved the
frontend.
Fix: route to the dedicated mount with injectA2UITool:false (the
dedicated agent owns generate_a2ui and emits a2ui_operations itself);
make generate_a2ui a no-arg tool matching the D6 fixtures and the
langgraph-python gold standard, with a constant inner system prompt
(per-pill distinctness comes from the captured user message). Regenerated
the gen-ui-declarative fixture and ported the LP definitions/renderers
catalog (all 7 driver testids) for parity. Eliminates the validation
loop: runsFinished=1, zero validation errors.
The LlamaIndex AG-UI adapter never forwarded RunAgentInput.tools, so
page-injected frontend tools (useFrontendTool / useComponent /
useHumanInTheLoop) were invisible to the LLM — runs the model couldn't
satisfy ended in RUN_ERROR (no RUN_FINISHED), which the harness reported
as sse-missing.
New RequestAwareAGUIChatWorkflow re-implements the chat step as the
upstream body plus three additions: forward RunAgentInput.tools as no-op
FunctionTool stubs carrying the verbatim injected JSON schema; re-role
tool-result messages to role="tool" on the LLM-bound message copy only
(so the hasToolResult second-leg fixture matches) without mutating
stored/snapshot history; and for frontend tool calls dispatch the
ToolCallEvent but skip the duplicate TOOL_CALL_CHUNK (the bare snapshot
already delivers the call). beautiful-chat 0/5 -> 5/5; mcp-apps fixed.
## Summary
The 12 `starter-*` services were deliberately `sleepApplication=true`
(sleepable), `probe.staging=false` (held out of the verify-deploy
staging matrix). That class-difference is the root of three recurring
symptoms: the `service=all` promote false-fails them (SLEEPING / no
running-digest), the deployed-starter smoke test 404s a cold container,
and they're excluded from staging validation. Decision: **bring them
into the normal managed-fleet flow — always-on + staging-probed.**
- **`verify-deploy.drivers.starter.ts` (new)** — real `probeStarter`
baseline driver (deployment SUCCESS + HTTP 200 on `/`, mirroring
`probeShell`); replaces the fail-loud `case "starter"` stub.
- **`railway-envs.ts`** — `staging.probe: false→true` for all 12
starters (prod already true); stale "staging probe OFF" comments
rewritten. `railway-envs.generated.json` regenerated (in-sync via
`--check`).
- **`provision-starter-fleet.ts`** — `sleepApplication: true→false` +
comments/logs; test updated.
## ⚠️ Deploy ordering (must hold)
This PR flips `probe.staging=true`, which routes starters into the
staging matrix. It must **not** merge until the live services are
flipped always-on, or a `service=all` promote would probe still-sleeping
starters and fail. Sequence: **(1) live-flip 24 instances
`sleepApplication=false` + redeploy (12 staging + 12 prod), (2) verify
awake + serving `/`, (3) merge this PR.**
## Verification
- Red-green: starter driver (stub→probe `/`), SSOT golden (probe.staging
true), provisioner (sleep false) — all RED→GREEN.
- `showcase/scripts`: 2092 tests pass; `tsc --noEmit` clean on changed
files.
## Test plan
- [x] vitest suites green (2092)
- [ ] CR
- [ ] live 24-instance always-on flip + redeploy (staging + prod)
- [ ] CI green
- [ ] post-flip: `service=all` dry-run shows starters pass staging probe
🤖 Generated with [Claude Code](https://claude.com/claude-code)
The built-in-agent shared-state-read-write demo wrote agent state via
direct property assignment (`agent.state = {...}`), which sets the value
but does not fire `onStateChanged` — so subscribed components never
re-render off a UI write. Every other framework demo (including the
langgraph-python gold standard) already uses `agent.setState(...)`, which
both updates state and notifies subscribers. This was the lone divergence.
Switch the seed and the title write to `agent.setState(...)` so the demo
matches the documented pattern (docs/shared-state.mdx says writes go
through `setState`) and the rest of the showcase.
Verified: built-in-agent D5 e2e-deep suite green after rebuild.
Flip the 12 starter-* services to behave like every other managed
showcase service: always-on and staging-probed.
- railway-envs SSOT: staging probe false -> true for all 12 starters
(prod was already on); refresh the stale "staging probe OFF" /
fail-loud-placeholder doc-comments to reflect baseline-driver verification.
- provision-starter-fleet: sleepApplication true -> false so the
provisioner creates always-on (not sleepable) Railway instances; update
the "the whole point — sleepable" header/inline comments + log lines.
- Regenerate railway-envs.generated.json (emit-railway-envs-json.ts) and
the golden fixture; update the SSOT probe + provisioner sleep assertions.
Replace the fail-loud `case "starter"` stub in verify-deploy's dispatch
switch with a real baseline liveness driver. The starter-template fleet
EXPOSEs only its Next.js frontend (serving `/` and `/api/copilotkit`,
NO `/api/health`), so the driver healthchecks `/` via probeBaseline,
exactly like the Next.js shells: deployment-SUCCESS + HTTP 200 on `/`.
promote-fleet.sh now emits a base64 results JSON (schema_version=1) with
both succeeded[] and failed[] alongside the existing succeeded_csv /
staging_drift outputs. showcase_promote.yml's notify job replaces the old
inline two-state (success/failure) notifier — which dumped the full
requested CSV and mislabeled any partial promote as a blanket Failed — with
a single dispatch of the previously-orphaned showcase_promote_notify.yml
renderer (success / partial / total). The dispatch enriches promote-fleet's
results blob with run context (6-hex run_id, trigger=workflow, operator,
pre_staging) and authenticates via the devops-bot App token (actions:write),
mirroring canary.yml — the default GITHUB_TOKEN cannot start new workflow runs.
promote-fleet has no failure taxonomy, so each failed entry uses the default
category "promote-failed".
## Summary
Adds the **pluggable persistence layer** for the bot packages (spec
slices **A + C**): a single `StateStore` interface with
`memory`/`redis`/`postgres` backends, the existing in-memory action
store folded onto it (durable actions across restarts for free),
turn-locking + inbound-event dedup + thread subscriptions/state, and
**cross-platform per-user transcripts** (`bot.transcripts`). These are
the open-source primitives a future managed `IntelligenceStore` slots
into -- that backend is intentionally **out of scope** here.
Surface parity (reactions / ephemeral / modals -- slice **D**) and
concurrency strategies + serverless webhook ingress (slice **B**) are
**deferred** to follow-on PRs.
## What's included
**A -- `StateStore` foundation**
- `StateStore` interface: grouped `kv` / `list` / `lock` / `dedup` /
`queue` primitives (`packages/bot`).
- Backends, each its own package, all passing a shared conformance
suite: `MemoryStore` (in `@copilotkit/bot`),
**`@copilotkit/bot-store-redis`** (Lua-scripted lock/queue atomicity),
**`@copilotkit/bot-store-postgres`** (row-based TTL lock, `SKIP LOCKED`
dequeue).
- `ActionStore`/`InMemoryActionStore` reimplemented over `state.kv`
(`kvActionStore`) and marked `@deprecated`; `ConversationStore` gains a
`StateStore`-backed helper.
- **All persistence config lives under one `store` object** --
`createBot({ store: { adapter, state, identity, transcripts,
onLockConflict, lockTtl, dedupTtl } })` (default backend `MemoryStore`;
legacy root `actionStore` still honored). `store.state` is an optional
**Standard Schema** that makes `thread.state()` / `thread.setState()`
**typesafe** (inferred type + runtime validation on write).
```ts
const bot = createBot({
adapters: [slack(/*...*/)],
agent,
store: {
adapter: createRedisStore({ url: process.env.REDIS_URL }),
state: z.object({ step: z.enum(["ask_name", "done"]) }), // -> thread.state()/setState() typed
identity: ({ author }) => author.email ?? null,
transcripts: { retention: "30d", maxPerUser: 200 },
onLockConflict: "drop",
lockTtl: 60_000,
dedupTtl: 300_000,
},
});
```
- **Durable actions** fall out of the fold -- the minted `ck:` action id
is the `kv` key, so a click after a restart re-renders from the
persisted snapshot when a durable backend is configured.
- Consumers wired: action snapshots, thread subscriptions + per-thread
state (`kv`), per-conversation **turn lock** with `onLockConflict:
"drop" | "force"` (`lock`), **inbound-event idempotency** by platform
event id (`dedup`). `queue` ships fully implemented + conformance-tested
but unconsumed (its consumer is the deferred concurrency work).
**C -- Cross-platform transcripts**
- `bot.transcripts` (`append` / `list` / `delete`) over `state.list`,
keyed by a developer-chosen `identity` resolver (paired-or-throw with
`transcripts` config), `retention` + `maxPerUser`, GDPR delete. Each
entry records its `platform` + `ts`, so an agent can reference "you said
on WhatsApp X" across surfaces.
- **`thread.runAgent({ transcript: true })`** auto-bridges the
transcript into a run: injects prior cross-platform history
(platform-labeled) as agent context, appends the current user turn, and
captures the streamed assistant reply back into the transcript. Manual
`append`/`list` remain available for full control.
**Surface plumbing**
- `eventId?` on the three ingress types + Slack adapter wiring
(Events-envelope `event_id` -> `client_msg_id` -> `channel:ts`;
interaction/command ids) so the dedup guard engages on Slack.
## Testing
- Shared `runStateStoreConformance` suite (kv/list/lock/dedup/queue
contract incl. stale-token fencing, TTL expiry, queue eviction,
**mixed-ttl whole-list expiry**, **kv/lock keyspace isolation**) runs
against all three backends. **Redis and Postgres validated live (16/16
each)** against local containers; MemoryStore runs in CI.
- Focused unit tests for `kvActionStore`, `Transcripts`,
`createStateBackedConversationStore`, thread subscribe/state, the
`createBot` orchestration (lock-release-on-throw, `onLockConflict`
callback, identity throws/null, dedup+lock ordering, dedup fail-open),
and Slack `eventId` derivation.
## Code review
Reviewed by a multi-agent pass (correctness / silent-failures / tests /
types / comments / backends / packaging) and **fixed to zero**. Notable
fixes: a Postgres data-retention bug (non-TTL append leaving immortal
rows -- now whole-list expiry), a Redis kv/lock keyspace collision
(added `lock:` infix), fail-open-but-now-fail-**loud** logging on
identity/dedup failures, eager `retention` validation, and required
`ThreadDeps.state`.
## Follow-ups (not in this PR)
- **CI: provision Redis + Postgres services and set `TEST_REDIS_URL` /
`TEST_POSTGRES_URL`** so the backend conformance suites run in CI
(currently `describe.skip` without them -- validated locally here).
- Discord/Telegram `eventId` wiring (Slack done; `// TODO` left in
place).
- Slice **B** (concurrency strategies, serverless webhook ingress) and
slice **D** (reactions/ephemeral/modals).
- `IntelligenceStore` managed backend (the product layer).
## Notes
- Dedup records on **receipt** (drops duplicate deliveries within the
TTL window); a handler that throws still leaves its event marked seen
(no retry-recovery) -- intentional, documented inline.
- **Squash-merge friendly** -- intra-branch commits are individual green
slices from a gated wave execution (one commit, `d73732cf14`, absorbed a
few wave-3 files via the auto-staging pre-commit hook).
- Pre-existing failures unrelated to this branch: strict `check-types`
in `src/threads.ts` / `src/utils/phoenix-observable.ts` /
`@copilotkit/core`; eslint warnings on Slack `chat.postMessage` and the
`pg` named export.
Generated with [Claude Code](https://claude.com/claude-code)
Adds a durable persistence layer for @copilotkit/bot, replacing the
in-memory-only ActionStore with a pluggable StateStore.
- StateStore interface (kv/list/lock/dedup/queue) with a shared
conformance suite; MemoryStore default plus @copilotkit/bot-store-redis
and @copilotkit/bot-store-postgres backends.
- createBot({ store }): typed per-thread state via Standard Schema,
action snapshots persisted through the store, per-conversation turn
lock (onLockConflict drop|force), and inbound-event dedup keyed on a
stable eventId. ActionStore is kept as a deprecated alias.
- Cross-platform transcripts (bot.transcripts + identity resolver) with
age-bounded retention (prune on append + filter on read), and
runAgent({ transcript: true }) to auto-inject history and capture the
reply.
- createBot({ components }) re-registers components so durable actions
re-fire after a restart; restart-durability demo in examples/slack.
- Dedup is marked seen only after the turn lock is acquired, so a turn
dropped on lock-conflict does not burn its eventId (no lost retries).
- Release lockstep: bot-store-redis/postgres version with bot + bot-ui.
Drop the env-var key-set-diff WARN in check_p6_parity (environment-specific keys
like NODE_ENV/CVDIAG_*/SHOWCASE_BACKEND_HOST_PATTERN/BROWSER_POOL_* no longer
block a promote) and introduce a non-blocking ADVISORY disposition demoting
region/replicas/restartPolicy, missing-expected-prod-domains, and concurrency-key
divergence from WARN. check_critical_env_key_parity stays staging-gated
((CRITICAL_ENV_KEYS & staging_keys) - prod_keys): it flags a critical key staging
carries but prod is missing, and tolerates infra/operator tokens absent from both.
Adds red-green spec coverage in test_promote_p6.rb. No source symbols renamed/removed.
## Summary
An **on-demand** tool to answer "is prod caught up with staging right
now?". The showcase deploy model is **staging = mutable `:latest`**
(continuously rebuilt) and **prod = immutable `@sha256:`** (advances
only on an explicit promote), so a prod column can sit **behind** a
green staging.
**There is no scheduled drift alert — by design.** Prod lagging staging
is **often intentional**: changes are batched and promoted deliberately,
so a recurring "N columns stale" alert would be pure noise. This tool is
therefore manual-only: a maintainer runs it when they want to check, and
it tells them the current state.
- **`bin/railway reconcile-prod`** — for every prod-eligible
(`probe.prod == true`) service, compares the **prod serving digest**
(the `@sha256:` from
`SnapshotCommand.build_snapshot(PRODUCTION_ENV_ID)`) against the
**staging running digest** (reuses
`PromoteCommand#staging_running_digest`, the same source the promote pin
uses). Classifies each:
- `green` — prod == staging (in sync)
- `stale` — prod != staging **and** staging is resolvable (prod is
behind a green staging)
- `gray` — staging running digest not resolvable, or the service has no
prod snapshot entry yet — informational, **not** stale
- Prints a readable per-service table + summary; **exits nonzero iff any
service is stale**; `--json` for machine output. **Read-only — no
promotes/mutations.**
- **`showcase/scripts/reconcile-prod-gate.sh`** — wrapper mirroring
`lint-prod-gate.sh`: surfaces the table into `$GITHUB_STEP_SUMMARY`,
optionally captures `--json` to `RECONCILE_JSON`, and propagates the
exit-code verdict (never swallows a non-zero).
- **`.github/workflows/showcase_reconcile.yml`** — **`workflow_dispatch`
only** (no cron). Regenerates the SSOT JSON (`EMIT_SKIP_OXFMT=1`, same
as the promote workflow's resolve/promote jobs), runs the gate with the
Railway/GHCR auth env, renders the reconcile table to the **GH step
summary**, and uploads the `--json` as a `reconcile-json` artifact. **No
Slack.** The run exits nonzero on a stale column so a manual run visibly
flags drift. `timeout-minutes: 10`.
- **Tests** — Ruby minitest (`test_reconcile_prod.rb`: classification +
exit-code + `--json` shape + dispatcher registration) and a bats gate
test (`reconcile-prod-gate.bats`). Wired the gate script into the
`showcase_validate.yml` shellcheck list.
### What changed from the original scheduled-alert design
The first cut of this PR shipped a daily cron + auto-post to #oss-alerts
on any stale column. Per owner feedback, that was reshaped to on-demand
only: the `schedule:` trigger and the Slack-on-stale step were removed
(intentional/deliberate staleness is not a bug, so an unsolicited
recurring alert is noise). The CLI command, the gate wrapper, and all
tests are unchanged.
## Gates
- `ruby showcase/bin/spec/test_reconcile_prod.rb` → **9 runs, 20
assertions, 0 failures**
- `bats showcase/scripts/__tests__/reconcile-prod-gate.bats` → **6 ok**
- `shellcheck -s bash showcase/scripts/reconcile-prod-gate.sh` →
**clean**
- `actionlint .github/workflows/showcase_reconcile.yml` → **clean** (the
pre-existing `depot-ubuntu-24.04-4` custom-runner-label warning is on
`showcase_validate.yml`, predates this PR — my only change there is one
line in the shellcheck list)
## Test plan
- [ ] CI green (Ruby suite, bats suite, actionlint/shellcheck,
commitlint)
- [ ] Optional: read-only `workflow_dispatch` run of
`showcase_reconcile.yml` to confirm it runs against live prod/staging
(safe — no mutations)
## What
Adds **`@copilotkit/bot-whatsapp`** — a WhatsApp Business **Cloud API**
`PlatformAdapter` for the platform-agnostic `@copilotkit/bot` engine —
plus a runnable **`examples/whatsapp`** app and docs. This brings
WhatsApp to the bots ecosystem alongside the existing Slack support,
reusing the engine, the `@copilotkit/bot-ui` IR, and the pluggable
`ActionStore` untouched.
## How it works
- **Ingress:** the adapter owns its own HTTP server — GET verification
handshake (`hub.challenge`) + POST intake validated by
`X-Hub-Signature-256` HMAC (timing-safe), acked `200` immediately then
processed async.
- **No streaming:** WhatsApp messages are immutable, so the run renderer
**buffers** text and sends once on `TEXT_MESSAGE_END`
(`supportsStreaming: false`; `update()` posts fresh, `delete()` no-ops).
- **Interactive mapping:** text/section → text; ≤3 buttons →
reply-button message; `Select` or 4–10 actions → list message; >10 →
numbered-text fallback. A control's `value` round-trips by encoding it
into the reply id (`ck:…::<json>`), since WhatsApp replies carry no
value field; oversized encodings fail loud rather than corrupt silently.
- **Memory:** WhatsApp exposes no readable history, so a pluggable
**`HistoryStore`** (default `InMemoryHistoryStore`) holds it and replays
it into `agent.messages` each turn (fresh threadId per turn, mirroring
`bot-slack`). Swap in a durable backend to persist across restarts.
- **Commands:** leading-keyword matching (`commandPrefix`, default `/`);
the command text is injected via the engine's `runAgent({ prompt })`
path (not persisted at ingress).
- **Inbound media** → AG-UI multimodal content parts; **HITL** via
interactive replies.
## Example
`examples/whatsapp` mirrors `examples/slack`: a CopilotKit
`BuiltInAgent` over MCP (Linear + Notion), with `issue_list`, an
interactive `show_incident`, and a `confirm_write` HITL gate.
## Tests & verification
- 62 unit tests across the package (render mapping, markdown→WhatsApp,
signature verification incl. wrong-but-equal-length, interaction
decode/round-trip, buffered renderer, webhook listener/server, stores,
media, adapter).
- `build` ✅, package `check-types` ✅, `publint`/`attw` (ESM-only) ✅,
example `check-types` ✅. Full `nx run-many -t test
--projects=packages/**` passes.
- Two rounds of code review (APPROVE) — fixed slash-command history
double-append and silent value-truncation; minors (HMAC over raw bytes,
conversationKey invariant, offset-correct Blob, unused-dep pruning,
added tests).
## Docs
Package `README.md` + `ARCHITECTURE.md`, example setup guide (Meta app +
webhook + tunnel), and a `shell-docs` WhatsApp guide page (registered in
`meta.json` + early-access gate).
## Notes / out of scope (v1)
- No template-send path for messaging outside WhatsApp's 24-hour
customer-service window (documented limitation).
- Pre-existing, unrelated `@copilotkit/core` `phoenix-observable.ts`
typecheck error exists on the branch base (missing `@types/phoenix`) —
not introduced here.
## What
Completes the cvdiag flap-observability instrument so **d5/d6/e2e probe
runs are readable from `cvdiag_events`** — previously only the d4 driver
emitted probe-layer rows, leaving the d5/d6 path (where the dashboard
flaps live) a blind spot.
- Extract `CvdiagProbeSession` (+ event shapes, constants,
`turnCompleteReason`) from `d4-chat-roundtrip.ts` into shared
`cvdiag/probe-session.ts`; d4 re-imports (behavior-preserving).
- Wire `CvdiagProbeSession` into `d6-all-pills.ts::runFeature`: emit
`probe.start/navigate.complete/message.send/firstToken` + an
exactly-once guarded `probe.exit` carrying `terminal_outcome` +
`failure_classifier`, and close the probe↔backend `test_id` join
(X-Test-Id already injected).
- Thread `cvdiagPbWriter` through `orchestrator.ts` (fleet worker) +
`cli/runner.ts` (`--live`) so probe events persist to `cvdiag_events`.
## Why
The d5/d6 probe path emitted **zero `probe.exit` rows** (verified: 2
days of cvdiag retention = 100% `d4-`, zero d5), so a flapping d5 cell
(e.g. `dom-missing` reds) could not be diagnosed from staging data. This
closes that gap.
## Verification
- Local red-green on the real surface (`langgraph-typescript --d5`):
`probe.exit` rows **0 → 38** (terminal_outcome + failure_classifier
populated).
- Full harness suite: **3167/3167 passing**; tsc/oxlint/oxfmt/build
clean.
## Code review (2-round cr-loop, 7 agents/round, converged + Procedure 3
clean)
- **A1** — `messageSend` char-count ran unguarded in the probe path; a
non-string input could throw and red a green probe. Fixed: computation
moved inside the `if (cvdiag)` guard + non-string coerced. (red-green)
- **A2** — `parseFailureClassifier` used a stale hardcoded 4-member
allow-list omitting `selector-mismatch`; reconciled both membership
checks to the canonical `FAILURE_CLASSIFIER_SET` (derived from
`CVDIAG_FAILURE_CLASSIFIERS`). (red-green)
## Follow-ups (not in this PR)
- `--headed` CLI launcher lacks the `goto`-wrap that installs the SSE
interceptor, so cvdiag (newly wired into `--headed`) mislabels
`failure_classifier` there; the supported fleet/`--direct` path is
correct. (dev-path quality)
- d6 feature-concurrency: 4 concurrent features share `test_id`
`d6-<slug>-<runId>`; per-feature reads work via `demo=featureType`, but
the §5 sequence_num join + replay buffer would benefit from per-feature
keying.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
A `shell-docs` promote expanded its dependency closure to include the
always-on Tier-1 verification set (harness, dashboard, …); harness then
tripped a P6 env-divergence WARN-refusal and the tier barrier gated docs
as NOT-ATTEMPTED. docs has no runtime dependency on the control plane.
Introduce a declarative `standalone` service class: a leaf that neither
depends on anything nor gates on anything. computePromoteClosure (TS) and
the resolve-promote-targets jq both skip the Tier-1 union when the request
is entirely standalone, so a standalone request promotes ONLY itself; the
fleet runner promotes `s:`-marked services ungated (never NOT-ATTEMPTED on
an unrelated failure, never gating a tier). Flag `docs` standalone.
Red-green: railway-envs.test.ts (4), resolve-promote-targets.bats (5),
promote-fleet.bats (3) fail on origin/main (docs closure pulls harness;
`s:` is an unknown tier) and pass after the fix.
- open a per-feature CvdiagProbeSession for each d5/d6 pill probe
- emit exactly-once probe.exit and failure_classifier per session
- join probe-session output to its run via the X-Test-Id header
- thread cvdiagPbWriter through the orchestrator and CLI runner
Call-Site Enumeration: FAILURE_CLASSIFIER_SET is exported from
cvdiag/probe-session and consumed by d6-all-pills (classifier validation
against the canonical set). The export has no other call sites; any future
classifier addition must update the canonical set in probe-session and the
validation in d6-all-pills together.
Behavior-preserving extraction of the CvdiagProbeSession lifecycle from the
d4 chat-roundtrip driver into a shared cvdiag/probe-session module, so the
d5/d6 probe path can reuse the same session boundaries. d4-chat-roundtrip
now imports the extracted session instead of defining it inline.
## Summary
- Backports the generated/root Threads guide content into the shared
authored Threads snippet.
- Adds the CLI “Choose your starting point” path, manual path, thread
lock options, Enterprise Intelligence CTA, and corrected next-step links
to authored Threads docs.
- Standardizes authored integration Threads pages to explicitly import
the shared snippet with `components={props.components}` so authored
routes stay aligned.
## Authored routes covered
- AG2
- Agno
- AWS Strands
- Built-in Agent
- CrewAI Flows
- LangGraph
- LlamaIndex
- Mastra
- Microsoft Agent Framework
- PydanticAI
## Validation
- `npm run pretypecheck` in `showcase/shell-docs`
- `npm run lint` in `showcase/shell-docs` (passes with existing
warnings)
- `npm run test` in `showcase/shell-docs`
- `npm run typecheck` in `showcase/shell-docs`
- `npm run build` in `showcase/shell-docs` (passes with existing
Next/Turbopack warnings)
- `git diff --check`
- Manual MDX link sweep for changed docs links (`/premium/self-hosting`,
`/premium/threads-explained`, `/reference/hooks/useThreads`, and
`http://localhost:3000`)
## Formatter note
- `pnpm run check-format` currently fails on unrelated existing files
under `examples/showcases/arcade-tools/*`,
`examples/v2/react/demo/tsconfig.json`, `migrations.json`, and
`nx.json`.
- Scoped `oxfmt --check` does not treat the changed MDX files as target
files, so there is no formatter-owned MDX change to apply here.
Prod sitting behind staging is often intentional (changes are batched and
promoted deliberately), so a recurring drift alert is noise. Reshape the
reconcile workflow to manual-only:
- Remove the daily `schedule:` cron trigger — leave only `workflow_dispatch`.
- Remove the auto-Slack-on-stale step (and its SLACK_WEBHOOK env / stale_line
output derivation) — no unsolicited #oss-alerts post on mere staleness.
- A manual run surfaces the reconcile table to the GH step summary, keeps the
cheap `--json` capture as an uploaded artifact, and still exits nonzero on a
stale column so a manual run visibly flags drift.
- De-noise the gate script + bats comments that referenced the removed
scheduled/Slack behavior.
The on-demand CLI (`bin/railway reconcile-prod`), the gate wrapper, and the
Ruby + bats tests are unchanged.
Lever 1 of the promote-reliability hardening plan. The showcase deploy
model is staging=mutable :latest (continuously rebuilt), prod=immutable
@sha256: (advances only on explicit promote), so a prod column can
silently fall BEHIND a green staging — drift today is only noticed by
eyeballing a dead column. This adds proactive, automatic detection.
- bin/railway reconcile-prod: for every prod-eligible (probe.prod==true)
service, compares the prod SERVING digest (LintProd snapshot path) vs
the staging RUNNING digest (reuses PromoteCommand#staging_running_digest).
Classifies green/stale/gray, prints a table + summary, exits 1 iff any
stale. --json for machine output. Read-only: no promotes/mutations.
- scripts/reconcile-prod-gate.sh: wrapper mirroring lint-prod-gate.sh —
surfaces the table to the GH step summary, captures JSON for the Slack
builder, propagates the exit-code verdict.
- .github/workflows/showcase_reconcile.yml: daily cron + workflow_dispatch;
runs the gate; on stale services posts the stale-column list to
#oss-alerts (SLACK_WEBHOOK_OSS_ALERTS) via the fromJSON('"\n"') idiom.
- Tests: Ruby minitest (classification + exit-code, RED-anchored on a
drift-blind classifier) and a bats gate test. Wired the gate script
into the showcase_validate.yml shellcheck list.
Post-promote convergence verification is deferred to a fast-follow.
## Summary
- Rename the overview capability from "Cloud-hosted web app" to
"Cloud-hosted Intelligence features".
- Remove the redirecting multi-conversation tutorial link from thread
docs, shared thread snippets, and useThreads references.
## Validation
- npm run test (showcase/shell-docs)
- npm run lint (showcase/shell-docs; exits 0 with pre-existing warnings)
- npm run typecheck (showcase/shell-docs)
- npm run build (showcase/shell-docs)
- Manual link sweep for edited MDX confirmed no remaining
/tutorials/multi-conversation-chat links
schema.json regenerated from the merged canonical schema.ts (failure_classifier
probe.exit additions UNION backend request.ingress/sse.first_byte/llm.call.*
boundaries + test_id adoption). Per-integration staged schema.ts copies
re-derived via 'showcase cvdiag-stage-ts' so codegen --check and stage --check
are both in sync. No hand-merge of generated artifacts.
Mike Ryan