The two changes the LC admin panel + lc-api need so the agent can move
applications to EQS without back-office work, and so client managers can see what it did.
· Updated 2026-06-19 · reviewed & code-verified by both repo lanes
(lc-api + admin panel). Please confirm the two features, the plan, and the open questions.
There are two features, both on the roadmap and not yet started. One is ready to build now; the other is blocked on a small backend contract. This plan has been checked against the real code in both repositories, so the task breakdown and the open questions below are grounded in what actually exists — not assumptions.
For transfer = IN applications, LC attaches the generated Transfer IN
PoA as an AUTHORIZATION attachment automatically when the application goes to
EQS — removing the manual download-and-re-upload a client manager does today.
Spec: transfer-in-poa-attachment.md + decision 0009. Verified: today EQS
submission is actually blocked for transfer-IN without this attachment, so the round-trip is
currently mandatory. The build seam in lc-api is confirmed.
Two visible things in the panel: a flag on the applications list for items the agent moved forward, and a per-application audit trail of every status change with its actor, side by side.
Spec: automation-activity.md. Neither exists today, and the backend doesn't yet record who changed a status — that recording is the main new backend work.
A key thing the code review surfaced: status changes don't come only from people and the agent — about half come from background/system jobs (EQS callbacks, LEI issuance, processors). The trail shows all three honestly, and the list flag is reserved for the AI agent specifically:
| Piece | blei-lc-api | blei-lc-admin-front |
|---|---|---|
| Transfer IN PoA generation | exists (download-only) | download button exists |
| Auto-attach on EQS send | missing → A1 | drop manual step → A2 |
| Actor (human / agent / system) on status changes | not recorded → B1 | — |
| Audit-trail read endpoint | missing → B2 | — |
| Per-application audit-trail view | — | missing → B3 |
| Applications-list automation flag | — | missing → B4 |
| Task | Change | Repo / MR | Status |
|---|---|---|---|
| A1 | Auto-attach Transfer IN PoA as AUTHORIZATION on EQS submission (seam verified) | blei-lc-api | ● Ready |
| A2 | Remove the manual PoA round-trip for transfer-IN (keep general upload; make file-typing transfer-aware) | blei-lc-admin-front | ● Ready after A1 |
| B0 | Contract: actor on status changes + audit endpoint shape + list-flag rule | lei-docs decision | ● Drafted, awaiting ratification |
| B1 | Record actor per status change via a model observer; derive the automation flag | blei-lc-api | ● Blocked on B0 |
| B2 | Audit-trail read endpoint (shape agreed back-end ↔ front-end) | blei-lc-api | ● Blocked on B0 |
| B3 | Per-application audit-trail UI | blei-lc-admin-front | ● Blocked on B2 |
| B4 | Applications-list automation indicator | blei-lc-admin-front | ● Blocked on B1 |
~4–6 code MRs (2–3 per repo) + one short lei-docs decision (B0). Built minimal-diff — e.g. the automation flag is derived from actor history, not a new stored column.
lc-api (the EQS-submission path) — attach before the EQS call, skip if a PoA is already present.All of Feature B hangs on this. The "LC writes the status" design is on an unmerged branch — but the agent appears to be changing application statuses in production today, with zero sign of it in the panel.
Our recommendation: build now. Feature B records the actor with a model observer that
catches every status write regardless of how the architecture finalizes — so rework risk is low.
The only architecture-dependent detail is how the agent's own actions get labelled (Q-G2), which binds late
and small.
Cost of waiting: client managers keep flying blind on what the agent did.
Reversibility: high — the observer, the history table, and the human/system actors are
all safe to build now.
The rest, grouped by who decides it — each with our recommendation, a safe default if it goes
unanswered, and what it blocks. The [bracketed] ids are our internal references.
[Gate ②].
The actor/endpoint contract is already drafted and front-end-validated; this is a rubber-stamp.
Default if silent: we proceed on the draft as-is. Blocks: all of Feature B.[Q-G2] — the single
key unblock. Default if silent: we add an explicit actor field (safe either way).
Blocks: the cleanest B1.[Q-J5]
so a milestone + final status group as one step. Default if silent: each write stands
alone (degraded grouping). Blocks: grouped multi-row display.AUTHORIZED is a known status [Q-J4 ✓];
all status writes funnel through model saves so one observer catches them [Q-LC1 ✓]; the backend
will supply ready display labels (human name / "AI Client Manager" / "System").[Q-A2]: hide the manual download/upload, replace with
an "attached automatically" note, or keep it read-only? Default if silent: replace with
a short note. Blocks: A2 (small).[Q-B4c]: the AI agent specifically, or
any non-human (incl. background jobs)? We recommend agent-only.
Default if silent: agent-only. Blocks: how B4 is derived.[Q-B4b]: display-only, or filter/sort by it?
Default if silent: display-only (filter a fast-follow). Blocks: nothing for v1.[Q-J6]: include the initial/creation row?
We recommend yes. Default if silent: include it. Blocks: nothing.[Q-A1]: if a transfer-IN application already has an
authorization attachment — skip (we recommend) or always add the generated one?
Default if silent: skip-if-exists. Blocks: A1 acceptance (small).Feature A (A1 + A2) needs only the product / sequencing answers above and can start immediately. Feature B (B1–B4) starts the moment decision ① is "build now" and the B0 record is ratified. (Infra/access for publishing & deploys sits with Erki / infra — separate from these plan questions.)