fix: discover local human targets for explicit forwarding #70
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/c6a4b291-human-conversation-discovery"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
A role receiving agent text could explicitly forward it with
conversation send --conversation, but had no supported way to discover that local target: the CLI had no list command and the existing list route returned an empty array for role tokens. Head of IT consequently could not post Morten’s requested test text despite their conversation already existing.conversation list → existing own-role local targets → assignee list identifies person → explicit send --conversation <id>Reuse the existing authorized list route/query, filtering role tokens by both organization and authenticated role ID. Human callers keep their existing user filter. The response contains existing conversation metadata, without transcript text. Runtime help describes discovery and explicit selection; discovery neither starts a conversation nor forwards anything. No active human runtime is required.
Evidence
Merge danger
Door: two-way. No schema or credential change; revert removes discovery while preserving all accepted text.
Blast radius: app.
Rollback and verification
Owner self-review of
ca9d167against main57a858b8.Standards: 0 findings after independent parallel review of production/docs and final test hunks. CLI remains typed parse/call/print; service owns role/organization filtering; existing query/schema reused.
Spec: 0 findings. Discovery returns only existing local own-role metadata; human caller privacy stays unchanged; runtime requires explicit local target selection. Regression red on empty role listing; service/API16, CLI/runtime24 and revised full-flow3 pass. Both transports discover the target through authenticated API without pre-injected conversation IDs. Types/lint/deps/format pass.
Blocking gate: separate Security Engineer review of metadata discovery plus green #479/#480 before merge. Actual production discovery/forwarding remains unverified until the combined patch rollout. Revert/compatible v0.50.0 recovery retains all durable records.
Reviewed
ca9d167against merge-base57a858b8. Standards: 0 findings. Organization access is checked before AND-filtering organizationId and authenticated roleId; user-only privacy and system empty list are retained. Metadata includes IDs, timestamps, read state and archive count, without transcripts. No schema, secrets, image, privilege or exposure changes. Spec: 0 findings. Discovery is read-only; explicit send retains separate ownership authorization and wrong-role 404. Run credentials retain active-run validation; role credentials need no human runtime. Peer text grants no API authority; explicit forwarding remains an agent decision, not a server-enforced human approval. Inspected service/API/CLI and local/WebSocket full-flow tests. Independently verified CI 479 and 480 success at exact head through Woodpecker API; no local test rerun (dependencies absent). Live kubectl deployment image remains 0.50.0, so new behavior is not verified live. Owner must verify own-role discovery, person isolation, wrong-role 404 and explicit selected-text delivery after rollout. Roll back compatible code/image while retaining schema037, registry and all accepted/failed text; no data deletion. Standards: 0, worst none. Spec: 0, worst none.