# FluxDesk for AI agents You are an AI agent. This page tells you how to connect to FluxDesk and how to work in it. It contains no data. ## Connect - Protocol: MCP over Streamable HTTP. Endpoint: `https://my.fluxdesk.net/mcp`. - Auth: OAuth 2.1 with PKCE. Discovery: `https://my.fluxdesk.net/.well-known/oauth-protected-resource/mcp` → `https://my.fluxdesk.net/.well-known/oauth-authorization-server`. Register dynamically (`POST https://my.fluxdesk.net/oauth/register` with `client_name` and `redirect_uris`), then send your person to the authorize URL. They choose what you may do (只能查看 / 可以新建 / 可以代我操作), which Projects, and for how long. - No OAuth? Your person can make a Token for you in FluxDesk (我的空间 › AI 助手 › 已连接的 AI › 其他 › 开发者选项 › 使用 Token) and give it to you as `Authorization: Bearer `. Never print, log or store it anywhere else. - Scopes you can ask for: `read`, `write`. Your person decides. High-impact actions are never granted to agents. ## First call Call the MCP tool `fluxdesk_help`. It returns who you act for, what you can reach, every tool you can call grouped by object, and what to do next. ## Find help and manuals Call the MCP tool `help_search` with `query` and optional `language` (en, zh, zh-TW, ja, es). It searches the same platform-only index as Help and the command palette, by title, historical aliases and summary. Each result carries a Web route and a native Help route; no Project content is searched. ## Objects ### AI Project member One roster membership and action ceiling. Execution permission is the original requester intersected with current Project policy. Shared FluxDesk work uses its executing Project quota; a member's own AI uses its own subscription. Personal recent runs are self-only. Tools: `project_ai_member_list`, `project_ai_settings_get`, `project_ai_execution_invoke`, `project_ai_execution_stop`, `project_ai_execution_retry`, `project_ai_execution_recover`, `me_ai_get`, `me_ai_projects_list` ### Home library Home is the person's own Project; its document center owns saved copies. Favorites/stars remain pointers. home_library_save requires source_kind/source_id, idempotency_key and supports dry_run/expected_version. Organization and Project policy, current source readability and logical Home capacity all apply. Saved content survives loss of source; unavailable provenance is redacted. Only a currently authorized Home-bound assistant with E1 can read processing-eligible saved material; private exports give no AI processing grant. Cross-Project source and Home authority are never inferred. AI tools can create folders, move and tag with preview and current versions; permanent deletion and policy/capacity changes are human-only. File byte URLs use the bearer attachment endpoint. Tools: `home_library_save`, `home_library_list`, `home_library_search`, `home_library_get`, `home_library_create_folder`, `home_library_move`, `home_library_set_tags` ### Temporary discussion A hidden tmp Project: Free 24 hours, Pro and above 72 hours, fixed at creation in expiresAt; existing discussions keep their expiry, no Project memory or cross-Project retrieval. Use idempotency_key and dry_run. Project-bound credentials only preview/propose a new root; an authorized unbound credential or person creates it. Creator-only promotion/dissolution and explicit cross-Project saves are human-confirmation proposals; use ask_human. Joining a new Project never gives an assistant an implicit grant. D6: explicit saves belong to the destination Project and its retention; original text/author survive tmp deletion, and source becomes 来自已结束的临时讨论. Live source IDs additionally require read:chatter and the source Project in this credential. Chat info on Web/App holds members and lifecycle actions. For a creator-authorized rename, first read get_temp_discussion.version, then call rename_temp_discussion with expected_version, name, idempotency_key and dry_run. Applied/preview responses include previousName for an explicit versioned undo; persisted replays contain no names. get_temp_discussion.remainingMemberCapacity is the remaining human capacity from the Project entitlement; 19 is an invite batch bound, not a total membership cap. get_temp_discussion.saved_copies returns only independently authorized destination references with read:tasks/read:docs; source-bound credentials receive no cross-Project copy list. Tools: `create_temp_discussion`, `get_temp_discussion`, `rename_temp_discussion`, `promote_temp_discussion`, `dissolve_temp_discussion`, `copy_temp_discussion_message` ### Plan & usage plan_usage reads every resource entitlement, used/limit and whether enforcement is active. Participation is unlimited; the Project owner governs Project resources. New member/source/token/hosted-member additions and shared REST/MCP API rates are enforced by default. Storage/file/public-link/group-call/starter keys are deferred: inspect enforced rather than assuming a listed catalog value is active. Capacity refusals include *_limit_reached, used and limit; 429 responses include Retry-After. request_project_allowance uses idempotency_key and dry_run and the existing admin request queue, with AI attribution on behalf of the person. set_plan_entitlements is a platform-admin preview only; ask_human for a human governance change. No prices or purchase flow. Tools: `plan_usage`, `request_project_allowance`, `set_plan_entitlements` ### Project The boundary for collaboration, permission and audit. project_allowance reads plan/used/limit: Free 2 active owned Projects, Pro 30, organization unlimited unless overridden. Home, tmp and archives do not count. create_project requires idempotency_key and supports dry_run. project_limit_reached includes used and limit; request_project_allowance opens an audited admin request. Plan and slot grants are human governance; AI may preview only. restore_project previews a current-owner restore with the same slot check; a human confirms in Project settings. No payment flow. Everything belongs to exactly one Project; you only see Projects your person is a member of (and that this connection was granted). get_project_focus reads current authorized WorkItems needing attention: pending acceptance, explicitly open blockers, then overdue execution with source deadlines. It is read-only; partial is not a complete total, and the existing Project-token allowlist still applies. A Project installs modules (get_project_modules, including `work_time` for work-time statements); a tool on a removed module answers `module_disabled` — that is the Project's choice, not an error to work around. Tools: `project_allowance`, `create_project`, `request_project_allowance`, `restore_project`, `get_project_summary`, `get_project_weekly_digest`, `get_project_focus` ### WorkItem The one unit of work (legacy tool names say `task`). Has an owner, status, comments and delivery Evidence. Read before you write; prefer comments and drafts over direct changes. Tools: `list_my_tasks`, `search_tasks`, `get_task`, `add_task_comment`, `update_task_status` ### Milestone A dated stage of a Project with a verifiable result; WorkItems are linked to it and its progress is done/total of the linked work you can see. Read with `milestone_list` / `milestone_get`; the Project's owner / lead creates and edits (`milestone_create`, `milestone_update` with `expected_version`), and links WorkItems with `milestone_items_set` (e.g. {"project_id":"…","changes":[{"work_item_id":"…","milestone_id":"…"}],"client_message_id":""}). Every change takes a fresh `client_message_id`; try it first with `dry_run: true`. Archiving cannot be undone: ask your person first. Tools: `milestone_list`, `milestone_get`, `milestone_items_set` ### Signal Something that happened in a connected system or chat that may need attention. Signals are evidence, not work: turn one into a WorkItem only when asked. ### Decision A recorded human judgment with its reasons. Agents read Decisions; they never make them. Tools: `get_decision` ### Evidence Proof attached to work: what you did, links, files, test results. Every agent write should leave Evidence a person can check. Tools: `submit_delivery_evidence` ### Profile Your person's own 编辑主页 and 合作设置: name, the profile fields and the three ways to work with them (委托 · 预约 · 留言) plus 可约时间, each 公开 or 仅自己. Change it only when your person asks; send an idempotency key and try `dry_run` first. Tools: `get_my_profile`, `update_my_profile_section`, `check_my_profile_operation` FluxDesk ID (the @ handle): `get_my_profile` returns `fluxdesk_id`; change it only when your person asks, with `set_my_fluxdesk_id(fluxdesk_id, idempotency_key, dry_run)` — `dry_run: true` checks availability without writing. 6–20 of a–z 0–9 _, starting with a letter; once per 30 days; old IDs keep resolving to the same person. To mention someone, write `@`; earlier handles in old messages still resolve. ### HumanRequest A typed question to your person (`ask_human`) when a judgment is theirs: direction, authorization, acceptance, publication, anything high-impact. Not a notification channel. Tools: `ask_human`, `agent_get_question` ### EntryDomain A domain that opens FluxDesk: an organisation's own domain or a platform entry such as app.fluxdesk.net. Platform metadata only, never Project content. An organisation's admin requests and checks its domains; turning a domain on or pausing it is an operator's call — you may only preview those two (dry_run). Tools: `entry_domain_list`, `entry_domain_request`, `entry_domain_verify` ## Rules - A registered Project AI acts only inside its registered Project, even when a legacy credential has no Project columns. Its provisioner's super-admin role and historical platform-triage grant never extend its reach. Legacy pool feedback and every other Project are out of scope. Refusals return out_of_scope with next_tool explain_ai_access and metadata-only connection audit; do not retry with a forged Project or requester, and do not use ask_human to get past the Project boundary. proposal_only and governance_human_only need a person: next_tool names the tool you can propose it with, and next_tool_arguments what to pass, or it is null with reason no_proposal_tool and you tell your person directly. An identity that no longer resolves answers next_tool null with reason identity_unresolved, because it can call no tool: a Project admin or its owner checks its membership and connection. - For platform feedback use your person's own unbound personal OAuth connection: connect the current site's /mcp endpoint, let the person choose All projects and Take notes, and complete browser consent. No token copying. Project policies still apply to Project content. Use list_feedbacks(platform_only=true), then get_feedback(feedback_id) for platform triage; Intake access is limited to authorized feedback objects. set_feedback_status notes and add_feedback_comment share attribution: the person with an AI-assisted marker for member-own AI, or the Project-qualified AI for a Project member. Always show the owner with any AI name. - The human owner can read get_my_ai_profile(project_id) and change their own Home AI name or speaking style with set_my_ai_profile(expected_version, idempotency_key, dry_run). These preferences grant no Project access. AI credentials are refused even for preview; ask the person instead. - get_my_ai_member_command_result reads only your recorded add/remove/role result in the source Project under live Project membership and exact caller ownership. A missing receipt stays unknown; never resend it. - When this session offers home_library_read_file, use a saved Home item id and one attachment id returned by home_library_get. Read-only chunks are at most 64 KiB; continue with nextOffset. Each chunk rechecks the same own-Home principal, grants, E1 and processing restrictions. A refusal never permits a source-attachment or browser-cookie fallback. - AI membership, roles, organization defaults, settings, quota, connecting clients and personal AI grants are HUMAN ONLY, including previews. Never use a machine credential to authorize yourself; propose it with the tool next_tool names, or tell your person. Human writes use an idempotency key and dry_run. - Hosted-node execution binding rollout defaults OFF. When required, use the exact live execution proof for every model attempt and job/content call, with a fresh logical call key per paid attempt. A replay never buys a second request. A refused call cannot fall back to an upstream key. Stop the actual process before signing its nonce-bound acknowledgment; uncertain paid observations remain held independently. - me_ai_client_attach is a human confirmation that another owned client is the same selected AI. Clients share one person's Project grant and generation, not each other's scopes. Disabling a Project, leaving, replacement or E1 off revokes access; re-enable never revives old keys. Fresh external recovery is target-bound primary-browser consent and returns a new Project-only key once; old keys and OAuth refresh tokens stay revoked. - Project owners can use preview_project_retention for aggregate capped retention counts without writes. Retention deletion is operator controlled; AI cannot execute it. Ask your person for high-impact changes. - You act FOR one person, never AS them. Every write is recorded as ' on behalf of '. - AI execution authority is the initiator’s current permissions ∩ the Project cap for this AI ∩ this AI’s own grant; re-check on every read, start, retry, resume and write. The initiator is the person invoking this execution (scheduled task: its creator), never the adder or runtime provider. - MCP is the system-call interface. New or changed business writes require idempotency and a non-writing dry-run; existing tools offer these only where their input schema declares them. - Every call is checked on the server against your person's live Project membership and permissions. A refusal is final for that call; do not retry it with other arguments to get around it. - High-impact actions (accepting work, approving releases, publishing to people outside the Project, changing members or permissions) are never yours. Ask your person: tell them in your reply, or use `ask_human` when you hold it. - Never copy content from one Project into another Project or into your own memory. - Read before you write. Prefer a comment or a draft over changing someone else's work. - When someone @mentions your person in a conversation, `list_chatter_messages` returns `mention_message_id`: the earliest unread message there that mentions them (null when none). Use that id to identify the mention; it may be outside the returned page. Reading marks nothing read. - Only a Project AI takes part in conversations: `get_chatter_channel_members` lists Project AIs only, each with `owner_label` and `mention_handle` (write `@` to ask it). A personal assistant is its owner's delegate, never a conversation member: an @ of it in a message wakes nothing and the message is sent as ordinary text. ## AI content permission Use `get_project_ai_content_policy` to read whether this Project may send content to its approved model provider. Missing organisation policy means off. Project administrators can turn it off or follow their organisation; organisation administrators govern the organisation setting. Changes are versioned, audited, and accept an operation id and dry-run preview. An AI cannot apply these decisions. No training-use guarantee is asserted by this policy. ## Identity and login devices get_my_linked_identities_and_sessions reads only your own linked identity and login-device metadata; no email, provider subjects, proofs or secrets. preview_my_identity_session_revocation proposes a version-bound device revocation; the person executes it. preview_legacy_test_account_merge is super-admin operations only, dry-run first and audited; an unavailable source export is refused. It proposes the fixed six-account test batch. apply_legacy_test_account_merge runs that one batch only (apply, pre-activation rollback or split) after your own dry run of the same operation, bound to the reviewed mapping and manifest digests, idempotent and audited; AI can only dry-run it and propose. run_identity_bootstrap (super-admin operations, before the switch) registers every existing active User of this cell in the identity directory so turning global identity on signs nobody out; test, system and inactive Users and the six reviewed Strict accounts are never registered. dry_run=true runs the exact writes and rolls them back (counts, collisions, coverage, plan digest; never an email or id list); a real run quotes that plan digest, is idempotent, batched and audited, and operation=rollback removes only the accounts it created and keeps any already in use. AI can only dry-run it and propose. Global identity is off by default; the deployment turns it on in the coordinated cutover. Sign-in stays on my.fluxdesk.net; native Apps never follow entry domains. ## When a call is refused - Missing scope: the error names the scope. Ask your person to reconnect you with that access. - Expired connection: ask your person to reconnect you (one tap in FluxDesk). - Suspended connection: an administrator paused it. Tell your person. - Not found / not a member: you cannot reach that object. Do not guess other ids. Project templates carry function definitions; permission-level names stay fixed. Use list_project_functions to read them. set_member_function and manage_project_function change a member's real permissions: a person's own session previews with dry_run and confirms with the same idempotency key and preview digest; an AI assistant receives proposal_only and asks the person through ask_human. Project invitations through create_my_invite accept functionId, idempotencyKey, dryRun and expectedPreview. ## Feature catalog (功能目录) get_feature_catalog(project_id) lists every first-party feature of a Project with module_id (the same ids as get_project_modules), five-language labels and summary, kind fixed|optional, surfaces, overview_card_ids, command_ids, dependencies, data_classes, retention_adapter_id, enablement_requirements, admitted, and per Project installed, state_version, navigation_version, overview_version, availability_reason and history_target. Only admitted features (known id, registered deletion adapter, MCP parity) can be added; new features default to off. get_feature_catalog(preview={module_id, enabled}) returns the plan without writing: appears/disappears (pages, create entries, Overview cards, actions), stops_new_writes, history_still_handled, data_kept (a count only when the caller sees every record), required_adjustments and plan_digest. Dependencies are never added or removed for you. A person applies with set_project_module_enabled(dry_run=false, expected_version, expected_plan_digest, operation_id); a changed plan answers version_conflict with the fresh preview; after an unknown result use check_project_module_operation. Removing keeps every record; adding again continues with them. An AI never adds or removes a feature: its preview carries a proposal (requires_human, proposed_by " 代 ", next_tool ask_human). ## Project templates v2 Read `list_project_templates` for the complete catalogue: blank first, ten presets, `sections` (builtin/organisation/mine), `tab_names`, and Overview cards with resolved titles. `get_project_template(template=...)` reads one exact visible version. `create_project(template=...)` copies that version and returns the applied composition. Use `create_project_template` to clone a readable template with allowlisted `fields`. The existing `manage_saved_project_template` is the update/archive action (action=update or archive); update creates an immutable new version. These writes require `idempotency_key`; `dry_run=true` returns the would-be manifest without rows. Organisation publish/default is separate. Templates contain configuration, never Project data, members or grants. AI attribution always includes its owner. For `switch_project_template`, review Overview additions/removals/reordering/retitling; customised layouts default to `apply_overview=false`, and replacement requires the confirmed preview composition. A member’s personal Overview view always wins. `security_level` is a typed policy hook; null keeps current behaviour. ## Platform feedback in a Project When Project intake is enabled, platform_only includes the FluxDesk Feedback Project and remaining pool rows. mine lists only your person's own reports (open by default; scope=all includes history). Requesters can read and reply only to their own reports; this grants no Project content, WorkItem links, team notes or CC list. Team access needs live Project membership and the Project's AI content policy and grant. triage:feedback, previously ‘Also handle platform feedback’, remains the handling scope for Projects your person belongs to; it grants no membership. The monitor keeps list_feedbacks → get_feedback → accepted → in_progress → add_feedback_comment(mark_shipped=true) → read back, and may correct its own reply with update_feedback_comment. A platform role without membership grants no intake content. Project-bound credentials stay inside their own Project and cannot use platform_only or mine. ## Project templates v2 list_project_templates returns ten presets (blank first), sections builtin/organisation/mine, ordered tab_names and Overview cards with resolved titles. get_project_template(template=...) reads an exact visible version. create_project(template=..., security_level=standard|strict) copies the configuration and security level, and returns the applied values and ceiling clamps. Omitted security_level uses the template field (null = standard); policy_template remains an alias and conflicting values are refused. create_project_template clones with allowlisted field edits; manage_saved_project_template action=update makes a new version and action=archive archives it. Writes require idempotency_key and support dry_run without rows. Template edits never change existing Projects. switch_project_template previews Overview differences; customised layouts default to apply_overview=false and replacement requires the confirmed composition. Member personal views always win. Templates contain no Project data, members or grants. AI attribution names its owner. ## Evaluate a delivery A Project owns each rubric version. A criterion has a stable identifier, name, description and either a numeric scale or a finite set of options, with optional anchors. Evaluate this delivery without profiling or comparing a person. ## Prepare with an assistant Use `rubric_list` and `rubric_get` to read definitions. Project Owners and Leads prepare new versions or archive with `rubric_upsert`; `rubric_bind` pins the version used by a WorkItem. Every write requires `schema_version`, `scope`, `expected_version`, `idempotency_key` and `dry_run`. Preview first and retry the same request safely. `assessment_propose` stores only an AI suggestion: a value or not-rated, a reason and Evidence references for each criterion. Suggestions name the assistant's owner or Project and the initiator, and expire no later than their sources. `assessment_get` reads the rubric, human judgement receipts and separate suggestions for one currently readable WorkItem. A suggestion is never applied automatically. ## Authorship and retention Only an authorized person submits a formal Assessment through acceptance. An executor cannot assess their own delivery; a generic MCP token cannot write a formal Assessment. Corrections append a receipt pointing to the previous one. A score never changes WorkItem state or replaces the acceptance outcome. There are no totals, averages, thresholds, per-student views or rankings. A used version is immutable; changes create a new version. Archiving stops new use. Forced purge requires a human preview of affected bindings and removes derived scores. WorkItem, delivery-round and Project erasure removes scores and snapshots with the source. Templates carry definitions only, without people or scores, copied into the target Project's own version. ## Related [Delivery and acceptance](/help/daily-collab/review-queue) ## Use criteria on a WorkItem Beside the completion criteria, choose **Use evaluation criteria**. An authorised reviewer can pick an exact Project rubric version, preview it, and confirm. Project Owners and Leads can also create a definition here; after creation, select its version to bind it. The bound version stays explicit when the Project creates a newer version. After recording the human acceptance decision, choose **Record human judgement**. Enter a value or **Not rated** for every criterion, explain each judgement, and select the relevant Evidence. Preview the entries, then confirm. The App shows the same rubric and Evidence and accepts the same human judgement. Evaluation does not accept the WorkItem or change its state. AI suggestions remain separate. Their assistant owner and initiator are shown; nothing is filled automatically. Corrections use **Append a revision**, which creates another receipt rather than replacing the original. Each receipt retains its own rubric definition, human author and time. ## Definitions in templates Project and WorkItem template editors can include an optional pure rubric definition. They copy no people or assessments. The new Project owns the instantiated version. **Writing rubric example** is an optional four-criterion starter, from 0 to 9 in steps of 0.5, with no total. It is not an official exam scale. ## My work and conclusions my_records_list / my_records_include / my_records_organize / my_records_remove / my_records_export are self-only. owner derives from the session; never send user_id. Include only a WorkItem you explicitly execute/delivered, with schema_version=my-records/1, scope=self, expected_version, idempotency_key and dry_run. Home keeps pointers and personal folder/tags, never copies works, comments or scores. Every source read/open/export/AI use rechecks access; leaving revokes at once. source_unavailable means 暂时无法读取 and contains no stale conclusion. Export only proposes one disclosure for the owner's Web/App confirmation under source policy. Project assistants cannot traverse personal indices. No totals, trends or rankings. Acceptance receipts only; rubric support follows RECORD-C. The Web /me/my-records and App /my-records views expose explicit opt-in, folder/tags, removal and owner-confirmed export; the export proposal returns confirmation_href and confirmation_app_path. A link alone never confirms a disclosure. Read /agents.md?article=daily-collab/my-records for the full contract. ## WorkItem forms WorkItem forms: workitem_form_get reads the exact bound definition and values under live WorkItem visibility (including participants/self-only). Human Project administrators use workitem_form_definition_upsert and workitem_form_bind; AI governance is proposal only. workitem_fields_update replaces the WHOLE form within the initiator's write rights, AI cap and grant. Supported kinds: date_range (inclusive calendar dates plus IANA timezone, no UTC conversion), choice, exact decimal-string number, and one live Project member ID. Read person values return member_id/label/status; submit only the active member_id string. Departed members become tombstones and cannot be selected again. Write envelope: schema_version=workitem-fields/1.0, project_id, expected_version, idempotency_key, dry_run. expected_version is the binding version for values/binds (0 for first bind), the latest definition version for definition writes (0 to create). Draft may omit required fields; stage=submit validates all. Preview writes zero rows, audits or queues. AI previews require an existing Project AI session; use project_ai_session_open explicitly first, because a preview never provisions a credential. Retry the same payload/key; workitem_fields_check_operation resolves unknown outcomes. Definition changes create new immutable versions; rebinding is explicit, with whole-form values and a preview. To upgrade an existing binding, pass the preview plan_digest as expected_plan_digest with the same request and key. Templates carry pure definitions only; copies belong to the target Project, with provenance and no remote link, source people, values or grants. A person default may only be initiator. Budgets: 32 fields, 50 choice options, 64KiB each for definition/values. No field ACL, formulas, aggregation, formal assessment or acceptance authority. Source deletion hides forms; purge cascades values, bindings and source-owned receipts. The form editor is a subsequent delivery; this contract is available through MCP. ## Uploaded video files and forwarding Uploaded video files have no duration limit and use the existing 50 MB file cap. App camera recordings remain limited to one minute. Use prepare_attachment_upload and the existing attachment finalize/read tools for supported file transfers. To forward an existing chatter message, call add_chatter_message(channel_id, forward_message_id, idempotency_key, dry_run=true) without body, reply or mentions. For a Project private target, also pass private_recipient_id; the normal recipient authority applies. Preview writes no message; apply with dry_run=false and retain the UUID key for retries. Forward requires read:chatter plus write:chatter, current source read and target posting authority, and the same Project boundary, scan and retention rules as Web/App. MCP cannot republish private content; a private-source preview reports requires_human_disclosure and a person completes it in the UI. A forward never re-pings source mentions. Machine forwards supply matching project_id and keep existing Project AI/content-policy/grant admission. ## AI access refusals AI access refusal codes distinguish never granted (personal_toggle_off, never_set=true) from an actual grant_revoked. The owner grants at /me/agent with me_ai_projects_set (human only). member_own_ai_off includes source; content_policy_off identifies E1. explain_ai_access(project_id, tool, arguments) previews the same call, read-only, including connection/selection and private-content barriers. Non-members receive not_found without settings. See /help/ai-platform/ai-access-errors. No grant request or automatic approval is created. ## Own account reads Your own unbound connected or legacy credential may read your account and relationships with the declared scope, without a Project grant. find_messageable_people(query), read:chatter, finds current friends and shared-Project people using Web Start chat readers and returns only person_id/name, up to 50. Contact availability and shared-Project precedence match Web Start chat. AI Project lists omit descriptions. AI DSR reads contain status/deadline metadata only; response notes and export links remain outside this opening. Project/execution identities and platform roles gain no authority over another account. Private reads and sends, inbox and Project content retain their checks. explain_ai_access with the original tool/arguments uses the same declaration. See /help/ai-platform/own-account-reads. When Project intake is enabled, platform_only includes the FluxDesk Feedback Project and remaining pool rows. mine lists only your person's own reports (open by default; scope=all includes history). Requesters can read and reply only to their own reports; this grants no Project content, WorkItem links, team notes or CC list. Team access needs live Project membership and the Project's AI content policy and grant. triage:feedback, previously ‘Also handle platform feedback’, remains the handling scope for Projects your person belongs to; it grants no membership. The monitor keeps list_feedbacks → get_feedback → accepted → in_progress → add_feedback_comment(mark_shipped=true) → read back, and may correct its own reply with update_feedback_comment. A platform role without membership grants no intake content. Project-bound credentials stay inside their own Project and cannot use platform_only or mine. For your own platform feedback outside a Project key's selected Projects: This connection only covers its selected Projects and cannot read or reply to platform feedback. Switch to your own personal connection with no Project binding; a Project key cannot be used here. You can also read and reply in My feedback. ## Feedback project Platform feedback can enter **FluxDesk Feedback**. The person submitting is the requester of that one record, not a project member. They can read and reply to their own feedback; they cannot read other requests, members, project chat, documents or linked work items. A platform role alone grants no project content access. ## Create and enable The Owner signs in again as a super administrator, then opens [Management settings → Feedback project](/settings/feedback-project) within 15 minutes. Choose the organization, select **Create**, preview, then **Confirm change**. Creation leaves new feedback intake **Off**. Open the created project and add the real coordinators as project members using the existing membership controls. On TEST first, select **Send new feedback to this project**, preview, then **Confirm change**. After TEST acceptance, repeat manually in each PROD cell. There is no automatic enablement or backfill. Existing feedback is unchanged. Submit as a non-member test account: find the record in **My feedback**, confirm a second non-member cannot read it, and confirm a project coordinator can read it. The requester must see no project or other requester content. ## Submitting The FluxDesk team will see what you attach. Review screenshots and remove private content before sending. New feedback is limited to 10 per hour and 30 per day; accounts younger than 24 hours have 3 per hour. A requester may add 30 replies per item per hour. A project owner or coordinator can mark harassment and block or unblock the requester; existing items stay readable to that requester. An Agent submits on behalf of its owner and shows both names. Project-bound project assistants cannot submit platform feedback. Anonymous identity stays masked; account erasure retains UUID attribution and shows only a deleted-account owner and a generic Agent; anonymous unlink removes the Agent pointer. Withdrawing new feedback remains the undo action. For an authorized human CLI session, `platform_feedback_project_get`, `platform_feedback_project_ensure` and `platform_feedback_intake_set` use `schema_version=platform-feedback/1`, cell scope, `expected_version`, `idempotency_key` and `dry_run`. AI enablement returns `proposal_only` with `ask_human`. A primary browser session bound to the human CLI credential must be younger than 15 minutes. `create_feedback` preview returns destination, consent and attachments without writing; enabled submissions require `schema_version=feedback-create/1`, `scope={kind:platform}`, `expected_version=0`, and an idempotency key. Project owners/coordinators use `platform_feedback_requester_block_set` with project scope and the preview version. Once the intake contains platform records, disabling requires the later migration/rollback procedure; the switch refuses to strand requesters. Existing pool records and backfill are separate operations. ## Related [Submit feedback](/help/operations/platform-feedback) · [Management settings](/help/operations/admin-settings) ## Project rule commands Canonical Project rules (A1 MCP, editor follows later): project_rules_command_set defines/edits one registered command with schema_version=project-rule-command/1.0, project_id, expected_version (0=create), idempotency_key and dry_run. Definitions/copies start paused. project_rules_command_state is human-only enable/pause/take_over; takeover creates a version, keeps original creator history, and remains paused. AI can only return no-write definition proposals; canonical details/simulation/receipts presently require human management credentials. project_rules_command_get lists registered command IDs and scoped rule definitions; project_rules_command_simulate previews at most 200 visible events from 7 days without writes; project_rules_command_runs returns minimal receipts and proposals under current WorkItem visibility. Field trigger workitem.fields_updated uses field_ids and typed-literal equality only. First automatic adapter workitem.fields_update replaces the complete form on one scoped WorkItem, with typed_args work_item_id/values/stage=draft; scope lists all form field IDs. Only registered low-risk reversible commands can mode=apply. High-impact operations require mode=proposal, carry exact digest/target version/Evidence refs/expiry, and a human applies via the domain command with fresh authority. No arbitrary tools, scripts, schedules, formal scoring or automatic governance. Attribution: 规则「名称」代 创建人. Leaving/demotion pauses; resume never replays. Current creator rights, feature authority and exact approved scope are rechecked in the mutation transaction. Limits: 20 rules/Project, 20 admissions/hour/rule, 100/hour/Project, causation depth 8. Durable reservation is not an exactly-once completion claim; applied requires a persisted domain receipt. Source purge removes derived rule data; retention is inbox 8d/runs 90d/operations 30d. Repeat the original key/payload after unknown outcomes; conflicting reuse is refused. ## Anchored annotations # Anchored comments An annotation uses a WorkItem or document comment; it creates no separate work record. Text anchors retain a source version, a Unicode range and a quote of at most 200 characters, even for longer selections. Media anchors retain one immutable attachment version and a start time, with an optional end time. The file must pass its safety check and have a server-verified duration. No viewing or playback tracking or automatic transcription is added. ## Use it on the web and in the App On a work item or document page, choose **Annotations** to open the annotation page. - Text: on the web, select text in the original and choose **Annotate**. In the App, touch and hold the original to select text, then tap **Annotate**. - Recordings and videos: pick a file under **Recordings and videos**. On the web, choose **Annotate here** next to the player; in the App, pause and tap **Annotate this moment**. Only the moment you pick is saved. - Write your annotation, choose **Preview** to check the snippet or moment, then **Post annotation**. Nothing is sent before you post. - In the **Annotation list**, choose a quote or moment to go back to that text or that moment in the recording. Screen readers can move through the list item by item. - You can **Resolve** or **Reopen** your own annotations, and **Locate again** after the original changes. ## Use the AI tools Call `annotation_list` with `schema_version: "annotation/1.0"`, `project_id` and `parent`. Optional `source_ref` selects the parent's body, a delivery text comment or a supported audio/video attachment. It returns the current canonical text channel and version, or verified duration; `media_sources` lists the parent's recordings and videos that can be annotated. `add_task_comment`, `update_task_comment` and `hide_task_comment` accept an optional `anchor`. Documents use `add_doc_comment`, `update_doc_comment` and `hide_doc_comment`. Anchor writes require `schema_version`, `scope.project_id`, `expected_version`, `idempotency_key` and `dry_run`. Use version 0 for a new annotation and the latest read version for a change. Preview first: it returns the exact snippet or moment and sends no comment or notification. Applying rechecks access and versions. Retry the same operation with the same idempotency key. ## When the source changes Text positions count Unicode characters, preserving emoji and line breaks. `annotation_reanchor` moves a text annotation only when the entire original selection has one exact match. Repeated or edited text stays attached to its old version and needs relocation. Neither a model nor an assistant guesses a location. Replacing an audio/video file never moves old comments to the replacement. `annotation_resolve` resolves or reopens the discussion; it does not accept or assess the WorkItem. ## Access and deletion The reader must be allowed to read the parent, the specific source and the comment body. Search and notifications use the same intersection. Shared documents cannot carry quotes from private WorkItems. Hidden or expired sources immediately hide annotations and snippets. Permanent source deletion purges the anchored comments, replies and quotes. AI attribution names the assistant's person or Project owner and the initiator. Pinned snapshots, formal questions, saved temporary copies and delivery Evidence retain their own contracts. They cannot be converted into anchored discussion, and an annotation cannot be promoted into one of these records. Create a separate record or annotate the supported original content. ## Related help [Documents](/help/daily-collab/collaboration-documents) ## Source message recipients ## Enable it for the source A Project manager or this source’s eligible steward opens **Settings › Connections › External systems › source details** and turns on **Allow messages to choose recipients**. New sources start with it on. Sources that already existed keep it off until a manager or eligible steward enables it. With it off, `recipients` is ignored and the saved handling rule continues to apply. ## Set recipients in each message Add `"recipients": [{ "email": "member@example.test" }]` to a generic notification or a version 2 envelope sent to the Project source. Up to **50 entries**, including duplicates, are accepted. Addresses are trimmed and matched exactly without case sensitivity. Duplicate addresses notify once; partial names and fuzzy matching are not supported. Only **active members of that source's Project** match. Unknown addresses and accounts outside the Project both return `not_a_project_member`, receive nothing, and are never added as members. The response's `delivered` means the member's message was admitted to the notification pipeline; it does not prove a device alert, reading or confirmation. Mute and each person's delivery settings still apply. ## Zoho example Map the Zoho record's account email to the intended member's **FluxDesk sign-in email**, then put that value in `recipients[0].email`. If the two addresses differ, maintain an explicit mapping in Zoho. Do not send a Zoho user ID as an email. The older `recipient_email`, `recipient`, `recipient_hint` and `target_email` fields do not select recipients on a Project source. For a message-selected confirmation rule, the first matched member confirms. For a fixed rule, the fixed person confirms. Draft recipients become watchers upon publication; none of these choices expands Project authority. [See the complete API request](/help/external-systems/request-examples) ## Where messages appear Open the source Project’s Overview. External sources near the top shows the title, summary, source and time of messages delivered to you. Open a row to read its full content and mark that message seen; opening the overview alone does not mark external messages seen. You can also use Workbench › Recent activity › All or External sources. In For me, tap the compact new external messages line to switch to External sources. For me contains action items only; ordinary notifications do not enter it. Messages stay in your recipient notification records for that Project. Recent pushes in the source details checks receipt. Beside the Project in the menu, a blue number counts the external messages you have not read, apart from the amber count of work waiting for you; tap it to open External sources showing unread messages. Use Mark as read on one message, or Mark all as read. Read state is kept on the server, so every device agrees. To choose how a Project or a source reaches you, open **Settings › Notifications › Alert settings › Project notifications**. Only recipients chosen by the rule, or the members the rule notifies, see a message. Opening a message marks that exact update seen and clears its new-update count. Settings remains the place to configure the source; a record-only event does not become a delivered update. In the App, tap a message to read its native detail. The original-record action offers a computer link; it does not open a browser in the App. ## Account away period Use get_my_away to read your own revision. set_my_away and clear_my_away require schema_version=1, scope=self, expected_version, idempotency_key and dry_run. Dates are inclusive in the owner's IANA zone; returns_on is the next local date. Only a personal session writes. get_away returns only current away/return-date and a delegate where the caller, owner and delegate share the Project. No note, source, reason, kind, revision or history is shared. Ordinary alerts are muted by default; p0_urgent WorkItems and direct calls are exempt from away muting. Preview writes nothing. See /agents.md?article=daily-collab/away. ## Workbench seen state Workbench: list_my_workbench_updates and get_colleague_status return exact id/version pairs. Personal credentials with write:inbox can call mark_workbench_updates_seen with those pairs, a UUID idempotency_key and dry_run=true to preview. Applying advances only your private group watermark through the authorized update: older updates in that group count as seen too. An older link never moves the watermark back. 看过最新的就算看过这一组. This does not handle decisions or read conversations. Project-bound credentials cannot use this account-wide marker. ## Project source messages and member recipients /help/external-systems/project-first New integrations are Project sources (Home is a Project). POST /api/signals/inbound accepts optional recipients:[{email}] on generic notifications and v2 envelopes; at most 50 submitted entries, trimmed case-insensitive exact sign-in email match among active source-Project members only. Unknown and non-member addresses both return not_a_project_member; matched entries return delivered (notification-pipeline admission, never proof of device delivery/read/action; mute and delivery preferences apply). Never adds members or widens authority. allowMessageRecipients defaults ON only for newly minted sources; existing sources stay OFF until a manager or eligible source steward opts in. OFF ignores recipients. get_project_source_recipient_settings reads; set_project_source_recipient_settings requires idempotency_key and expected_version, supports dry_run and optional confirmation_rule:{id,mode:fixed|message}. signals_inbound_preview is read-only, available to Project managers or the eligible source steward and does not notify or reserve quota. A message-selected confirmation uses the first matched member, with no Owner fallback when none match. A fixed confirmer stays fixed. Work item drafts carry matched members as watchers (cc), rechecked at human publication. Recipients never become members or assignees automatically. Personal modes 1-3 and personal tools-token bulk are legacy for existing senders only; no new personal inbound Tokens. Do not extend those routes. New integrations always use a Project source. Map the Zoho account email explicitly to the recipient's FluxDesk sign-in email and send it in recipients[].email; do not use recipient_email or a Zoho user ID. Delivered Project source messages appear in Project updates and list_my_workbench_updates(category=external), with readable title/summary/severity and an exact event link. Opening uses the canonical workbench seen command. Human-bound source stewards/managers can read get_project_source_rule_confirmers and preview or apply set_project_source_rule_confirmers with every selected eligible Project member, expected_version, idempotency_key, and dry_run (default true). AI governance writes remain forbidden. ## Connection stewardship A Project source is configured by its owner/lead managers or its current eligible live member steward. Request approval assigns the requester. Stewardship never grants Project-wide settings, another source or cross-Project targets. get_project_source_configuration reads the current version; configure_project_source_details edits details or transfers stewardship (manager only); configure_project_source_rule edits category, arrival rule and Project-member targets. New writes require expected_version and idempotency_key and default to dry_run. Connection governance uses person credentials; AI proposes via ask_human. list_platform_connections is platform-admin metadata only: creator, steward, approver and retained per-connection usage observations with partial coverage; never bodies, addresses, keys, routing content or per-person totals. See /help/external-systems/source-token and /help/external-systems/troubleshooting. ## Project and default group chat names The default Project group chat always uses the current Project name. To rename it, use rename_project(project_id, name, expected_name, idempotency_key, dry_run). Preview with dry_run=true, then apply with the same expected_name and an idempotency key. Project editing permission is required and rechecked. The narrow scope write:projects:rename (or its parent write:projects) is required; AI callers additionally need manage, a live grant and enabled AI content access. Existing credentials need an explicit scope update or write reconnect. Retry the same request with the same key; rename again to undo. Other channels keep their own names.