docs(faq): the Copilot answer stops promising an AI redaction rule

[os-steve]

Fixes #1623

Description

reference/faq line 116, under "The Copilot won't answer about a specific customer.", promised a security control that ships nowhere:

AI redaction rule — admins can block the Copilot from referencing flagged accounts (e.g., VIP, in litigation). The Copilot says so explicitly.

The answer offered two possibilities and only the first one — sharing — was real. Line 116 is now a denial that hands the reader the mechanism actually doing the work, in all three faces. Nothing else on the page is touched.

Why this matters more than a wrong navigation path

No data leaks. Field-level security is real and is enforced for the Copilot, exactly as administration/sharing-and-security states. The risk runs the other way: an admin reads this bullet, believes flagged-account blocking is sitting there waiting to be configured, and therefore never sets up the FLS that is actually protecting the records. A false control placed next to a true one can substitute for it in a reader's head.

So the replacement is written to leave a reader knowing what they must actually do: field permissions on the profile are the control, and there is no second, AI-specific one to go looking for.

What was resolved, and against what

Measured in this worktree at b66ee261, against the installed package — node_modules/@objectstack/spec reports 17.3.0, matching objectstack.manifest.json's specVersion: ^17.3.0.

Claim	Result
A redaction / sensitivity key in the eleven shipped settings namespaces	None.
A Setup entry for redaction, sensitivity or masking (four shipped locales)	None.
The platform's redactFields	Lives on an object's publicSharing block — fields stripped from share-token responses. src/objects/knowledge_article.object.ts is this repo's only user, for exactly that. Not the Copilot.
A VIP / litigation / confidential / AI-exclusion flag in src/	Zero. The one confidential hit is a comment in sales-manager.profile.ts about crm_opportunity.is_private, an opportunity row-level rule — not an account flag and not AI-specific.
A src/skills/ instruction mentioning redaction or a blocked-account check	None ⇒ the promised "The Copilot says so explicitly" had nothing to trigger it.

Three near-misses were run down rather than pattern-matched, and none is a Copilot redaction rule:

• maskingRule — a field property (name / email / phone / id_card / bank_account, or {keepHead, keepTail}). Field-shaped PII masking, not per-account blocking.
• redactUrlCredentials / redactableConfigKeys / MetadataTypeRedactor — credential redaction on datasource and metadata read paths. Secrets, not customer records.
• sensitivity in spec/dist/data — the words "case sensitivity" in filter-logic prose. Not a key.

⇒ the card's premise holds unchanged. Nothing has appeared at this ref that would invert it.

Changes Made

• content/docs/reference/faq.mdx — line 116 only
• content/docs/reference/faq.zh-Hans.mdx — line 116 only
• content/docs/reference/faq.zh-Hant.mdx — line 116 only
• .changeset/faq-no-ai-redaction-rule.md — added by this PR

The diff is exactly @@ -116 +116 @@ in each of the three faces — one line each, nothing else on the page, no src/, no test/**, no new guard.

Deliberately not over-claiming FLS

FLS gives permission-shaped visibility, which is a different thing from per-account VIP blocking — conflating them is the defect this card exists to remove. The new line therefore says only what is true: the Copilot reads as the signed-in user, so a field masked on their profile never reaches it. It does not say FLS blocks flagged accounts. Record-level invisibility is left where it already lives — the Sharing bullet immediately above — rather than being restated as a second cause.

crm_opportunity.is_private is real record-level confidentiality, and is deliberately not cited here: it is opportunity-scoped, not account-scoped, not AI-specific, and already covered by that sharing bullet. Naming it would have re-invented the very shape being deleted.

Agreement with PR #1622

#1622 corrected the same claim in checklist form on administration/setup section 14. Its landed wording was read first and reused, so the two pages now deny the same thing in one voice and send the reader to the same page — Sharing & security, unanchored, the same link target #1622 used.

Terminology follows the live pages rather than a fresh coinage: zh-Hans 字段级安全 / 遮罩 / 权限档案 / 共享与安全, zh-Hant 欄位層級安全 / 遮罩 / 權限設定檔 / 共用與安全, each as administration/sharing-and-security spells it in that locale. The zh-Hant face keeps #1622's 脫敏 spelling for the denied term so both pages name it identically.

Testing

pnpm verify — exit 0, all eight stages ran and printed their own verdict:

✓ Validation passed (1085ms)          objectstack validate
                                      tsc --noEmit
                                      objectstack lint
✓ i18n lint gate: 0 `i18n/missing-*` issues
✓ source hygiene clean
✓ source token ratchet clean
                                      objectstack build
Test Files  160 passed (160)          vitest run
     Tests  3394 passed | 1 skipped (3395)

Targeted docs guards, run first: docs-setup-navigation-names, docs-anchor-links, docs-zh-hant-justification, docs-locale-callouts, docs-drift — 5 files, 57 tests, exit 0.

Checked by hand, because no gate reads this prose:

• Locale prefixes — the new zh links carry /zh-Hans/ and /zh-Hant/. grep -nE '\]\(/docs/' over both Chinese faces returns nothing.
• No retired UI name — the new text uses none of RETIRED_UI_NAMES, and neither bolded phrase (There is no AI redaction rule, field-level security) contains an arrow, so it makes no **App → …** navigation claim for the guard's rule 2 to resolve. No path is bolded that does not resolve, because no path is claimed.
• No control characters — grep -naP '[\x00-\x08\x0b\x0c\x0e-\x1f\x7f]' over all four changed files is empty.

What no green here proves

⚠️ No gate reads this prose. link-check.yml wakes on .mdx but runs file-extension: '.md' exact, so it opens none of the three edited pages — only the changeset, which is why no site-absolute link was put in it. The claim that the bullet is now true rests on the measurements above, at b66ee261, against installed @objectstack/* 17.3.0 — not on any check turning green.

Type of Change

Documentation update. Draft — not marked ready, not enqueued, no auto-merge.

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
hotcrm	Ignored		Sep 6, 2026 1:01am UTC