docs(technical-writing): manually review distilled rules for project applicability

[Bad3r]

Context

PR #199 (#199) distilled ~109 prescriptive rules from "Docs for Developers" (Bhatti et al., Apress 2021) into six files under docs/technical-writing/. Rules were extracted with their original strength keywords (RFC-2119 MUST/SHOULD/MAY for hard rules, imperatives for guidance). Source-faithful extraction means the set is calibrated to a public docs site at a SaaS company, not to this NixOS configuration repo.

Examples of misalignment already surfaced by the PR review:

• lifecycle.md mandates CODEOWNERS entries or metadata headers per page. This repo has neither and no CI gate that enforces it.
• lifecycle.md mandates 301 redirects on every URL move. This repo ships markdown in source control, with no web hosting layer where 301s could be configured.
• code-samples.md initially mandated an 80-character cap as MUST while also mandating idiomatic style (rustfmt 100, Google Java 100, Kotlin 120). The conflict was resolved during PR review (commit bc0b0fa8), but similar precedence cases likely remain.

Goal

Do a manual pass over each rule and decide one of:

• Keep as written.
• Downgrade MUST to SHOULD (or vice versa) to match how this repo actually operates.
• Reword to scope the rule to the repo's surface (source-controlled markdown, no public host).
• Drop the rule entirely if it cannot be acted on here.
• Note the rule as aspirational and add the missing infrastructure as a separate task.

Files to review

• docs/technical-writing/scope-and-audience.md
• docs/technical-writing/drafting.md
• docs/technical-writing/editing.md
• docs/technical-writing/code-samples.md
• docs/technical-writing/visual-content.md
• docs/technical-writing/lifecycle.md

Suggested cross-checks

• Grep for MUST/MUST NOT and verify each is actually enforceable in this repo.
• Grep for SHOULD/SHOULD NOT and verify the reasoning still applies.
• Look for sibling rules in the same file that conflict at the same strength level (the precedent from code-samples.md).
• Check rules that assume infrastructure not present (CODEOWNERS, hosted docs, 301s, broken-link CI, prose linter CI, freshness-review automation).

Out of scope

• Rewriting the rules into a different format.
• Adding the missing infrastructure (track separately).