fpf.tools
Library / First Principles Framework (FPF) - Core Conceptual Specification
Jump to passage
In this reading
Source · lines 113655–113677

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 08:25:59 UTC · snapshot created 2026-10-03 08:26:43 UTC · last check 2026-10-03 09:50:10 UTC

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

  • Anti-pattern: Restating CN‑Spec/CG‑Spec rules inside a G.x “for convenience”. Avoid: cite A.19.CN 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.