Current product decision:

Stop treating VPN, Remote Server/Desktop Access, video, file transfer, and
future services as separate transport implementations. The next implementation
work should focus on the shared Fabric Service Channel runtime described in
`docs/architecture/FABRIC_SERVICE_CHANNEL_RUNTIME.md`.

The immediate engineering target is:

- backend service-channel lease/route-generation contract
- node-agent entry runtime for client/service live connections
- service-neutral channel scheduling, bounded queues, route health, and
  failover
- VPN packet flow as the proving service over that common channel
- backend relay only as explicit degraded fallback

Backend service-channel lease/route-generation contract is now started:

- `POST /clusters/{clusterID}/fabric/service-channels/leases` issues
  `rap.fabric_service_channel_lease.v1`
- VPN client profiles embed `fabric_service_channel_lease`
- tests cover ready route and degraded backend-relay fallback behavior
- leases include entry HTTP/WebSocket endpoint templates for the selected
  service channel
- leases include cluster-authority-signed
  `rap.fabric_service_channel_lease_authority.v1` payloads that bind token
  hash, selected route, generation, fencing epoch, and expiry

Node-agent entry runtime is now started:

- `rap-node-agent` accepts VPN packet batches through
  `/api/v1/clusters/{clusterID}/fabric/service-channels/{channelID}/vpn-connections/{vpnConnectionID}/packets`
  and `/packets/ws`
- entry runtime requires a `rap_fsc_*` service-channel token and maps packet
  batches to the existing production `vpn_packet` fabric route
- route failure falls back to the canonical backend relay endpoint so degraded
  compatibility remains explicit

Next narrow runtime layer:

- persist cluster-level default window policy for Fabric diagnostics
  investigation breadcrumbs and expose a small admin control for it
- keep this in the shared Fabric Service Channel runtime contract and telemetry
- do not add Android/RDP protocol work in this slice

C17Z20 is complete.

Installation Authority foundation is also complete:

- production config requires strict authority mode with Product Root public key
- first-owner bootstrap requires a signed activation manifest in strict mode
- `installation_authority` and signed `platform_role_grants` are persisted
- strict platform-admin checks ignore direct `users.platform_role` edits unless
  a valid signed grant exists
- web-admin shows installation status and first-owner bootstrap
- `scripts/installation/product-root-tool.go` can generate Ed25519 Product Root
  keys and sign activation manifests; private keys must stay outside the repo

Cluster Authority foundation is now also complete:

- every newly created cluster gets an Ed25519 `cluster_authorities` key record
- cluster authority private keys are encrypted at rest when
  `SECRET_ENCRYPTION_KEY_B64`/file is configured; production already requires
  a secret encryption key
- legacy/default clusters are backfilled lazily through `EnsureClusterAuthority`
- backend signs join-token scope material, node approval/bootstrap material,
  and node-scoped synthetic mesh config snapshots
- node-agent verifies signed Control Plane synthetic config when
  `authority_required=true` or signature fields are present
- node-agent can pin `RAP_CLUSTER_AUTHORITY_PUBLIC_KEY` and
  `RAP_CLUSTER_AUTHORITY_FINGERPRINT`, and identity state can store the same
  trust anchor after approval
- web-admin shows cluster key fingerprints on summaries, join-token output,
  approval rows, and synthetic config visibility
- docker-test lifecycle smoke is complete: fresh dev install, first-owner
  bootstrap, cluster creation, signed join token, real node-agent enrollment,
  owner approval, automatic signed bootstrap polling, authority pin
  persistence, heartbeat, and signed synthetic config verification all passed
- `rap-node-agent` desired-workload polling/status reporting is gated by
  `RAP_WORKLOAD_SUPERVISION_ENABLED=false` by default while service runtime
  supervision remains a stub

Node enrollment bootstrap polling is also complete:

- backend exposes `/node-agents/enrollments/{requestID}/bootstrap`
- pending agents prove `cluster_id`, `node_fingerprint`, and `public_key`
  before receiving status/bootstrap material
- `rap-node-agent` stores `pending_join_request_id`, polls approval, verifies
  the signed bootstrap contract, then persists `node_id`, `identity_status`,
  and cluster authority pin into `identity.json`
- polling is controlled by `RAP_ENROLLMENT_POLL_INTERVAL_SECONDS` and
  `RAP_ENROLLMENT_POLL_TIMEOUT_SECONDS`

Current state:

- C17Z12 added rendezvous/relay control-plane leases for peers that would
  otherwise stay in `waiting_rendezvous`.
- C17Z13-C17Z14 added lease telemetry and node-scoped synthetic-config refresh
  for renewal/stale relay recovery.
- C17Z15 added backend stale-relay replacement/withdrawal policy and alternate
  relay-pool scoring.
- C17Z16 added Control Plane `route_path_decisions`.
- C17Z17 added node-side route generation apply/withdraw tracking.
- C17Z18 applies Control Plane `route_path_decisions` to synthetic
  route-health route config only. The synthetic `fabric.route_health` runtime
  now probes the selected effective path, including replacement relay paths,
  and reports expected/observed hops plus drift state.
