FPF Reference

    G.Core:8 - Common anti-patterns and how to avoid them

    Preface node heading:g-core-8-common-anti-patterns-and-how-to-avoid-them:78820

    What this page is

    This is generated FPF reference text from the specification preface or supporting sections. It helps interpret FPF; it is not FPF Reference product documentation.

    Methodology

    Use it to understand how the specification wants to be read, then return to a route, pattern, or work packet for active work. Cite generated IDs only when the wording changes the task decision.

    Content

    • Anti-pattern: Restating CN‑Spec/CG‑Spec rules inside a G.x “for convenience”. Avoid: cite A.19 and G.0 through CC‑GCORE‑CN‑CG‑1.

    • Anti-pattern: Adding a fourth guard status (“unknown”, “maybe”, “probe-only”) as a separate decision value. Avoid: keep guard domain tri‑state; express “probe-only” as policy/branching and record via pins/audit.

    • Anti-pattern: Treating mandatory invariants as “defaults” to centralize them. Avoid: keep invariants as invariants (CC‑GCORE‑* cited through canonical governing definitions); restrict the Default Governing Definition Index to true defaults (constants or conditional default-rules).

    • Anti-pattern: Turning partial orders into scalar ranks silently. Avoid: keep set‑valued semantics unless a total order is explicitly declared by a comparator/policy.

    • Anti-pattern: Competing defaults scattered across multiple patterns. Avoid: Default Governing Definition Index; delegate duplicate statements to the one governing definition.

    • Anti-pattern: Local trigger tokens without canonical mapping. Avoid: provide/cite a TriggerAliasMap with namespace‑qualified aliases.

    • Anti-pattern: Breaking public CC ids during dedup. Avoid: convert to delegation items; preserve IDs.

    Last Updated: 2026-06-17 — upstream FPF commit 646b0b9b (github.com/ailev/FPF)