[Epic]: Cross-team dependencies for the console

## Executive Summary

We want to track five items the console cannot resolve on its own because the code, decision, or
sign-off they need lives outside this repo's team boundary — backend `lightbridge-authz`, the
`cratestack` codegen toolchain, or a product/security owner — because leaving them untracked lets
console work silently stall on a dependency nobody outside the console team can see. This epic
exists to solve the visibility gap: without it, a blocked console ticket looks identical to an
abandoned one.

## Strategic Intent

The intent of this epic is to give every cross-team dependency blocking console work a single,
durable, visible home — one ticket per dependency, naming the owning team, staying in Todo until
that team responds — so the console roadmap is never silently blocked by something invisible to
the people who could unblock it.

## Problem Statement

Five pieces of console-adjacent work require action from a team the console cannot direct: a
version-pin lockstep bump on the backend, a new field on the usage API contract, two `cratestack`
codegen toolchain features, and a product/security sign-off on an authorization-shape decision
already shipped. Today these live as scattered code comments, README caveats, and an unresolved
PR discussion — not as tracked, assignable work. Impact on users: none directly yet, but each item
either blocks a specific console capability (the latency dashboard) or leaves a correctness risk
live (the version-drift incident the lockstep pin exists to prevent) or a workaround permanently
in the tree (the two `cratestack` workarounds). Impact on engineering: console engineers re-discover
these constraints by reading source comments instead of a tracker; there is no forcing function for
the owning teams to respond.

## Desired Outcome

Each of the five dependencies has its own ticket, assigned conceptually to its owning team,
stating plainly what the console needs and why the console itself cannot deliver it. Console work
that depends on one of these is linked to the relevant ticket instead of silently stalling. As each
owning team resolves its item, the ticket closes and any blocked console ticket becomes unblocked.

## Scope (In / Out)

### In Scope
- Five tracked tickets, one per external dependency, each stating: what is needed, why the console
cannot resolve it itself, what console work it blocks (if any), and what "done" looks like from
the console's perspective.
- Linking each ticket to this epic as a sub-issue so board rollups reflect dependency status.

### Out of Scope
- Implementing any of the five items — they are explicitly owned by backend, `cratestack`
maintainers, or a product/security owner, not the console team.
- Chasing or escalating the owning teams outside of normal ticket triage.
- Any console-side workaround beyond what already exists (e.g. the CBOR/WASM asset-copy script,
the generated-specifier normalization script) — those stay in place until their upstream item
lands, and are removed in their own console-side follow-up once it does.

## Source of truth (links)

- https://github.com/ADORSYS-GIS/converse-frontends/blob/main/packages/authz-rpc/README.md
- https://github.com/ADORSYS-GIS/converse-frontends/pull/257
- https://github.com/ADORSYS-GIS/converse-frontends/pull/223
- https://github.com/ADORSYS-GIS/converse-frontends/blob/main/docs/adr/0008-console-shell-inversion-and-visual-direction.md
- https://github.com/ADORSYS-GIS/converse-frontends/blob/main/docs/adr/0009-nextjs-console-replacement.md
- https://github.com/ADORSYS-GIS/converse-frontends/blob/main/openapi/usage.backend.yaml

## Stakeholders

- Product Owner / Technical Lead / Delivery Owner: @stephane-segning
- Backend counterpart: `lightbridge-authz` team (owns the cratestack version pin and the usage API
contract)
- Tooling counterpart: `cratestack` maintainers (owns the CLI/codegen feature set)
- Security/Compliance sign-off: whoever owns authorization-model decisions for the console (item 5)

## Key Assumptions

- Each owning team can pick up its ticket independently; there is no ordering dependency between
the five items themselves.
- The console-side workarounds already in the tree (CBOR/WASM asset copy, specifier normalization)
remain acceptable stopgaps until their upstream item lands — none of them block a release today.
- The version-pin lockstep ticket is the only one with release-blocking urgency (P0); the rest are
scoped work items or a sign-off, not incidents.

## Constraints

- None of these five items can be implemented inside `converse-frontends` — by definition, each
requires a change or decision outside this repo's control (backend repo, `cratestack` toolchain
repo, or a human sign-off).
- This epic and its tickets stay in Todo (per the shared board convention) until the owning team
responds; the console team does not self-assign the resolution work.

## Risks

| Risk | Probability | Impact | Mitigation |
| --- | --- | --- | --- |
| Backend deploys with a cratestack version that has drifted from the frontend's 0.8.13 pin, repeating the untagged/tagged `Value` wire-format incident (`lightbridge-authz#282`) | Medium | High — silent data corruption, e.g. the `allowedModels` governance allowlist defeat already seen once | Ticket 1 tracks the backend-side pin explicitly; console deploy is gated on confirmation, not a green CI run alone |
| Latency dashboard work (Epic 4) stays blocked indefinitely because the usage API field never lands | Medium | Medium — one dashboard section stays in a permanent "blocked" state | Ticket 2 is the single tracked place that unblocks it; Epic 4's ticket cites this one |
| The two `cratestack` toolchain items never land, so their console-side workaround scripts become permanent rather than temporary | Low | Low — cosmetic tech debt, no functional risk while Epic 5 (Expo retirement) is pending anyway | Tickets 3 and 4 stay open at P2; both workarounds are already documented, not hidden |
| The role-derivation widening ships without sign-off indefinitely, leaving an unreviewed authorization-shape change live in production | Low | Medium — an authorization decision without recorded accountability | Ticket 5 tracks the outstanding PR #223 discussion explicitly at P1 |

## Success metrics

| Metric | Current | Target | Source |
| ------ | ------- | ------ | ------ |
| Cross-team dependencies with a tracked, owned ticket | 0 | 5 | This epic's sub-issues |
| Console tickets silently blocked with no visible dependency link | Unknown (not tracked) | 0 | Epic 4 latency ticket links to Ticket 2 |
| Version-pin lockstep confirmed before next console deploy | Unconfirmed | Confirmed in Ticket 1 before deploy | Ticket 1 |

## Child User Stories

This epic's shape differs from the console's other epics: five tickets hang directly off the epic
with no intermediate stories, because each is a standalone external ask with no internal
sub-decomposition.

- Ticket: Backend cratestack pin → 0.8.13 before any console deploy — P0 · S · 2
- Ticket: Usage API — expose latency/percentile fields — P1 · M · 3
- Ticket: cratestack — Hermes/RN backend for `@cratestack/cbor` — P2 · M · 3
- Ticket: cratestack — `--relative-specifier-style` emit option — P2 · S · 2
- Ticket: Sign-off on the console's role-derivation widening — P1 · XS · 1

**Estimation model.** Points: XS=1, S=2, M=3, L=5, XL=8. One point ≈ half a dev-day for an advanced
engineer, including tests, the governance PR, and review turnaround. Team: 4 advanced + 2 senior =
6 delivery engineers; the scrum master carries no delivery points. At a 70% focus factor a 2-week
sprint ≈ 48 points. Epic points = sum of its tickets (there are no stories in this epic to roll up
through). **Epic 6 total: 11 points.**

## Human accountable owner

@stephane-segning

## AI Usage Declaration

Ticket decomposition

## Human verification completed

- [ ] Intent checked against source of truth
- [ ] Scope reviewed by Product Owner
- [ ] Technical feasibility reviewed by Technical Lead
- [ ] Risks reviewed
- [ ] Acceptance criteria reviewed
- [ ] No unverified AI claim remains
- [ ] I am the accountable owner and accept responsibility for this epic.