[documentation-writing-alignment] Resolve conflicting mock requirements in module test guidance #563

Problem

The module test documentation gives incompatible requirements for mocks. This is a policy contradiction, not a writing-style choice. The writing review preserves both requirements until the owning policy is resolved.

Evidence

At 64ffb1d87f86bd5d487891fdb140b78385a00531, test-specification.md says "No Mocks: We do not use mocks in tests." powershell-module-standard.md says "Unit tests mock boundaries owned by the module" and requires tests that run locally without secrets that cannot be mocked.

A reader cannot determine whether module-owned boundary mocks are prohibited or required for unit tests. The prose-only delivery in #556 must not choose a policy by weakening one requirement.

Expected result

The owning module test policy defines the applicable test categories and mock requirements. Both documents state that same policy, with any intentional scope difference explicit. Normative requirements remain distinct from claims about existing CI enforcement, as required by the pinned Documentation Model.

Acceptance criteria

• The policy owner decides the allowed/required mock use for each affected test category.
• The two pages state consistent requirements without deleting a supported test scenario or changing normative force through ambiguous wording.
• Existing testing guidance and relevant test examples verify the chosen interpretation.
• Any necessary implementation change has explicit separate scope; the writing campaign does not silently change test behavior.
• A focused draft PR records the decision, changed guidance, and applicable existing validation.

Constraints and implementation plan

The module standard is reserved by the existing release/framework proposal ownership, including #524. Obtain owner coordination before editing. The active assertion audit in #551 owns no documentation and does not resolve this policy.

• Confirm the policy and test-category scope with its owner; record the source decision before editing.
• Build acceptance examples that distinguish allowed mocks, prohibited mocks, and live integration tests.
• Update the owning guidance consistently in one focused draft PR.
• Verify examples, preserved technical constraints, and existing relevant documentation/test checks.

Reproduction and environment

1. Open the two source links in Evidence at the pinned commit.
2. Read the function-test specification's no-mocks rule.
3. Read the module standard's unit-test boundary-mock rule.
4. Determine whether a unit test may mock a module-owned boundary. The pages give incompatible answers without an explicit scope distinction.

The environment is repository documentation at the pinned source commit. The contradiction is independent of operating system or PowerShell runtime. Regression status and the last consistent version are unknown. No authoritative policy workaround is known; keep the exception explicit instead of selecting a rule by inference.

Root-cause boundary and verification

The verified cause is overlapping normative text without a defined test-category distinction. Whether an intentional distinction exists is unresolved. The smallest correction is a policy decision and consistent guidance, not a test-runner change.

A prose linter cannot decide a test policy. Use the repeatable four-step comparison above as the failing documentation regression before editing, then show that each affected test category has one consistent answer afterward. Record that manual result and the policy source in the draft PR. Existing Markdown/link checks verify syntax and links only.