feat: scope release-branch edits to self-host and fix table conventions

[RiskeyL]

Process fixes from the CE 1.16.2 prep, independent of release content.

• dify-docs-release-sync: new copy-scope rule under Docs Branch — release-branch work edits only the en/self-host/... copy of dual-copy pages; the en/cloud/... copy describes what Dify Cloud currently runs and updates on Cloud's own release lane; single-copy trees ride the release branch; main-targeting fixes still edit both copies. During 1.16.2 prep the unqualified "both product copies" rule sent cloud-tree edits onto the CE release branch, which had to be reverted.
• dify-docs-guides: the dual-copy discipline rule gains the matching release-branch exception with a pointer to the rule's home.
• writing-guides/formatting-guide.md § Tables: manual cell breaks are <br/><br/> (corrects the previous <br/><br/><br/><br/> prescription), and long description cells split at semantic boundaries (what it does / default behavior / how to change it).
• check-format-cjk.py: the ja sentence-length check now treats <br/> tags as sentence boundaries instead of counting the markup toward the 80-character limit, which false-flagged table cells whose prose was well under the threshold.

Ref: DC-193

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
dify-ce-cloud-docs	🟢 Ready	View Preview	Aug 14, 2026, 11:23 AM

💡 Tip: Enable Workflows to automatically generate PRs for you.

[Copilot]

Pull request overview

This PR updates internal documentation/process rules and formatting checks to prevent release-branch documentation edits from accidentally modifying Cloud docs, and to align table formatting conventions with the style guide and CJK linting behavior.

Changes:

• Refines release-branch scoping rules so release prep work targets the self-host copy of dual-copy pages, with Cloud docs updated on Cloud’s separate release lane.
• Updates the table formatting guidance to standardize manual line breaks and encourage semantic splitting of long table cells.
• Adjusts the Japanese sentence-length lint to treat <br/> as a sentence boundary, avoiding false positives in table cells.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
writing-guides/formatting-guide.md	Updates table conventions for manual line breaks and semantic splitting of long description cells.
.claude/skills/dify-docs-release-sync/SKILL.md	Adds a release-branch copy-scope rule to prevent Cloud-tree edits during CE release prep.
.claude/skills/dify-docs-guides/SKILL.md	Aligns dual-copy scoping guidance with the new release-branch exception.
.claude/skills/dify-docs-format-check/check-format-cjk.py	Treats <br/> tags as sentence boundaries for JA sentence-length checks to reduce false flags.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

Suppressed comments (2)

writing-guides/formatting-guide.md:357

• The phrase “one break per boundary” is ambiguous because the previous bullet defines a “manual line break” specifically as <br/><br/>. Spell out the exact markup here to avoid inconsistent table formatting.

- Split long description cells at semantic boundaries (what it does / default behavior / how to change it), one break per boundary — long cells hurt more in a table than an extra break does.

.claude/skills/dify-docs-format-check/check-format-cjk.py:739

• The new comment says “
  tags”, but the regex matches <br>, <br/>, and <br />. Updating the comment keeps the code documentation accurate.

        # <br/> tags are line breaks, not prose: treat them as sentence boundaries

[Copilot]

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated no new comments.

Suppressed comments (2)

.claude/skills/dify-docs-terminology-check/SKILL.md:66

• The git grep example here uses regex matching (git grep -n) when i18n keys commonly contain . and other regex metacharacters, which can produce false matches. Use fixed-string matching (-F) to ensure you’re tracing the exact key.

   - Multiple exact hits → the value is shared by several keys; pick by tracing which component the documented surface renders (`git grep -n '"<key>"' "$REF" -- 'web/app/**'`), and record which key you chose and why. Never assume the closest-looking key.

writing-guides/glossary.md:169

• This git grep example uses regex matching by default, but i18n keys typically contain . which changes the meaning in regex and can lead to incorrect matches. Use fixed-string matching (-F) (and -n for line numbers) so the instruction reliably finds the exact key usage.

For a label not yet in this table, resolve its exact i18n key before writing any language's form: find the key whose en-US value matches on the surface you are documenting — several keys often share one value, so trace the rendering component (`git grep '<key>' -- 'web/app/**'`) to disambiguate — then take each language from that key. Never pick a translation by matching values across namespaces; a label whose key you cannot identify is unverified and must be flagged, not approximated.