FPF Reference

    G.Core:3 - Forces

    Preface node heading:g-core-3-forces:76079

    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

    • One governing definition vs. usability: We must centralize universal invariants, but G.x must remain readable and pattern-scoped for authors.
    • Delegation-first vs. completeness: Many norms already have canonical governing definitions such as A.6.7, A.15.3, A.19, G.0, A.19.CHR, and the relevant Part E patterns. G.Core must cite those governing definitions rather than duplicating semantics.
    • Public-id and alias continuity: Public CC IDs and deprecated trigger labels must remain stable as labels; deduplication must not break citations.
    • Typed change control: RSCR/refresh must become id‑based (catalogued trigger kinds) rather than prose-based “meaning”.
    • Strict distinction: Keep governing spec refs (CN‑Spec, CG‑Spec), suites, kits/surfaces, policies, planned baselines, audits, and refresh orchestration distinct.
    • Minimal specificity naming: New IDs must be kind‑suffixed and minimally specific, to reduce semantic lock‑in while remaining precise.
    • Phase‑2 scope discipline: G.Core must not become a container for discipline/method/generator taxonomies; those remain pattern-scoped (Extensions), delegated to existing governing patterns, or marked Phase‑3 seeds (appendix) without new Phase‑2 norms.

    Last Updated: 2026-06-08 — upstream FPF commit 093d30e8 (github.com/ailev/FPF)