GPT Direction — Registries/Pivot Rebuild as Reuse Foundation

Date: 2026-05-30 Reviewer: GPT Council

User correction

The prior discovery/cross-check was useful but still under-scoped. It did not sufficiently account for the already-designed species/taxonomy/registry ontology and the existing /knowledge/registries and /knowledge/pivot UI/work.

Important existing musicians that must be called:

• Điều 2 Registry law: every entity must have ID, registry, metadata, automated management.
• Species taxonomy: multi-layer species/composition model, not ad hoc list.
• Information atom law: every governed entity has identity, registry, metadata, relations, page/profile.
• Điều 26 Pivot: pivot_count is the canonical counting method.
• Existing registries page /knowledge/registries: old UI/model exists but violates newer Nuxt/template boundary and must be treated as reference, not implementation authority.
• Existing pivot page /knowledge/pivot: should be the base for rebuilding registries-pivot, but only through PG → Directus/API → Nuxt render shell, no Nuxt business logic/hardcode.

Strategic direction

Do not create isolated list tools. Rebuild the registries/pivot layer once as the canonical counting and registry governance surface.

Working name: Registries-Pivot OS Agency Surface

Preferred path: /knowledge/pivot may be evolved into /knowledge/registries-pivot if needed, but development should start by auditing and preserving useful logic from /knowledge/pivot and /knowledge/registries.

Key principles

1. Reuse first: existing species taxonomy, meta_catalog, table_registry, pivot_definitions, pivot_results, v_registry_counts, birth_registry, registry pages, and pivot pages must be audited before any new design.
2. No hardcode: no handwritten per-count commands, no hardcoded species/category/tier lists, no Nuxt counting logic.
3. PG-first: counts must come from pivot definitions/functions/views in PG; Directus/Nuxt only expose/render.
4. Living list: every registry/list must have live source + planned source + reconciliation + pivot count + IU/profile/relation path.
5. Species aware: every object must know species/composition layer; final object layer is the object's own DB/relationship substrate.
6. UI is OS Agency standard: consistent, functional, data-driven; beauty is secondary.

Required next macro

Run a focused audit/design macro:

REGISTRIES_PIVOT_FOUNDATION_REUSE_AUDIT_AND_REBUILD_BLUEPRINT

Goal:

• inspect existing /knowledge/registries and /knowledge/pivot pages/code/data;
• inspect species taxonomy, atom law, registry law, pivot law, birth/collection, DOT governance, IU/KG;
• map existing capabilities that must be reused;
• identify violations in current implementation (Nuxt hardcode, manual counts, non-pivot logic);
• design the rebuild as a data-driven template/surface over PG pivot/registry substrate;
• produce a roadmap and prompts, not immediate production implementation.

Guardrails

• No production Nuxt coding yet.
• No new counting engine.
• No schema mutation.
• No PG/Directus/Qdrant mutation.
• No hardcoded categories/counts/species.
• Do not discard old work; classify each artifact as REUSE / EXTEND / WRAP / RECONCILE / RETIRE / DEFER / NEW.