The package manifest declares dsh.bundle.patch: ./cordis.patch.yml; installing it into a profile applies the patch rows over the profile composition. Credentials may use !!js process.env.… in the patch.

A code expires after the window the platform states, and an unscanned one is replaced automatically, so coming back later still finds a usable code; a refusal or a rejected request stops the flow with its reason and needs a restart to try again. To reset stored credentials, remove the lark-channel section from the settings document, whose path prints via the host settings surface; the settings layer overrides entry-config values while present.

The invariant companion row is not part of the default patch: the shipped web profile composes no invariants service, and a row waiting on an absent service fails the whole tree at boot. cordis.patch.yml documents the diagnostic-composition row.

Each message event is routed to the conversation sessionScope selects — the chat, one topic thread, or one sender within a chat. The session id is derived from that key (lark-<key>), so it is stable across restarts: the channel adopts a live agent, resumes a stored session, or creates one, in that order. Later messages become agent.followup() turns.

Group messages are prefixed with the sender name so the model can tell voices apart. Messages a bot authored, and mentions carrying no text, are skipped after the authorization check.

cot (default) shows the process the way the platform's own agents do — a native thinking-process message carrying reasoning, each tool call with an icon from its kind, and each result as a code block — while the answer is sent as an ordinary markdown message, which is where the platform says a final answer belongs. It needs a client new enough to render one (PC 7.70, mobile 7.74); stream keeps the whole turn in one typewriter card for older clients. showProcess turns the process off in either mode, leaving the answer alone, and hideProcessWhenDone lets the platform drop a finished process. When the platform refuses to open one, the answer still arrives.

Tool activity is labelled from each tool's own presentCall title, the label the host's own surfaces show, falling back to the model's description argument and then the bare name; its declared kind picks the icon.

A line beginning with / is a control, not a prompt — the host runs it without a model turn, so whatever commands the deployment composed — /compact, /plan, /permission, /export and the rest — reach the runtime instead of the model reading them as prose. /stop cancels the running turn (cancellation is an agent method, not a registered command) and /help lists what the chat accepts. An unresolved name is named as unknown with that listing rather than handed to the model.

On first use the channel also registers those commands on the bot itself (syncSlashCommands), so Feishu offers them when a user types /. The sync reconciles: it adds what the panel is missing and removes what the channel no longer offers, so the menu never offers a command that answers "unknown". A deployment that curates its own menu turns the sync off.

A screenshot is how someone shows a problem, so with attachImages on, images are downloaded and committed to the host attachment store and ride the user message as opaque references. Bounds come from that store: count, per-image and per-message bytes, accepted media types.

It is off by default because a route that cannot take images rejects the whole request, the image is in the session log by then, and every later request resends it — compaction included — so one screenshot ends that conversation for good. The host exposes no way to ask a route whether it accepts images, so a deployment on a vision route turns this on. An image that cannot be attached leaves a note in the text rather than vanishing — otherwise the model answers as though it had seen one.

approval/request questions for agents owned by this plugin become an interactive card with 允许一次 / 拒绝 buttons; the click settles the host outcome (allowed-once / rejected), the card is rewritten with the decision, and a withdrawn question settles cancelled. Questions about other agents delegate to the next composed answerer.

The listener is registered prepended, which is load-bearing when the Web app is composed alongside: its BFF claims every audited approval and never delegates, so in arrival order a chat-driven approval would surface in a browser nobody is watching while the chat waited forever.

The card shows the exact arguments the call would run, bounded, and renders every model-authored value (that command, the justification) as plain_text so neither can pose as the card's own markup. Whoever may drive a chat may answer its approvals — in a group, the room — and the settled card names who decided. Set approvers when an escalation should need a named human; a click from another chat never counts.

The platform owns the outer boundary, and this plugin narrows rather than gates. Who in the tenant can open a conversation with the bot at all is the app's visibility scope, set in the developer console — that is the authorization decision for direct messages, and duplicating it here would only add friction. A group is a room someone deliberately put the bot in, so the gate there is which rooms.

Every list is empty by default: senderAllowlist narrows direct senders, groupAllowlist narrows rooms, approvers narrows who may answer an escalation. A refused message is ignored silently in the chat and named on the operator console — answering would make the bot an oracle for who is allowed. The transport policy is narrowed to match whatever is configured, so restricted traffic stops before reaching this process.

ctx.userQuestions admits ONE provider per context, and with the Web app composed its BFF owns it and claims every agent-owned question — so ask_user_question and exit_plan_mode are denied per chat agent (denyTools) with a reason that redirects the model, plus a prompt sentence saying a question belongs in its reply. A chat reply already becomes the next turn, which is the native equivalent.

Each chat agent joins an agent preset (preset, default the roster's own default) inside creation setup. A deployment with a preset roster keeps every model-facing row on the agent plane, so an agent that joins nothing would reach the model with NO tools — and a model with no tools emits its native tool-call markup as plain text instead of calling anything. An unknown preset fails the creation and is reported to the chat rather than running a toolless session.

Chat sessions are accounted under the workspace record for their directory, registering it when none exists, because host grouping is an account rather than a cwd derivation — an unattached session shows under the GUI's Ungrouped bucket however its cwd reads. The session's cwd is the workspace's own canonical path, which is the value attachSession validates against. A registry that refuses the directory only costs grouping; the chat still runs.