[codex] Compact agent governance loading

.cursor/rules/session_startup_instructions.mdc

@@ -1,45 +1,16 @@
 ---
-description: This rule provides essential instructions for testing and building the project correctly, avoiding common pitfalls with test environment management.
+description: Bootstrap Cursor sessions through the canonical agent governance docs instead of relying on stale inline reminders.
 globs:
 alwaysApply: true
 ---
 
 # Session Startup Instructions
 
-## Core Workflow Reminders
+1. Read `AGENTS.md`.
+2. Read `docs/agent-rules/INDEX.md`.
+3. Read `docs/agent-rules/05-non-negotiable-checklist.md`.
+4. Detect repository root, branch, and worktree state before implementation.
+5. Load any additional rule files selected by the applicability matrix in `docs/agent-rules/INDEX.md`.
+6. If a sibling internal checkout (for example `../specfact-cli-internal/`) exists and you are designing or scoping an OpenSpec change, follow the internal wiki guidance in `docs/agent-rules/40-openspec-and-tdd.md` (section **Internal wiki and strategic context**): read `wiki/hot.md`, `wiki/graph.md`, and relevant `wiki/concepts/*.md` via absolute paths; do not import wiki text into this repo.
 
-- **Testing:** Run `hatch run smart-test`. Ensure total coverage is >= 80%.
-- **Formatting:** Apply `black .`, `isort .`, `mypy .`, and `pylint src tests` before committing.
-- **Commits:** Use the [Conventional Commits](https://www.conventionalcommits.org/) format.
-- **Versioning:** When releasing, update `CHANGELOG.md`, `pyproject.toml`, `setup.py`, and `src/__init__.py`.
-- **Docstrings:** Follow the [Google Python Style Guide](https://google.github.io/styleguide/pyguide.html).
-
-## Initial Context Checklist
-
-1. **Review:
-1.1. `GEMINI.md`: Check for any session-specific goals or instructions (applies to GEMINI CLI only).
-1.2. `CLAUDE.md`: Check for any session-specific goals or instructions (applies to Claude CLI only).
-2. `docs/README.md` to get the latest project status and priorities and see which plan is referenced as being worked on: Understand the current development phase and tasks based on the mentioned plan in the README.md file.
-3. Outline your understanding of the current development phase and tasks based on the mentioned plan in the README.md file, before proceeding with any work. Ask the user for confirmation before proceeding.
-
-## Documentation and Planning Guidelines
-
-**CRITICAL**: When working with planning and documentation:
-
-- **Work directly with major artifacts**: Update strategic plans, implementation plans, and analysis documents directly. Do NOT create plans for plans, tracking documents for tracking documents, or status artifacts for status artifacts.
-- **Update existing artifacts**: Add status annotations (✅ Complete, ⏳ In Progress, 🟡 Pending) directly to existing plan documents rather than creating separate status files.
-- **Consolidate, don't multiply**: Only create new documentation artifacts when they add clear, unique value that cannot be captured in existing artifacts.
-- **Performance metrics**: Record timing and performance data directly in implementation status documents, not in separate performance tracking files.
-- **Test results**: Include test results and validation outcomes in the relevant implementation status or quality analysis documents.
-
-**Examples of what NOT to do**:
-
-- ❌ Creating `PHASE0_TRACKING.md` when `CODE2SPEC_STRATEGIC_PLAN.md` already exists
-- ❌ Creating `STEP1_1_TEST_RESULTS.md` when `PHASE1_IMPLEMENTATION_STATUS.md` can be updated
-- ❌ Creating `PERFORMANCE_METRICS.md` when performance data can go in implementation status
-
-**Examples of what TO do**:
-
-- ✅ Update `CODE2SPEC_STRATEGIC_PLAN.md` with status annotations (✅ Complete, ⏳ Next)
-- ✅ Add test results and performance metrics to `PHASE1_IMPLEMENTATION_STATUS.md`
-- ✅ Update `QUALITY_GAP_ANALYSIS.md` with measurement results and progress
+Do not treat this file as a complete workflow handbook. The canonical repository governance now lives in `docs/agent-rules/`.

.github/copilot-instructions.md

@@ -1,23 +1,11 @@
 # GitHub Copilot Instructions — specfact-cli
 
-## Clean-Code Charter
+Use [AGENTS.md](../AGENTS.md) as the mandatory bootstrap surface and [docs/agent-rules/INDEX.md](../docs/agent-rules/INDEX.md) as the canonical governance dispatcher.
 
-This repository enforces the **7-principle clean-code charter** defined in:
-- `skills/specfact-code-review/SKILL.md` (`nold-ai/specfact-cli-modules`)
-- Policy-pack: `specfact/clean-code-principles`
+## Minimal reminders
 
-Review categories checked on every PR: **naming · kiss · yagni · dry · solid**
-
-Phase A KISS thresholds: LOC > 80 warning / > 120 error per function.
-Nesting-depth and parameter-count checks are active. Phase B (>40/80) is deferred.
-
-Run `hatch run specfact code review run --json --out .specfact/code-review.json` before submitting.
-
-## Key conventions
-
-- Python 3.11+, Typer CLI, Pydantic models, `@icontract` + `@beartype` on all public APIs
-- No `print()` in `src/` — use `get_bridge_logger()`
-- Branch protection: work on `feature/*`, `bugfix/*`, `hotfix/*` branches; PRs to `dev`
-- Pre-commit checklist: `hatch run format` → `type-check` → `lint` → `yaml-lint` → `contract-test` → `smart-test`
-
-See `AGENTS.md` and `.cursor/rules/` for the full contributor guide.
+- When a sibling internal repository (for example `../specfact-cli-internal/`) exists, read its `wiki/` files by absolute path before designing an OpenSpec change; see **Strategic context** in `AGENTS.md` and `docs/agent-rules/40-openspec-and-tdd.md` (section **Internal wiki and strategic context**). Do not copy wiki content into this repository.
+- This repository enforces the clean-code review gate through `hatch run specfact code review run --json --out .specfact/code-review.json`.
+- Public APIs require `@icontract` and `@beartype`.
+- Work belongs on `feature/*`, `bugfix/*`, `hotfix/*`, or `chore/*` branches, normally in a worktree.
+- The full governance rules live in `docs/agent-rules/`; do not treat this file as a complete standalone handbook.