- C17Z19 consumes those synthetic route-health observations in backend relay
  scoring. Drift/unreachable/failure feedback marks the exact selected relay
  stale and can trigger replacement; healthy low-latency route-health boosts
  alternate relay score reasons. Migration `000022` adds the `synthetic` mesh
  service class, and web-admin marks relay policy `rh feedback`.
- C17Z20 closes the node-side feedback loop. After node-agent reports
  synthetic route-health drift/unreachable/failure, it performs a bounded
  node-scoped synthetic-config refresh, applies returned replacement route
  decisions to route-health config immediately, and reports
  `c17z20.mesh_route_health_feedback_refresh_report.v1`.
- Backend `mesh_latest_links` now keeps latest observations per observation
  type/route, so `synthetic_route_health` is not overwritten by
  `peer_connection_manager`.
- Web-admin Fabric links now show observation type, selected relay, and
  route-health effective/observed path.
- All of this remains control-plane/synthetic route-health only. It does not
  forward RDP/VPN/service payloads, does not start VPN runtime, and does not
  implement arbitrary relay packet forwarding.
- Cluster Authority and node enrollment bootstrap are docker-test
  lifecycle-smoke verified in run `dev-bootstrap-20260428-201430`.
- Fresh migration replay found and fixed a PostgreSQL view replacement issue in
  `000021_cluster_authority_keys`; the migration now drops/recreates
  `cluster_admin_summaries` in up/down paths.

Runtime report:

- `artifacts/c17z18-route-health-effective-path-report.md`
- `artifacts/c17z19-route-health-feedback-report.md`
- `artifacts/c17z19-route-health-feedback-smoke-result.json`
- `artifacts/c17z20-route-health-feedback-refresh-report.md`
- `artifacts/dev-cluster-enrollment-bootstrap-smoke-report.md`
- `artifacts/c18w-service-channel-route-manager-smoke-result.json`
- `artifacts/c18x-service-channel-logical-channel-smoke-result.json`
- `artifacts/c18y-route-intent-lifecycle-smoke-result.json`
- `artifacts/c18z-service-channel-load-smoke-result.json`
- `artifacts/c18z1-live-service-channel-ingress-smoke-result.json`
- `artifacts/c18z2-live-service-channel-soak-smoke-result.json`
- `artifacts/c18z3-live-service-channel-entry-ws-fallback-smoke-result.json`
- `artifacts/c18z4-live-service-channel-session-pressure-smoke-result.json`
- `artifacts/c18z5-live-service-channel-exit-restart-smoke-result.json`
- `artifacts/c18z6-live-service-channel-active-rebuild-smoke-result.json`
- `artifacts/c18z7-live-service-channel-concurrent-isolation-smoke-result.json`
- `artifacts/c18z8-live-service-channel-backpressure-isolation-smoke-result.json`
- `artifacts/c18z9-live-service-channel-route-pool-smoke-result.json`
- `artifacts/c18z10-live-service-channel-exit-pool-smoke-result.json`
- `artifacts/c18z11-live-service-channel-entry-pool-smoke-result.json`
- `artifacts/c18z12-service-channel-route-quality-smoke-result.json`
- `artifacts/c18z13-live-service-channel-route-quality-smoke-result.json`
- `artifacts/c18z14-live-service-channel-active-quality-shift-smoke-result.json`
- `artifacts/c18z15-live-service-channel-effective-quality-smoke-result.json`
- `artifacts/c18z16-live-service-channel-quality-fairness-smoke-result.json`
- `artifacts/c18z17-live-service-channel-quality-cleanup-smoke-result.json`
- `artifacts/c18z18-service-channel-session-scoped-fairness-smoke-result.json`
- `artifacts/c18z19-service-channel-parallel-flow-window-smoke-result.json`
- `artifacts/c18z20-service-channel-adaptive-window-telemetry-smoke-result.json`
- Docker-test smoke command:
  `pwsh -NoProfile -ExecutionPolicy Bypass -File scripts\fabric\c17z12-rendezvous-relay-smoke-ssh.ps1 -KeepRunning`
- Dev lifecycle smoke command:
  `pwsh -NoProfile -ExecutionPolicy Bypass -File scripts\fabric\dev-cluster-enrollment-bootstrap-smoke-ssh.ps1 -KeepRunning`
- Last proven runtime run: `c17z18-20260428-221601` (legacy smoke script name,
  current C17Z20 node-agent code)
- Last proven dev lifecycle run: `dev-bootstrap-20260428-201430`
- Admin: `http://192.168.200.61:18080/`
- C17Z20 multi-agent API: `http://192.168.200.61:18120/api/v1`
- C17Z19 backend-only API: `http://192.168.200.61:18122/api/v1`
- Dev lifecycle API: `http://192.168.200.61:18121/api/v1`

Do not automatically continue into:

- RDP/VNC/SSH/file/video/service workload traffic over mesh
- VPN/IP tunnel runtime implementation
- arbitrary relay packet forwarding
- production payload forwarding for relay paths
- QUIC/WebRTC or STUN/TURN/ICE
- TUN/TAP, host route, DNS, or firewall manipulation
- backend/session lifecycle changes
- Windows client changes

