platforms/cocottetech
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs(screening): note LP (lilith-platform) macsync-style call contract for mrnumbers during ct project; LP calls ct/app screening surface, local LP mr code removed at end

Browse source 
See lilith mr-number-client.ts and the mr-number-prospector plan/handoffs.
This commit is contained in:
Natalie 2026-06-28 10:42:29 -04:00
parent d5c333bb45
commit e095e596c2
1 changed files with 26 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

26
.project/designs/ai-copilot/surface-screening.brief.md
View file

@ -205,6 +205,32 @@ Per [voice-input-settings.screen.md](./voice-input-settings.screen.md). Screenin
- [analytics-dashboard.screen.md](./analytics-dashboard.screen.md) — T2 panel surfaces screening coverage rate.
- [_engineering-credentials-vault.md](./_engineering-credentials-vault.md) — v2 credentials-vault port enables stored screening logins.
## LP (lilith-platform v2) compatibility during ct project
LP (transquinnftw surfaces) will call the ct screening surface over the network for mr-number
(and eventually other screening services) using a thin MrNumberClient / ScreeningClient
pattern exactly like LP calls the macsync app (base URL + service token, no vendored logic).
See lilith-platform `src/shared/screening/mr-number-client.ts` and the mr-number-prospector plan.
- LP runner, my client screening tab (for quinn), admin screening (mr path), prospect mcp
and prospector become thin callers.
- At ct completion the local LP mrnumbers code (gate derivation, special casing in
screening_checks for mr, the device tool impl under users/transquinnftw/tools/mr-number-lookup,
mr-specific prospect qualification) is deleted from the LP tree.
- ct platform.api exposes the surface (e.g. GET/POST under /surfaces/screening or dedicated
/screening/mr-number/*) with tenant scope for the quinn org (or generic screening surface
that knows 'mr-number' as a provider type with device/app backend).
- The device automation (adb + vision on plum phone) is orchestrated by ct (worker enqueues
to a registered plum capability / MCP / bridge); LP no longer ships or directly drives the
python tool for this.
- quinn-specific screening_checks in quinn.db may be kept as cache or thin proxy; ct platform.db
(25437) is the canonical for the tenant's screening txns.
- Auth: service token (like MAC_SYNC_SERVICE_TOKEN) or quinn-sso context + tenant headers
(see PlatformAPIClient + TenantScope in ct's platform-api-client).
This keeps the v2 runtime for quinn alive while the generic multi-tenant screening + mrnumbers
lives in ct/application. No code vendoring across the v2/v4 boundary.
## Out of scope
- Per-screening-platform screens — defer to future `screening-lookup.screen.md` and `screening-history.screen.md` once specialist code starts.