docs(feishu): remove nonexistent disabled value from dmPolicy options

[wm0018]

What Problem This Solves

docs/channels/feishu.md line 47 lists "disabled" as a valid dmPolicy value, but the Zod schema only accepts open, pairing, allowlist. Users who configure dmPolicy: "disabled" will hit a schema validation failure at runtime.

Evidence

Schema — disabled is not a valid dmPolicy value

extensions/feishu/src/config-schema.ts:14

const DmPolicySchema = z.enum(["open", "pairing", "allowlist"]);

Only three values are valid for dmPolicy. "disabled" is not in the enum.

Schema distinguishes DM policy from group policy

extensions/feishu/src/config-schema.ts:14-18

const DmPolicySchema = z.enum(["open", "pairing", "allowlist"]);
const GroupPolicySchema = z.union([
  z.enum(["open", "allowlist", "disabled"]),
  z.literal("allowall").transform(() => "open" as const),
]);

groupPolicy supports disabled; dmPolicy does not. The doc incorrectly applied the group-policy value set to the DM-policy field.

Runtime uses dmPolicy: "disabled" only as an internal routing sentinel

extensions/feishu/src/policy.ts:182,212

// Group message ingress routing — internal sentinel, not user-configurable
dmPolicy: "disabled",
groupPolicy,

The literal "disabled" is hardcoded internally to prevent group messages from falling through to DM routing. It is never read from user config.

Validated config reference — dmPolicy has no disabled entry

The config schema validation at extensions/feishu/src/config-schema.ts:326 only handles dmPolicy === "open" for the wildcard check; validation passes through silently for pairing and allowlist:

if (value.dmPolicy === "open") {
  // checks allowFrom includes "*"
}

There is no validation branch for disabled because the schema rejects it before this code runs.

User Impact

Users who configured channels.feishu.dmPolicy: "disabled" based on the old docs would encounter a schema validation failure. To disable DMs, use dmPolicy: "allowlist" with an empty allowFrom array.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed June 28, 2026, 11:15 PM ET / 03:15 UTC.

Summary
The PR removes one Feishu channel documentation bullet that lists dmPolicy: "disabled" as a valid direct-message policy option.

PR surface: Docs -1. Total -1 across 1 file.

Reproducibility: yes. Source inspection shows current main and v2026.6.10 document dmPolicy: "disabled", while the Feishu schema accepts only open, pairing, and allowlist for user config.

Review metrics: 1 noteworthy metric.

• Documented config values: 1 invalid value removed. The changed line is an enum-style Feishu dmPolicy option, so maintainers should compare it against the plugin schema before merge.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🌊 off-meta tidepool
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• none.

Risk before merge

• [P1] The PR is intentionally narrow; the shared setup wizard still appears able to offer and write dmPolicy: "disabled" for Feishu, which should be handled as separate setup/schema work if maintainers want the wizard aligned too.

Maintainer options:

1. Decide the mitigation before merge
   Merge the docs correction, then track the existing setup wizard/schema mismatch separately if maintainers want Feishu setup to hide disabled or intentionally support it.
2. Pause or close
   Do not merge this PR until maintainers decide whether the risk is worth taking.

Next step before merge

• [P2] No repair lane is needed; the PR is a narrow docs-only correction and routine maintainer review or merge is the remaining action.

Security
Cleared: The diff only removes one docs bullet and introduces no dependency, workflow, secret, network, or executable surface.

Review details

Best possible solution:

Merge the docs correction, then track the existing setup wizard/schema mismatch separately if maintainers want Feishu setup to hide disabled or intentionally support it.

Do we have a high-confidence way to reproduce the issue?

Yes. Source inspection shows current main and v2026.6.10 document dmPolicy: "disabled", while the Feishu schema accepts only open, pairing, and allowlist for user config.

Is this the best way to solve the issue?

Yes for the docs mismatch: removing the invalid value is the narrowest maintainable correction. It does not solve the separate pre-existing setup prompt inconsistency, which should be handled in a follow-up if desired.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 2001b15f5b92.

Label changes

Label justifications:

• P3: This is a low-risk docs-only correction for a Feishu channel configuration value.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: Real behavior proof is not required because this PR only changes files under docs/.

Evidence reviewed

PR surface:

Docs -1. Total -1 across 1 file.

View PR surface stats

Area	Files	Added	Removed	Net
Source	0	0	0	0
Tests	0	0	0	0
Docs	1	0	1	-1
Config	0	0	0	0
Generated	0	0	0	0
Other	0	0	0	0
Total	1	0	1	-1

What I checked:

• PR diff: The proposed patch only deletes the "disabled" - disable all DMs bullet from the Feishu direct-message dmPolicy list. Public docs: docs/channels/feishu.md. (docs/channels/feishu.md:47, 891e1c948bac)
• Current docs mismatch: Current main still lists "disabled" in the Feishu direct-message policy list. Public docs: docs/channels/feishu.md. (docs/channels/feishu.md:47, 2001b15f5b92)
• Schema contract: The Feishu schema accepts open, pairing, and allowlist for dmPolicy; disabled is only present in the separate group-policy schema. (extensions/feishu/src/config-schema.ts:14, 2001b15f5b92)
• Internal sentinel only: Feishu policy code uses dmPolicy: "disabled" as an internal group-routing sentinel while direct-message authorization receives normalized user config. (extensions/feishu/src/policy.ts:151, 2001b15f5b92)
• Existing setup gap: A shared setup prompt still offers disabled for DM policy, and the Feishu setup adapter exposes that shared DM-policy surface; this predates the docs-only PR and is separate follow-up work. (src/flows/channel-setup.prompts.ts:146, 2001b15f5b92)
• Shipped behavior: Release v2026.6.10 has the same Feishu docs bullet and the same schema enum, so the PR is not obsolete against the latest release. Public docs: docs/channels/feishu.md. (docs/channels/feishu.md:47, aa69b12d0086)

Likely related people:

• mazhe-nerd: Authored merged Feishu onboarding/docs PR feat: Streamline Feishu channel onboarding with QR code scan-to-create flow #65680, which rewrote docs/channels/feishu.md and extensions/feishu/src/setup-surface.ts. (role: introduced docs behavior; confidence: high; commits: f67d04e1a0a9; files: docs/channels/feishu.md, extensions/feishu/src/setup-surface.ts)
• niuchong0523: Merged the Feishu onboarding/docs rewrite that introduced the current docs/setup surface. (role: merger; confidence: medium; commits: 9e2ac8a1cb9a; files: docs/channels/feishu.md, extensions/feishu/src/setup-surface.ts)
• RomneyDa: Recently merged docs: align Feishu DM policy defaults #91755 to align Feishu DM policy defaults in the same docs page. (role: recent Feishu docs contributor; confidence: medium; commits: 0d5de2587b75; files: docs/channels/feishu.md)
• chengoak: Authored merged Feishu dynamic-agent docs work touching the same page in docs(feishu): add dynamicAgentCreation and per-user isolation docs #82793. (role: recent Feishu docs contributor; confidence: medium; commits: d8ed2323a3a5; files: docs/channels/feishu.md)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.