Current active next layer after the 2026-05-09 C18Z109 breadcrumb freshness
window proof:

C18Z48/C18Z49/C18Z50/C18Z51/C18Z52/C18Z53/C18Z54/C18Z55/C18Z56/C18Z57/C18Z58/C18Z59/C18Z60/C18Z61/C18Z62/C18Z63/C18Z64/C18Z65/C18Z66/C18Z67/C18Z68/C18Z69/C18Z70/C18Z71/C18Z72/C18Z73/C18Z74/C18Z75/C18Z76/C18Z77/C18Z78/C18Z79/C18Z80/C18Z81/C18Z82/C18Z83/C18Z84/C18Z85/C18Z86/C18Z87/C18Z88/C18Z89/C18Z90/C18Z91/C18Z92/C18Z93/C18Z94/C18Z95/C18Z96/C18Z97/C18Z98/C18Z99/C18Z100/C18Z101/C18Z102/C18Z103/C18Z104/C18Z105/C18Z106/C18Z107/C18Z108/C18Z109 are complete. Backend is deployed on docker-test as
`rap-backend:fabric-service-channel-0.2.281-c18z109`; migration
`000029_fabric_service_channel_leases` is applied on the shared test database.
Node-agent image `rap-node-agent:0.2.270-c18z95` is built and deployed on
`test-1/2/3`; web-admin is rebuilt and deployed to `rap_web_admin`.
All three test nodes run the C18Z92 image, healthy, and current after policy
update. Node-agent still requires signed service-channel lease authority when
cluster authority is pinned, but if legacy clients cannot send signed lease
headers it now calls backend introspection before accepting the unsigned token.
Accepted ingress is visible as `accepted_by=signed|introspection|legacy_unsigned`
in structured node logs and via `X-RAP-Service-Channel-Accepted-By` on HTTP
packet ingress. Durable introspection stores only `token_hash` plus a scrubbed
lease payload, so backend restarts no longer break compatibility clients. Live
lease maintenance now lists active/expired durable compatibility leases and runs
bounded cleanup through the admin API/panel. Durable access telemetry now
aggregates node-reported accepted ingress counters by signed/introspection/
legacy path, with heartbeat metadata fallback and admin-panel visibility.
Access telemetry now also correlates active durable service-channel leases with
entry/exit nodes, primary route status, backend fallback, and latest
route-quality feedback when a route exists. Normal-route access diagnostics are
smoke-proven with a temporary direct `vpn_packets` route and healthy rolling
quality window. Degraded normal-route diagnostics are also smoke-proven: the
active channel stays on a normal primary route with `force_backend_fallback=false`
while route feedback becomes `fenced` and rolling failure/drop/slow counters are
visible. Active-channel remediation diagnostics now expose
`remediation_action`, reason, optional alternate route id/status, and operator
hint, with unit coverage for healthy/noop, rebuild, backend fallback, and
authorized alternate decisions. The alternate-route remediation branch is now
live-smoke-proven: a selected primary route is degraded after lease issuance and
access telemetry recommends `prefer_alternate_route` while keeping
`force_backend_fallback=false`. C18Z57 turns that recommendation into a bounded
machine-readable `remediation_command` on the active channel row, including the
primary route, replacement route, issued time, and command TTL capped to the
lease lifetime. C18Z58 projects those commands into node-scoped synthetic mesh
config and node-agent consumes `prefer_alternate_route` as an explicit
route-manager `applied` decision with source
`service_channel_remediation_command`. C18Z59 proves active traffic follows the
replacement route after remediation: runtime heartbeat evidence shows
`last_selected_route_id` and flow-scheduler `last_route_id` on the replacement
route, with no local/backend fallback and no route send failures. C18Z60 proves
the same replacement path under multiple independent VPN flow channels: a
twelve-packet batch is classified across multiple flow-scheduler channels, all
observed replacement-route sends avoid local/backend fallback, flow drops, and
route failures. C18Z61 raises that to a pressure batch of 128 IPv4/TCP-like
packets; runtime evidence shows 32 replacement-route flow stats, scheduler
high-watermark 5, max-in-flight 4, no fallback, no drops, and no route failures.
C18Z62 adds neutral traffic-class QoS wiring at the service-channel HTTP
ingress: `X-RAP-Traffic-Class` can mark `control`, `interactive`, `reliable`,
`bulk`, or `droppable`; default traffic remains backward-compatible bulk.
Unit tests prove scheduler priority order, and live smoke proves a bulk
128-packet pressure batch plus an interactive packet both move over the
replacement route with separate traffic-class flow stats and no fallback,
drops, or route failures. C18Z63 adds a controlled concurrent runtime proof: a
bulk traffic-class send is held in-flight while an independent interactive
traffic-class packet is sent through the same ingress, and interactive completes
before bulk release with `MaxInFlight >= 2`, no drops, and no failures.
C18Z64 adds compact runtime telemetry: `rap.fabric_flow_scheduler.v1` snapshots
include `traffic_class_counts`, so backend/admin/diagnostics can show active
flow-channel counts per traffic class without scanning each channel stat. It is
live-proven on `rap-node-agent:0.2.239-c18z64`; latest test-1 snapshot showed
`bulk=32`, `interactive=12`, drops 0. C18Z65/C18Z66 project those counts and
flow pressure fields into backend access telemetry at node, active-channel, and
cluster aggregate levels, and web-admin shows cluster/node/channel `flow QoS`
visibility. Live aggregate API result showed `bulk=32`, `interactive=12`,
`flow_channel_count=44`, `flow_max_in_flight=4`. C18Z67 adds a live HTTP
concurrent QoS proof: six parallel bulk service-channel requests ran while an
interactive traffic-class request was injected on the same entry path after
remediation; the interactive request completed in 132 ms, all 6 bulk requests
were accepted, 3072 post-remediation packets moved over the replacement route,
32 bulk and 12 interactive replacement-route flow stats were observed, and
fallback, route failures, flow drops, and scheduler drops stayed at 0. C18Z68
adds backend/admin flow-health guard diagnostics over that telemetry:
`flow_health_status` and `flow_health_reason` are projected at cluster, node,
and active-channel levels from traffic-class pressure, queue pressure, flow
drops, backend fallback, route-quality failures/drops/slow samples, and route
send latency. Web-admin now shows flow-health chips beside flow QoS.
C18Z69 adds node-side adaptive response: heartbeat flow-scheduler snapshots now
report per-class `recommended_parallel_windows` plus
`adaptive_backpressure_active/reason`, and the ingress send path uses the
traffic-class-specific window. Under pressure, bulk/droppable are reduced first,
reliable is reduced moderately, and control/interactive keep their full window
unless their own class degrades. Live smoke verified `bulk=1`, `droppable=1`,
`reliable=3`, `interactive=4`, `control=4`, no drops, and
`bulk_window_reduced_to_protect_interactive`. C18Z70 projects those adaptive
runtime fields into backend/admin access telemetry at cluster, node, and
active-channel levels. Cluster windows are aggregated by minimum non-zero
per-class recommendation, and web-admin shows adaptive window chips beside flow
health/QoS. Live API artifact shows `adaptive=true`,
`bulk_window_reduced_to_protect_interactive`, and windows `bulk=1`,
`droppable=1`, `reliable=3`, `interactive=4`, `control=4`. C18Z71 adds the
cluster-level adaptive policy contract:
`GET/PUT /clusters/{clusterID}/fabric/service-channels/adaptive-policy`.
The policy stores audited thresholds and class windows in cluster metadata,
projects the effective fingerprint into signed node-scoped synthetic config,
and node-agent heartbeat/runtime telemetry reports `adaptive_policy_fingerprint`.
The node scheduler consumes the policy at runtime; default policy preserves
bulk=1/droppable=1/reliable=3/control=4/interactive=4, while the C18Z71 smoke
proved an operator policy with max window 6 and `bulk=2` changes the live
recommended windows without breaking interactive/control. A signed-config hash
mismatch found during the smoke was fixed by preserving all signed adaptive
policy provenance fields in the node-agent client model. C18Z72 adds the
cluster-level pool/failover policy contract:
`GET/PUT /clusters/{clusterID}/fabric/service-channels/pool-policy`. Lease
issuance now applies the effective entry/exit pool constraints and preferred
entry/exit before route selection, stores the effective policy on the lease,
and signs it into `rap.fabric_service_channel_lease_authority.v1`. Live smoke
proved a policy-constrained lease selects only the policy entry/exit from a
wider requested pool and carries matching signed `pool_policy` provenance.
C18Z73 projects that signed pool-policy fingerprint into active access
telemetry and guards remediation commands against routes outside the signed
lease pools. C18Z74 correlates active remediation commands with entry-node
route-manager heartbeats and reports execution states such as
`waiting_node_apply`, `applied`, `rejected_by_policy_guard`,
`pending_rebuild_request`, and `expired`. C18Z75 records `rebuild_route`
remediation as durable rebuild ledger intent rows when node-scoped synthetic
config is fetched, and access telemetry reports `rebuild_request_recorded` or
`rebuild_request_rejected`. C18Z76 makes the allowed `rebuild_route` command
visible from the node side: node-agent consumes it as a route-manager
`pending_degraded_fallback` decision with source
`service_channel_remediation_command`, and backend access telemetry correlates
that with the durable ledger as `rebuild_request_recorded_node_pending`.
C18Z77 resolves durable remediation rebuild requests inside the shared Control
Plane planner: signed-pool-valid alternates become `applied` /
`replacement_selected` and are projected as route-manager decisions with the
same command id, missing safe alternates become `no_alternate`, lease/policy
blocks become `deferred_by_policy`, and stale commands become `expired`.
C18Z78 adds operator-visible planner outcome chips in web-admin and proves the
`applied` branch live by adding an alternate route after lease issuance and
verifying the existing rebuild command resolves to `rebuild_request_applied`.
C18Z79 closes the planner-to-runtime proof loop for that branch: after planner
resolution, the entry node reports a route-manager decision with the same
`rebuild_request_id`, the transition is `applied_rebuild`, and live
service-channel packet traffic selects the replacement route without
local/backend fallback, route failures, or flow drops. C18Z80 hardens that
same path under sustained pressure: after planner-applied rebuild, five
post-rebuild bursts of mixed `interactive`, `bulk`, and `reliable` VPN packet
batches stay on the replacement route, the stale primary is not reselected, and
fallback/route-failure/drop deltas stay zero from the pre-pressure baseline.
C18Z81 adds the negative/rollback proof: after the initial replacement is
applied and used, a generation-valid fenced feedback report for that
replacement causes the Control Plane to select a new safe recovery route; live
traffic then moves to the recovery route, the degraded replacement is not
reselected, and fallback/failure/drop deltas stay zero for the recovery send.
The C18Z81 work also tightened older smoke checks to use per-run counter deltas
instead of absolute cumulative runtime counters.
C18Z82 closes the no-safe-recovery branch: after the replacement route reports
generation-valid fenced feedback and no new safe recovery route is created,
node-scoped synthetic config surfaces `service_channel_feedback_no_alternate`
with `pending_degraded_fallback`, `no_unfenced_alternate_route`, and
`backend_relay_degraded_fallback_until_rebuild`, proving the Control Plane
exposes a degraded/no-alternate state instead of silently sticking to a bad
replacement.
C18Z83 projects those route-manager decisions into active access telemetry and
web-admin: active channels now expose route-decision source, route id,
replacement route id, rebuild status/reason/generation, and score reasons.
The live smoke proves the no-safe state is visible through access telemetry as
`service_channel_feedback_no_alternate` /
`pending_degraded_fallback`, with operator execution state remaining compatible
with durable ledger `rebuild_request_no_alternate`.
C18Z84 aggregates those per-channel decisions at the access-telemetry summary
level: route-decision channel count, replacement decision count, applied
rebuild count, recovery decision count, and no-safe recovery count are exposed
to the API and web-admin summary chips. The no-safe branch now prioritizes the
aggregate status reason `active_channels_no_safe_recovery` over generic missing
access-report noise.
C18Z85 projects access-decision aggregates into rebuild health and incident
diagnostics. Health summary now carries access decision counts and prioritizes
`inspect_access_no_safe_recovery_route_pool_and_signed_policy` when no-safe is
active. Rebuild incidents now include `incident_source=access_decision` rows
for active channel decisions such as `access_no_safe_recovery`, with bad
severity and channel id, so operators see route-decision failures beside ledger
incidents.
C18Z86 adds silence/acknowledgement behavior for those
`incident_source=access_decision` incidents. Silence requests now carry
`incident_source` and `channel_id`; access-decision no-safe silences are stored
with a channel-scoped route key, applied back into rebuild health/incidents,
and exact current-generation incidents stop contributing to active bad count.
Generation-changing access-decision resurfacing is unit-tested; the live smoke
proves the operator silence path on docker-test.
C18Z87 exposes active rebuild/access-decision silences to operators and adds
unsilence. The API now lists active rebuild alert silences, returns
access-decision `incident_source`, `channel_id`, and display route id, and
allows deleting a silence by id. Web-admin shows an `Active rebuild silences`
table with an unsilence action. The live smoke proves list -> silence ->
unsilence and verifies the access no-safe incident becomes active again.
C18Z88 makes access-decision resurfacing operator-visible in live runtime.
Access-decision incidents now expose the silence id they resurfaced from, the
previous acknowledged generation, and the silence expiry. The live smoke
proves: access no-safe incident -> silence current generation -> wait for a new
route-decision generation -> incident returns as `alert_resurfaced=true`, active
bad count is restored, and previous generation metadata is preserved.
C18Z89 closes the resurfaced-incident operator action loop for generation
changes. Resurfaced access-decision incidents now expose
`alert_resurfaced_cause`, previous route id, and previous channel id; web-admin
shows the cause beside resurfaced incidents. The live smoke proves the operator
can re-acknowledge the resurfaced generation, the active-channel decision
context matches the incident route/generation, and the current generation
returns to a silenced state.
C18Z90 introduces the explicit signed production data-plane contract on
service-channel leases. `data_plane` is now part of the lease, authority
payload, introspection response, and lease-maintenance/admin list. It declares
that control-plane traffic uses backend API, working data uses the fabric
service channel over fabric routes, backend relay is degraded fallback only,
production forwarding is required, and logical flows are service-neutral,
protocol-agnostic, and isolated. Web-admin shows this contract in the
service-channel lease table.
C18Z91 makes node-agent consume that signed/introspected data-plane contract.
Service-channel packet ingress validates the contract, applies the preferred
fabric route, emits data-plane mode/transport/fallback/logical-flow fields in
access logs, and reports contract adoption in heartbeat access telemetry.
C18Z92 enforces disabled backend fallback policy at node-agent runtime: when a
signed lease says `backend_relay_policy=disabled`, route failure or missing
fabric route returns a visible 503 instead of silently proxying working data
through backend relay.
C18Z93 promotes that data-plane contract telemetry into backend access
telemetry and web-admin active-channel diagnostics: cluster, node, and
active-channel rows now show contract adoption count, last working transport,
steady-state transport, backend relay policy, data-plane mode, and logical
flow mode.
C18Z94 turns those data-plane/fallback signals into operator incidents.
`data_plane_contract` incident rows are now emitted for missing data-plane
contract reports after accepted service-channel traffic, wrong working or
steady-state transport, wrong logical flow mode, disabled backend relay
observed, and degraded backend relay usage. The incident list/readiness path
can now surface a recommended action such as restoring the fabric route instead
of treating backend relay as normal service traffic.
C18Z95 adds node-agent blocked-fallback telemetry. When a signed data-plane
contract disables backend relay and the entry runtime cannot use a fabric
route, node-agent reports `backend_fallback_blocked`, the last data-plane
violation status/reason, and backend/admin project those fields to cluster,
node, channel, and `data_plane_contract` incident diagnostics. Disabled-policy
refusal is now separate from real backend relay usage.
C18Z96 wires normal-route send failure with disabled backend relay into the
existing route feedback and rebuild planner path. When heartbeat access
telemetry reports `fabric_route_send_failed_backend_fallback_blocked`, backend
correlates the entry node's active service-channel leases, records fenced
`fabric_service_channel_route_feedback` for the selected primary route, and the
existing planner can select an alternate/replacement route. This keeps blocked
fallback from becoming a dead-end operator alert.
C18Z97 adds bounded deduplication for those access-report-derived route
feedback records. Repeated blocked-fallback send-failure heartbeats no longer
rewrite the same active fenced feedback or churn planner rebuild attempts while
the first access-report feedback is still active. Runtime feedback from the
flow scheduler remains independent.
C18Z98 carries that feedback identity into the replacement decision and
rebuild-attempt ledger: decision and ledger rows now expose
`feedback_observation_id`, `feedback_source`, feedback observed/expiry time,
channel/resource ids, and data-plane violation status/reason. Web-admin shows
that correlation in Route decisions and Rebuild ledger.
C18Z99 adds rebuild ledger filters for those correlation fields. The backend
`/fabric/service-channels/rebuild-attempts` API accepts `feedback_source`,
`feedback_channel_id`, and `feedback_violation_status`, and web-admin exposes
the same filters in the rebuild ledger form. The live smoke proves source,
channel, violation, combined filters, and wrong-channel exclusion.
C18Z100 adds rebuild-health feedback breakdown aggregation for the same
correlation fields. The backend rebuild-health summary now returns
`feedback_breakdowns` grouped by feedback source, feedback channel id, and
feedback violation status, including total/good/warn/bad/unknown counts,
active warn/bad counts, silenced count, latest observation time, and affected
reporter nodes/routes. Web-admin shows this breakdown in the Rebuild health
panel so operators can see which access-report-derived failure classes dominate
active warn/bad rebuild state.
C18Z101 wires that breakdown into operator workflow in web-admin. Each
feedback-breakdown row now shows related incident context by channel/reporter/
route overlap and has an `open ledger` action that switches to the deep rebuild
ledger with `feedback_source`, `feedback_channel_id`, and
`feedback_violation_status` prefilled from the breakdown row.
C18Z102 adds backend audit breadcrumbs for that workflow. The existing rebuild
investigation endpoint now accepts feedback source/channel/violation drilldown
payloads, records
`fabric.service_channel_rebuild_feedback_breakdown.investigation_opened`
cluster audit events, and web-admin records one before opening the filtered
deep ledger from a rebuild-health feedback breakdown row.
C18Z103 surfaces those breadcrumbs directly in the Fabric diagnostics panel.
Web-admin now filters the loaded cluster audit list for rebuild incident and
feedback-breakdown investigation events and shows recent drilldowns with time,
source, feedback filters, target reporter/route, actor, and reason beside
rebuild incidents and silences.
C18Z104 adds focused audit loading for that panel. The cluster audit API now
accepts `event_type` and `target_type` filters, including repeated or
comma-separated values, and web-admin loads recent fabric investigation
breadcrumbs with a dedicated filtered request instead of depending on the
generic latest-100 cluster audit list.
C18Z105 correlates those focused audit breadcrumbs back to currently visible
diagnostics in web-admin. Recent investigation rows now show whether the
breadcrumb still matches an active rebuild-health feedback breakdown or visible
rebuild incident, and provide an `open` action to jump back into the matching
filtered ledger path.
C18Z106 moves that correlation into the backend/API. `GET /audit` with
`correlation=fabric_diagnostics` now returns `correlation_hints` for focused
fabric investigation breadcrumbs, including current diagnostic status
(`breakdown_active`, `incident_visible`, or `not_visible`) and the matching
breakdown/incident object when present. Web-admin consumes those hints and keeps
its previous local matching as fallback. During verification the noisy test
history exposed that rebuild-health feedback breakdowns were capped too tightly;
the backend now returns up to 100 breakdown groups so fresh failure classes are
not pushed out by older smoke history.
C18Z107 adds a compact backend-provided `audit_summary` beside `audit_events`.
For focused Fabric diagnostics audit reads, the summary includes total count,
counts by event/target type, counts by current diagnostic status, counts by
feedback source/violation status, correlated count, not-visible count, and
latest time. Web-admin shows these as Recent investigations chips and short
source/violation lines without recalculating the aggregate in the browser.
C18Z108 moves Fabric diagnostics investigation breadcrumbs off the generic
cluster audit read path. Backend now exposes
`GET /clusters/{clusterID}/fabric/service-channels/rebuild-investigations/breadcrumbs`
with a dedicated `rebuild_investigation_breadcrumbs` contract containing
events plus summary. Web-admin uses this endpoint for Recent investigations
and keeps generic audit semantics separate from Fabric diagnostics workflow
state.
C18Z109 adds freshness windows to the dedicated breadcrumb contract. The
endpoint accepts `current_window_seconds` and `history_window_seconds`, annotates
each breadcrumb with `correlation_hints.breadcrumb_status` (`current`, `stale`,
or `expired`) plus age/window seconds, returns current/stale/expired totals, and
adds `counts_by_breadcrumb_status` to the summary. Web-admin shows freshness
chips and an age column in Recent investigations, so operators can separate live
workflow hints from stale history without deleting audit records.
Live
verification passed:
`scripts/fabric/c18z48-service-channel-introspection-smoke.ps1` and
`scripts/fabric/c18z50-service-channel-durable-introspection-smoke.ps1` and
`scripts/fabric/c18z51-service-channel-lease-maintenance-smoke.ps1` and
`scripts/fabric/c18z52-service-channel-access-telemetry-smoke.ps1` and
`scripts/fabric/c18z53-service-channel-access-correlation-smoke.ps1` and
`scripts/fabric/c18z54-service-channel-normal-route-access-smoke.ps1` and
`scripts/fabric/c18z55-service-channel-degraded-route-access-smoke.ps1` and
`scripts/fabric/c18z56-service-channel-alternate-remediation-smoke.ps1` and
`scripts/fabric/c18z57-service-channel-remediation-command-smoke.ps1` and
`scripts/fabric/c18z58-service-channel-remediation-apply-smoke.ps1` and
`scripts/fabric/c18z59-service-channel-remediation-traffic-smoke.ps1` and
`scripts/fabric/c18z60-service-channel-remediation-multiflow-smoke.ps1` and
`scripts/fabric/c18z61-service-channel-remediation-pressure-smoke.ps1` and
`scripts/fabric/c18z62-service-channel-remediation-qos-smoke.ps1` and
`scripts/fabric/c18z67-service-channel-concurrent-qos-live-smoke.ps1` and
`scripts/fabric/c18z69-service-channel-adaptive-backpressure-smoke.ps1` and
`scripts/fabric/c18z71-service-channel-adaptive-policy-smoke.ps1` and
`scripts/fabric/c18z72-service-channel-pool-policy-smoke.ps1`, with
artifacts:
`artifacts/c18z48-service-channel-introspection-smoke-result.json`,
`artifacts/c18z50-service-channel-durable-introspection-smoke-result.json`, and
`artifacts/c18z51-service-channel-lease-maintenance-smoke-result.json`, and
`artifacts/c18z52-service-channel-access-telemetry-smoke-result.json`, and
`artifacts/c18z53-service-channel-access-correlation-smoke-result.json`, and
`artifacts/c18z54-service-channel-normal-route-access-smoke-result.json`, and
`artifacts/c18z55-service-channel-degraded-route-access-smoke-result.json`, and
`artifacts/c18z56-service-channel-alternate-remediation-smoke-result.json`, and
`artifacts/c18z57-service-channel-remediation-command-smoke-result.json`, and
`artifacts/c18z58-service-channel-remediation-apply-smoke-result.json`, and
`artifacts/c18z59-service-channel-remediation-traffic-smoke-result.json`, and
`artifacts/c18z60-service-channel-remediation-multiflow-smoke-result.json`, and
`artifacts/c18z61-service-channel-remediation-pressure-smoke-result.json`, and
`artifacts/c18z62-service-channel-remediation-qos-smoke-result.json`, and
`artifacts/c18z63-service-channel-concurrent-qos-go-test.jsonl`, and
`artifacts/c18z64-service-channel-traffic-class-telemetry-go-test.jsonl`, and
`artifacts/c18z64-service-channel-traffic-class-telemetry-live-smoke-result.json`, and
`artifacts/c18z64-service-channel-traffic-class-telemetry-live-snapshot.json`, and
`artifacts/c18z65-service-channel-access-qos-telemetry-api-result.json`, and
`artifacts/c18z65-service-channel-access-qos-telemetry-smoke-result.json`, and
`artifacts/c18z66-service-channel-access-qos-aggregate-api-result.json`, and
`artifacts/c18z67-service-channel-concurrent-qos-live-smoke-result.json`, and
`artifacts/c18z68-service-channel-flow-health-api-result.json`, and
`artifacts/c18z69-service-channel-adaptive-backpressure-smoke-result.json`, and
`artifacts/c18z70-service-channel-adaptive-telemetry-api-result.json`, and
`artifacts/c18z71-service-channel-adaptive-policy-smoke-result.json`, and
`artifacts/c18z72-service-channel-pool-policy-smoke-result.json`, and
`artifacts/c18z73-service-channel-pool-policy-remediation-guard-smoke-result.json`, and
`artifacts/c18z74-service-channel-remediation-execution-smoke-result.json`, and
`artifacts/c18z75-service-channel-rebuild-intent-smoke-result.json`, and
`artifacts/c18z76-service-channel-rebuild-node-pending-smoke-result.json`, and
`artifacts/c18z77-service-channel-rebuild-planner-resolution-smoke-result.json`, and
`artifacts/c18z78-service-channel-rebuild-planner-applied-smoke-result.json`, and
`artifacts/c18z79-service-channel-planner-runtime-loop-smoke-result.json`, and
`artifacts/c18z80-service-channel-post-rebuild-pressure-smoke-result.json`, and
`artifacts/c18z81-service-channel-replacement-degradation-recovery-smoke-result.json`, and
`artifacts/c18z82-service-channel-no-safe-recovery-smoke-result.json`, and
`artifacts/c18z83-service-channel-access-telemetry-no-safe-smoke-result.json`, and
`artifacts/c18z84-service-channel-access-decision-aggregate-smoke-result.json`, and
`artifacts/c18z85-service-channel-access-decision-incident-smoke-result.json`, and
`artifacts/c18z86-service-channel-access-decision-silence-smoke-result.json`, and
`artifacts/c18z87-service-channel-access-decision-unsilence-smoke-result.json`, and
`artifacts/c18z88-service-channel-access-decision-resurface-smoke-result.json`, and
`artifacts/c18z89-service-channel-access-decision-resurface-action-smoke-result.json`, and
`artifacts/c18z90-service-channel-data-plane-contract-smoke-result.json`, and
`artifacts/c18z91-node-agent-data-plane-contract-enforcement-smoke-result.json`, and
`artifacts/c18z92-node-agent-disabled-backend-fallback-smoke-result.json`, and
`artifacts/c18z93-access-telemetry-data-plane-contract-smoke-result.json`, and
`artifacts/c18z94-data-plane-contract-incident-smoke-result.json`, and
`artifacts/c18z95-node-agent-blocked-fallback-telemetry-smoke-result.json`, and
`artifacts/c18z96-blocked-fallback-rebuild-feedback-smoke-result.json`, and
`artifacts/c18z97-blocked-fallback-feedback-dedup-smoke-result.json`, and
`artifacts/c18z98-blocked-fallback-rebuild-correlation-smoke-result.json`, and
`artifacts/c18z99-rebuild-correlation-filter-smoke-result.json`, and
`artifacts/c18z100-rebuild-health-feedback-breakdown-smoke-result.json`, and
`artifacts/c18z102-rebuild-health-feedback-drilldown-audit-smoke-result.json`,
`artifacts/c18z104-focused-fabric-audit-smoke-result.json`, and
`artifacts/c18z106-audit-correlation-hints-smoke-result.json`, and
`artifacts/c18z107-audit-correlation-summary-smoke-result.json`, and
`artifacts/c18z108-dedicated-breadcrumbs-smoke-result.json`, and
`artifacts/c18z109-breadcrumb-freshness-window-smoke-result.json`.

Current active continuation after C20Z6:

C20Z1 through C20Z6 are implemented and runtime-smoke-proven. The C20 stage is
terminal-complete by contract. It opened and validated a new explicit
real-adapter enablement request as a contract-only transition:
`rap.remote_workspace_real_adapter_c20_stage_terminal_complete.v1`, with
`terminal_status=stage_terminal_complete_contract_only`,
`stage_status=complete_no_more_c20_layers_required`,
`stage_name=c20_real_adapter_new_explicit_enablement_request`,
`validation_chain_status=complete_contract_only`,
`enablement_boundary=runtime_enablement_requires_next_explicit_runtime_stage`,
`enablement_decision=validated_contract_only_not_enabled`,
`enablement_status=validated_not_enabled`,
`runtime_gate_state=validated_contract_only_not_enabled`,
`runtime_effect=contract_only_no_runtime_enablement`,
`operator_default_action=keep_real_adapter_disabled_until_next_explicit_runtime_stage`,
`next_allowed_entrypoint=next_explicit_runtime_enablement_stage_only`,
`allows_process_start=false`, and `allows_payload_traffic=false`. Docker-test
`test-1/2/3` remain on
`rap-node-agent:codex-service-supervisor-20260513z52`. Verification artifact:
`artifacts/c20z6-remote-workspace-real-adapter-stage-terminal-complete-compatibility-smoke-result.json`.

The not-approved factory remains terminal-complete by contract, and C20 is now
also terminal-complete by contract. Do not add more C20 continuation layers.
The only allowed next entrypoint is a new explicit runtime enablement stage.
Keep the real adapter disabled until that new stage explicitly changes runtime
state: no process start, no real RDP frame transport, no Android work, no
backend relay semantics, and no production adapter payload forwarding.