docs(agent-governance): add Grok 4.3 / Grok Build engineering harness (#798)
* feat: add Grok 4.3 agent config, GROK.md, GPT55.md, handoff template, and .env additions - GROK.md: full agent instructions optimized for Grok 4.3 high-effort mode - GPT55.md: agent instructions for GPT-5.5 (o3-level reasoning, stateless) - docs/handoff_template.md: mandatory cross-session handoff artifact template - .env.grok43: Grok 4.3 environment config additions (do not commit secrets) - AGENTS.md: prepend Grok 4.3 multi-agent/Arena mode addendum block * feat: prepend Grok 4.3 / GPT-5.5 multi-agent addendum to AGENTS.md * refine GROK.md: add Versor Coherence Guardian Protocol section + tighten NON-NEGOTIABLE INVARIANTS with explicit versor_apply / cga_inner / FieldState / claim schema / safety pack rules for stronger algebraic and epistemic guardrails * refine AGENTS.md: align Grok 4.3 / Grok Build hard stops with refined GROK.md (Plan Mode, skills system, Versor Coherence Guardian references) while preserving full compatibility for Claude * upgrade docs/handoff_template.md to mastery level for Grok Build: add Versor Coherence Guardian checks, subagent reconciliation section, skills usage tracking, and stronger invariant verification language * expand .env.grok43 into full Grok Build mastery configuration (skills dir, Plan Mode preference, Arena settings, auto-invoke) * create skills/core-bootstrap.md - highest priority Grok Build skill for statelessness compensation * create skills/versor-coherence-guardian.md - critical Grok Build skill enforcing the new Versor Coherence Guardian Protocol * create skills/pre-edit-sweep.md - Grok Build skill implementing the Pre-Edit Sweep Protocol at mastery level * create skills/claim-proposal-guardian.md - Grok Build skill protecting claim schema and epistemic rigor * create docs/core-rd-base-prompts.md - high-signal, architecture-grounded prompt library for HITL and agentic use (lightly polished for structure and scannability) * add Phase-Specific Prompt Library reference section to GROK.md pointing to the new docs/core-rd-base-prompts.md * add reference to docs/core-rd-base-prompts.md in AGENTS.md Grok section * add prompt library reference to handoff_template.md in the 'What Must Not Be Forgotten' section * move .env.grok43 to docs/examples/grok43.env.example as a proper example file * remove old .env.grok43 (moved to docs/examples/grok43.env.example) * update docs/core-rd-base-prompts.md: fix epistemic wording + add sections #8 PR Merge-Readiness Audit and #9 Grok Build Implementation Session * make 'full suite before merge' rule scope-sensitive in GROK.md for docs/config-only changes * add reference to new prompt sections #8 and #9 in handoff_template.md * create docs/grokbuild/README.md - comprehensive SpaceX-level mastery guide for using Grok 4.3 + Grok Build on CORE * fix broken markdown fences in sections #8 and #9 of docs/core-rd-base-prompts.md * fix skill invocation wording and soften curl|bash recommendation in docs/grokbuild/README.md * docs(agent-governance): clean handoff template whitespace
This commit is contained in:
Shay
GitHub
parent
5f6e9f5e08
commit
e36591ed46
11 changed files with 917 additions and 0 deletions
28
AGENTS.md
28
AGENTS.md
|
|
@ -4,6 +4,34 @@ This repository is building a deterministic cognitive engine, not a transformer
|
|||
wrapper and not a demo chatbot. Every agent must preserve the geometric
|
||||
runtime while moving the system toward teachable cognitive chat.
|
||||
|
||||
## Agent-Specific Instruction Files
|
||||
|
||||
Different agents read a supplementary file alongside this one. Read yours
|
||||
before touching any code:
|
||||
|
||||
| Agent | Supplementary file | Key differences |
|
||||
|---|---|---|
|
||||
| **Claude** | `CLAUDE.md` | Deep context; self-restraining; read for semantic anchoring rule nuance |
|
||||
| **Grok 4.3 + Grok Build** | `GROK.md` | Stateless; requires high reasoning effort; Arena/parallel subagent rules; Plan Mode preferred; skills system; see also docs/core-rd-base-prompts.md for phase-specific prompts |
|
||||
| **GPT-5.5 (o3-class)** | `GPT55.md` | Stateless; fluency cautions; extended thinking for algebra/field work |
|
||||
|
||||
If you are Grok 4.3 or GPT-5.5, complete the Session Start Checklist in your
|
||||
file before reading anything else in this file.
|
||||
|
||||
## Grok 4.3 / Grok Build Hard Stops (Mastery Level)
|
||||
|
||||
These apply to Grok 4.3 and Grok Build in addition to every rule below:
|
||||
|
||||
1. **You are stateless.** Read `GROK.md` in full, `docs/runtime_contracts.md`, and the most recent `HANDOFF-*.md` (if dated within 3 days) before any edits.
|
||||
2. **High reasoning effort is mandatory** for all tasks touching `algebra/`, `field/`, `generate/realizer.py`, `generate/graph_planner.py`, `generate/intent.py`, `vault/store.py`, `calibration/`, `core/cognition/`, or `teaching/`.
|
||||
3. **Use Plan Mode** (Grok Build) for any non-trivial change in the above modules. Direct edits are discouraged.
|
||||
4. **Skills are the preferred mechanism** for repeated protocols. Use `/core-bootstrap`, `/versor-coherence-guardian`, `/pre-edit-sweep`, and `/claim-proposal-guardian` (or their auto-triggered versions).
|
||||
5. **Sweep before you edit.** Use tool-call chains to trace imports and call sites.
|
||||
6. **Write a handoff doc at session end** using `docs/handoff_template.md`.
|
||||
7. **Arena / parallel subagents:** each subagent independently satisfies `||F * reverse(F) - 1||_F < 1e-6` before reporting. Reconcile results before any merge. No mutable state sharing.
|
||||
|
||||
---
|
||||
|
||||
## North Star
|
||||
|
||||
CORE should become capable of:
|
||||
|
|
|
|||
133
GPT55.md
Normal file
133
GPT55.md
Normal file
|
|
@ -0,0 +1,133 @@
|
|||
# CORE Agent Instructions for GPT-5.5 (o3-class)
|
||||
|
||||
Read this file in full before touching any file in this repository.
|
||||
CORE is a deterministic cognitive engine — not a transformer wrapper, not a
|
||||
generic chatbot, not an infrastructure playground.
|
||||
|
||||
> **You are stateless across API sessions.** You have no persistent memory
|
||||
> of prior conversations. Complete the
|
||||
> [Session Start Checklist](#session-start-checklist) before any edits.
|
||||
|
||||
---
|
||||
|
||||
## Session Start Checklist
|
||||
|
||||
1. **Read this file in full.**
|
||||
2. **Read `AGENTS.md` in full.**
|
||||
3. **Read `docs/runtime_contracts.md` in full.**
|
||||
4. **Run the smoke suite:**
|
||||
```bash
|
||||
core test --suite smoke -q
|
||||
```
|
||||
5. **Check for a handoff doc** — read the most recent `HANDOFF-*.md` if one
|
||||
exists dated within the last 3 days.
|
||||
6. **State your task scope** — before editing, name the module(s) and the
|
||||
invariant you will prove was not violated.
|
||||
|
||||
---
|
||||
|
||||
## Reasoning and Tool Use
|
||||
|
||||
GPT-5.5 (o3-level) has strong multi-step reasoning. Use it here by:
|
||||
|
||||
- **Reasoning through the full operator chain** before proposing edits to
|
||||
algebra or field modules. Do not shortcut the math.
|
||||
- **Using tool calls** to sweep import graphs and call sites before editing.
|
||||
- **Stating your reasoning** about why an edit preserves versor_condition
|
||||
before writing the code.
|
||||
|
||||
For extended thinking mode: enable it for any task touching `algebra/`,
|
||||
`field/`, `vault/`, `calibration/`, or `core/cognition/`.
|
||||
|
||||
---
|
||||
|
||||
## NON-NEGOTIABLE INVARIANTS
|
||||
|
||||
```
|
||||
❌ versor_condition(F) < 1e-6 at every runtime field state.
|
||||
Fix the operator/construction boundary; do not weaken the threshold.
|
||||
|
||||
❌ Normalization only at:
|
||||
ingest/gate.py
|
||||
language_packs/compiler.py
|
||||
algebra/versor.py
|
||||
sensorium/*/canonical.py
|
||||
session/context.py (semantic anchoring only — see CLAUDE.md)
|
||||
Forbidden in: generate/stream.py, field/propagate.py, vault/store.py,
|
||||
logging/telemetry layers.
|
||||
|
||||
❌ No cosine similarity, HNSW, ANN, or approximate recall in runtime.
|
||||
Vault recall is exact and deterministic.
|
||||
|
||||
❌ No stochastic generation or opaque LLM fallbacks in the cognitive path.
|
||||
|
||||
❌ No pack mutation outside the proposal-only reviewed teaching loop.
|
||||
|
||||
❌ INV-21/22/23/24/29/30 (see CLAUDE.md for full text).
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## GPT-5.5 Specific Cautions
|
||||
|
||||
GPT-5.5's code generation is fluent and fast. That fluency creates
|
||||
specific risks for CORE:
|
||||
|
||||
- **Do not generate "helpful" utility wrappers** that centralize normalization
|
||||
or add intermediate caching layers. CORE's architecture is already
|
||||
explicit about where these belong.
|
||||
- **Do not add type coercions** in hot-path algebra that silently
|
||||
re-normalize field state.
|
||||
- **Do not suggest async/concurrent refactors** to vault or algebra paths
|
||||
without a full trace of the determinism contract.
|
||||
- **Tool-use completions that look finished may not be** — always run the
|
||||
CLI validation suite, do not assume correctness from code inspection alone.
|
||||
|
||||
---
|
||||
|
||||
## Pre-Edit Sweep Protocol
|
||||
|
||||
Before editing any module in `algebra/`, `field/`, `generate/`, `vault/`,
|
||||
`core/cognition/`, `teaching/`, or `calibration/`:
|
||||
|
||||
1. Trace every import of the target module.
|
||||
2. Identify all callers of the target function/class.
|
||||
3. Check `evals/` and `calibration/` for tests covering the changed path.
|
||||
4. Only then propose edits.
|
||||
|
||||
---
|
||||
|
||||
## End-of-Session Handoff Requirement
|
||||
|
||||
At the end of every session, write a handoff document using the template
|
||||
at `docs/handoff_template.md`. Name it:
|
||||
|
||||
```
|
||||
HANDOFF-gpt55-YYYY-MM-DD.md
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Architecture Summary
|
||||
|
||||
Raw input becomes a closed versor field once; thought evolves through exact
|
||||
versor transitions and CGA recall; cognition is structured as intent,
|
||||
proposition graph, articulation target, deterministic realization, reviewed
|
||||
memory, eval/calibration replay, and traceable evidence.
|
||||
|
||||
See `AGENTS.md` for the full cognitive path, key modules, and PR checklist.
|
||||
|
||||
---
|
||||
|
||||
## CLI Validation Lanes
|
||||
|
||||
```bash
|
||||
core test --suite smoke -q
|
||||
core test --suite cognition -q
|
||||
core test --suite teaching -q
|
||||
core test --suite packs -q
|
||||
core test --suite runtime -q
|
||||
core test --suite algebra -q
|
||||
core test --suite full -q
|
||||
core eval cognition
|
||||
```
|
||||
227
GROK.md
Normal file
227
GROK.md
Normal file
|
|
@ -0,0 +1,227 @@
|
|||
# CORE Agent Instructions for Grok 4.3
|
||||
|
||||
Read this file in full before touching any file in this repository.
|
||||
CORE is a deterministic cognitive engine — not a transformer wrapper, not a generic chatbot, not an infrastructure playground. The rules here are architectural invariants, not suggestions.
|
||||
|
||||
> **You are stateless.** You have no memory of prior sessions.
|
||||
> Complete the [Session Start Checklist](#session-start-checklist) before any edits. Do not skip it.
|
||||
|
||||
---
|
||||
|
||||
## Phase-Specific Prompt Library
|
||||
|
||||
For detailed, phase-oriented guardrails that are tightly coupled to CORE’s architecture, invariants, ADRs, and epistemic model, see:
|
||||
|
||||
**`docs/core-rd-base-prompts.md`**
|
||||
|
||||
These prompts are designed to be used as standing prefixes **in addition to** this file. The "Session Entry / Context Load" prompt is especially recommended at the start of most sessions. The "Standing Loop Axiom Check" is highly effective as a final self-audit before committing.
|
||||
|
||||
---
|
||||
|
||||
## Session Start Checklist
|
||||
|
||||
Run these steps in order, using your tool-call chains, before writing a single line of code:
|
||||
|
||||
1. **Read this file in full.**
|
||||
2. **Read `AGENTS.md` in full.**
|
||||
3. **Read `docs/runtime_contracts.md` in full.**
|
||||
4. **Run the smoke suite and report pass/fail:**
|
||||
```bash
|
||||
core test --suite smoke -q
|
||||
```
|
||||
5. **Check for a recent handoff doc** — if a `HANDOFF-*.md` file exists dated within the last 3 days, read it. It contains state you would otherwise have no way to recover.
|
||||
6. **State your task scope** — before editing, write one sentence naming the module(s) you intend to change and the invariant you will prove was not violated.
|
||||
|
||||
Do not treat conversation history as a substitute for steps 1–5. History does not survive context resets. Ground yourself in the repo.
|
||||
|
||||
---
|
||||
|
||||
## Reasoning Effort Requirement
|
||||
|
||||
You must operate at **high reasoning effort** for all tasks that touch:
|
||||
|
||||
- `algebra/`
|
||||
- `field/`
|
||||
- `generate/realizer.py`, `generate/graph_planner.py`, `generate/intent.py`
|
||||
- `vault/store.py`
|
||||
- `calibration/`
|
||||
- `core/cognition/`
|
||||
- `teaching/`
|
||||
|
||||
If you were invoked at default or low effort and the task touches any of these modules, **stop and request re-invocation at high effort.** Low-effort reasoning on the algebra/field layer produces plausible-looking but mathematically incorrect results.
|
||||
|
||||
For `workbench-ui/`, `docs/`, `notes/`, `scripts/` at low risk, medium effort is acceptable.
|
||||
|
||||
---
|
||||
|
||||
## Versor Coherence Guardian Protocol
|
||||
|
||||
Before proposing or executing **any** change that could affect versor closure, field propagation, or exact CGA recall:
|
||||
|
||||
1. Explicitly confirm that the core invariant holds: `||F * reverse(F) - 1||_F < 1e-6` for the affected `FieldState`.
|
||||
2. Verify that `versor_apply(V, F)` and `cga_inner(X, Y)` paths remain exact and untouched except through the allowed modules (`algebra/versor.py` and permitted callers).
|
||||
3. Re-run the relevant invariant checks from `tests/test_versor_closure.py` (or current equivalent) on the modified paths.
|
||||
4. Only after the above may you proceed with edits or proposals.
|
||||
|
||||
This protocol is mandatory for any work in `algebra/`, `field/`, `vault/`, or `generate/`.
|
||||
|
||||
---
|
||||
|
||||
## NON-NEGOTIABLE INVARIANTS
|
||||
|
||||
These are **hard architectural constraints enforced by construction**. Violating any one of them is a bug that must be reverted before merge.
|
||||
|
||||
**Versor & CGA Level (Exact Algebraic Coherence)**
|
||||
- `||F * reverse(F) - 1||_F < 1e-6` must hold identically for **every** runtime `FieldState` and every application of `versor_apply(V, F)`.
|
||||
- All state is represented as versors. All transitions are exact versor products. No exceptions, no approximations.
|
||||
- Multivector representation in `algebra/` uses fixed `(32,)` float32 arrays for Cl(4,1). No dynamic resizing or external library types in the hot path.
|
||||
- `cga_inner(X, Y) = -d²/2` is the sole exact recall primitive. It must remain exact and deterministic.
|
||||
|
||||
**Normalization & Approximation Boundaries**
|
||||
- Normalization is allowed **ONLY** at the explicitly listed locations:
|
||||
- `ingest/gate.py`
|
||||
- `language_packs/compiler.py`
|
||||
- `algebra/versor.py`
|
||||
- `sensorium/*/canonical.py` (signal canonicalization, pinned only)
|
||||
- `session/context.py` (semantic anchoring)
|
||||
- Forbidden everywhere else, including `generate/stream.py`, `field/propagate.py`, `vault/store.py`, and all logging/telemetry paths.
|
||||
|
||||
**No Approximate or Stochastic Mechanisms**
|
||||
- No cosine similarity, HNSW, ANN indexes, embedding-based recall, or any approximate nearest-neighbor mechanism anywhere in the deterministic cognitive path.
|
||||
- Vault recall is **exact** `cga_inner` only.
|
||||
- No stochastic generation, sampling, opaque LLM fallbacks, or probabilistic mechanisms in the core deterministic reasoning, teaching, recognition, or realization pipelines.
|
||||
|
||||
**Claim Schema & Epistemic Rigor**
|
||||
- Claim status transitions (SPECULATIVE → COHERENT → CONTESTED → FALSIFIED) may only occur through the defined review-gated TeachingChainProposal mechanism.
|
||||
- A claim may not move to COHERENT without passing all applicable review gates and producing a reproducible evidence bundle.
|
||||
- No direct mutation of epistemic status. Only `vault/store.py` may transition status (INV-29).
|
||||
- User-facing `vault.recall` must enforce `min_status=COHERENT` (INV-24).
|
||||
|
||||
**Safety & Identity Packs**
|
||||
- Safety packs (`packs/safety/`) are **unmodifiable at runtime**. They are fail-closed and reviewer-signed.
|
||||
- Identity packs are swappable only via the defined PersonaMotor + proposal mechanism. Runtime mutation is forbidden.
|
||||
- Any attempt to relax or bypass a safety axis must be rejected and logged as a protocol violation.
|
||||
|
||||
If you believe one of these must change for correctness or performance reasons, **STOP**. Write a proposal in `notes/` or `docs/decisions/` and do not implement the change. CORE’s architecture is not negotiated inside a coding session.
|
||||
|
||||
---
|
||||
|
||||
## Pre-Edit Sweep Protocol
|
||||
|
||||
Before editing any module in `algebra/`, `field/`, `generate/`, `vault/`, `core/cognition/`, `teaching/`, or `calibration/`:
|
||||
|
||||
1. Use your file-read and search tool chains to **trace every import** of the target module across the codebase.
|
||||
2. Identify **all callers** of the specific function or class you intend to change.
|
||||
3. Check `calibration/` and `evals/` for tests that exercise the changed path.
|
||||
4. Only then propose edits.
|
||||
|
||||
Your 1M-token context window means you can load the full relevant subgraph in one pass. Do this. Do not guess at call sites.
|
||||
|
||||
---
|
||||
|
||||
## Agentic Tool-Call Discipline
|
||||
|
||||
Grok 4.3's multi-step tool-call chains are an asset here. Use them to:
|
||||
- Load the full affected module graph before proposing changes.
|
||||
- Run CLI validation lanes and report actual output, not assumed output.
|
||||
- Confirm invariants are held after edits by re-running the relevant suite.
|
||||
|
||||
Do not use tool chains to:
|
||||
- Probe for statistical or ML-based workarounds to exact CGA constraints.
|
||||
- Discover "alternative" normalization sites not listed above.
|
||||
- Chain edits across multiple modules before verifying the first one.
|
||||
|
||||
---
|
||||
|
||||
## Arena / Parallel Subagent Mode
|
||||
|
||||
If running in Arena mode (parallel subagents):
|
||||
|
||||
- Each subagent **receives its own copy of this file and AGENTS.md**.
|
||||
- Each subagent must **independently satisfy** `||F * reverse(F) - 1||_F < 1e-6` before reporting results.
|
||||
- Do not share mutable runtime state between subagents.
|
||||
- Treat Arena subagent results as **independent proposals**, not sequential commits. Reconcile them before any merge.
|
||||
- No subagent output becomes another subagent's unchecked input.
|
||||
|
||||
---
|
||||
|
||||
## End-of-Session Handoff Requirement
|
||||
|
||||
At the end of every session, write a handoff document to the repo using the template at `docs/handoff_template.md`. Name it:
|
||||
|
||||
```
|
||||
HANDOFF-grok43-YYYY-MM-DD.md
|
||||
```
|
||||
|
||||
This is not optional. It is the only continuity mechanism across your stateless sessions. A session without a handoff doc is a session whose work may be silently lost or contradicted by the next session.
|
||||
|
||||
---
|
||||
|
||||
## Architecture Summary
|
||||
|
||||
Raw input becomes a closed versor field once; thought evolves through exact versor transitions and CGA recall; cognition is structured as intent, proposition graph, articulation target, deterministic realization, reviewed memory, eval/calibration replay, and traceable evidence.
|
||||
|
||||
```text
|
||||
CognitiveTurnPipeline
|
||||
-> tokenize / OOV policy / inject
|
||||
-> intent classification
|
||||
-> PropositionGraph
|
||||
-> ArticulationTarget
|
||||
-> deterministic realizer / articulation surface
|
||||
-> generation walk telemetry
|
||||
-> identity + energy telemetry
|
||||
-> reviewed teaching capture (when correction intent appears)
|
||||
-> deterministic trace hash
|
||||
```
|
||||
|
||||
Key modules:
|
||||
- `core/cognition/pipeline.py` — cognitive turn spine
|
||||
- `core/cognition/result.py` — canonical turn result shape
|
||||
- `core/cognition/trace.py` — deterministic trace hashing
|
||||
- `generate/intent.py` — deterministic intent classification
|
||||
- `generate/graph_planner.py` — proposition graph and articulation target
|
||||
- `generate/realizer.py` / `generate/templates.py` — deterministic realization
|
||||
- `teaching/*` — reviewed teaching / correction lifecycle
|
||||
- `vault/store.py` — epistemic store with INV-21/22/23/24/29 guards
|
||||
- `evals/*` — deterministic eval harness
|
||||
- `calibration/*` — bounded replay-based calibration
|
||||
- `docs/runtime_contracts.md` — runtime response, memory, identity, and testing
|
||||
|
||||
---
|
||||
|
||||
## PR Checklist
|
||||
|
||||
Before opening or merging, answer:
|
||||
|
||||
```text
|
||||
What capability, performance property, or security boundary did this add/protect?
|
||||
Which invariant proves the field remains valid?
|
||||
Which CLI suite/eval proves the relevant lane?
|
||||
Did this avoid hidden normalization, stochastic fallback, approximate recall, and unreviewed mutation?
|
||||
If it touches user input, files, dynamic imports, or logs, what trust boundary was enforced?
|
||||
Was the smoke suite green before and after?
|
||||
```
|
||||
|
||||
Prefer small, load-bearing PRs.
|
||||
|
||||
For runtime/algebra/cognition/teaching/pack changes: run full suite before merge.
|
||||
For docs/config-only agent-governance changes: smoke is sufficient unless the PR touches CLI, tests, generated docs, or executable scripts.
|
||||
|
||||
---
|
||||
|
||||
## CLI Validation Lanes
|
||||
|
||||
```bash
|
||||
core test --suite smoke -q
|
||||
core test --suite cognition -q
|
||||
core test --suite teaching -q
|
||||
core test --suite packs -q
|
||||
core test --suite runtime -q
|
||||
core test --suite algebra -q
|
||||
core test --suite full -q
|
||||
core eval cognition
|
||||
```
|
||||
|
||||
Run the smallest relevant suite first.
|
||||
For runtime/algebra/cognition/teaching/pack changes, run full before merge.
|
||||
For docs/config-only agent-governance changes, smoke is sufficient unless the PR changes CLI, tests, generated docs, or executable scripts.
|
||||
169
docs/core-rd-base-prompts.md
Normal file
169
docs/core-rd-base-prompts.md
Normal file
|
|
@ -0,0 +1,169 @@
|
|||
# CORE R&D Base Prompts
|
||||
|
||||
These prompts are grounded directly in CORE’s actual architecture — the runtime contracts, invariants, ADR chain, and epistemic model. They are designed to be dropped into Grok Build, Claude Code, or any agentic loop as standing prefixes.
|
||||
|
||||
They work **in addition to** `GROK.md` and `AGENTS.md`, not as replacements.
|
||||
|
||||
## Recommended Usage Pattern
|
||||
|
||||
The cleanest loop for CORE R&D:
|
||||
|
||||
1. Start every session with the **Session Entry / Context Load** prompt.
|
||||
2. Add the appropriate phase-specific prompt (#2–#6) for the work at hand.
|
||||
3. End every session by running the **Standing Loop Axiom Check** (#7) as a final self-audit before committing.
|
||||
|
||||
For Grok Build’s parallel subagent (Arena) mode, assign one subagent per major module boundary and give each its own copy of the relevant phase prompt. The contracts are precise enough that agents rarely drift when anchored to the same ADR references and invariants.
|
||||
|
||||
---
|
||||
|
||||
## 1. Session Entry / Context Load
|
||||
|
||||
Paste this at the start of any coding session:
|
||||
|
||||
```text
|
||||
You are working inside AssetOverflow/core. Before touching anything:
|
||||
|
||||
1. Read CLAUDE.md and AGENTS.md fully. Do not infer the project structure — derive it.
|
||||
2. The field invariant is load-bearing: versor_condition(F) < 1e-6. Any path you write that propagates field state must preserve closure or fail loudly. Never silently downgrade.
|
||||
3. Teaching claim status uses the four-position reviewed revision graph: SPECULATIVE, COHERENT, CONTESTED, FALSIFIED.
|
||||
|
||||
Do not confuse this with runtime EpistemicState / DisclosureClaim surfaces, which are richer (PERCEIVED, EVIDENCED, VERIFIED, DECODED, INFERRED, UNDETERMINED, SCOPE_BOUNDARY, etc.) and governed separately.
|
||||
4. Durable standing mutations (corpus/pack/policy/identity) are proposal-only, reviewed via teaching/*. Do not route around this.
|
||||
5. wrong == 0 is not a metric target — it is an architectural obligation. If a path you produce can emit a wrong (non-refused) answer that isn't disclosed as [approximate], treat that as a structural defect, not a test failure. Do not proceed until you have internalized the above.
|
||||
```
|
||||
|
||||
## 2. New Feature / ADR-Driven Work
|
||||
|
||||
```text
|
||||
You are implementing a new capability slice for CORE under the ADR discipline.
|
||||
|
||||
Rules:
|
||||
- Every non-trivial decision must be traceable to an existing ADR or require a new one. If you are making an architectural choice with no ADR anchor, name it explicitly and propose the ADR before writing code.
|
||||
- Placement is load-bearing. generate/* owns generation/propagation semantics. algebra/versor.py owns closure invariants only — no admissibility logic there. field/propagate.py is a forbidden normalization/repair site.
|
||||
- Fail loudly, not silently. No silent catch-and-continue on versor violations, refusal exhaustion, or epistemic transitions.
|
||||
- New test gates follow the taxonomy in docs/runtime_contracts.md: algebra/ physics/ runtime/ cognition/ teaching/ packs/. Do not mix concerns across test directories.
|
||||
- Every new invariant must be enforced by a failing test, not by convention.
|
||||
```
|
||||
|
||||
## 3. Refactor / Cleanup Pass
|
||||
|
||||
```text
|
||||
You are doing a refactor pass on CORE.
|
||||
|
||||
Constraints:
|
||||
- Do not reorganize tests as standalone churn. Only move files if it directly reduces contract ambiguity or unlocks a cognitive subsystem.
|
||||
- Protect load-bearing behavior: versor closure, deterministic replay, runtime response/telemetry contracts, memory correctness, identity protection, teaching/correction safety, and the articulation contract.
|
||||
- Do not preserve stale constructors, private helper shapes, or exact formatting that is not part of a documented contract. These are not worth protecting.
|
||||
- Backward compatibility is a real constraint: InnerLoopExhaustion is a ValueError; every existing except ValueError handler must continue to work.
|
||||
- Trace hash determinism is a hard invariant: compute_trace_hash must produce byte-identical output for identical inputs. Any change that touches hashed payloads must be verified against this.
|
||||
```
|
||||
|
||||
## 4. Eval / Testing Lane Work
|
||||
|
||||
```text
|
||||
You are writing or extending an eval lane for CORE.
|
||||
|
||||
Invariants for all eval work:
|
||||
- wrong == 0 is the gate, not a stretch goal. A lane that permits any non-refused wrong answer does not pass.
|
||||
- refused is the safe failure mode. A lane that refuses everything (0 correct, 0 wrong, N refused) is a passing gate; whether it qualifies for expert promotion is a separate ADR question.
|
||||
- Seal discipline: plaintext holdout data never touches disk. CORE_HOLDOUT_KEY is required to decrypt; tests without the key skip, never fail.
|
||||
- No cross-domain bleed: evidence lanes must attach only to their domain's ratified packs.
|
||||
- Adversarial suites must include at least one family that proves the gate isn't trivially satisfied by refusing everything.
|
||||
- Lane shapes are registered, not inferred. Adding a new lane to the audit-passed surface requires an explicit registry entry and an ADR amendment.
|
||||
```
|
||||
|
||||
## 5. Determinism / Replay Audit
|
||||
|
||||
```text
|
||||
You are auditing or restoring deterministic replay in CORE.
|
||||
|
||||
The replay contract:
|
||||
- No clock, no LLM sampling, no external randomness in any replayable path.
|
||||
- compute_trace_hash folds refusal_reason only when non-empty, preserving byte-identical hashes for non-refused turns.
|
||||
- Divergence in a persisted CognitivePipelineRecord is evidence against equivalence, not wall-clock noise. Treat it as a falsification signal, not a flake.
|
||||
- No pickle. Pickle defeats replay determinism and is a code-execution surface.
|
||||
- All hashed payloads: canonical JSON (sorted keys, tight separators, UTF-8, no NaN/Infinity). Floats forbidden in hashed payloads.
|
||||
- A live turn with a trace hash but no status="recorded" CognitivePipelineRecord fails before journal append.
|
||||
```
|
||||
|
||||
## 6. Architectural Boundary / Separation Guard
|
||||
|
||||
```text
|
||||
You are working near a trust boundary or architectural separation in CORE.
|
||||
|
||||
The most critical active separation: open-world CLOSE derivation vs. closed-world FrameVerdict. These have zero data flow in either direction. This is enforced by INV-30 and INV-31.
|
||||
|
||||
Do not create import paths, type sharing, or semantic composition across this boundary. Any controlled interaction — however narrow — is a material architectural change requiring a new ADR, updates to INV-30/INV-31, re-verification that wrong_total == 0, and fresh ratification.
|
||||
|
||||
Formation Pipeline boundary discipline: every trust boundary has a content-addressed input and output. Every rejection produces an audit record. No silent failures anywhere in the pipeline.
|
||||
|
||||
When in doubt about whether a change crosses a boundary: it does. Prove it doesn't before proceeding.
|
||||
```
|
||||
|
||||
## 7. The Standing Loop Axiom Check
|
||||
|
||||
Use this as a closing self-audit after any session before committing:
|
||||
|
||||
```text
|
||||
Before committing, answer each question:
|
||||
|
||||
1. Does any new propagation path preserve versor_condition(F) < 1e-6? If no: do not commit.
|
||||
2. Does any new path produce a wrong (non-refused, undisclosed) answer? If yes: structural defect, not a test to patch.
|
||||
3. Does any new code touch corpus/pack/policy/identity mutation outside the reviewed teaching path? If yes: route through proposal-only.
|
||||
4. Does any new invariant have a failing test that would catch violation? If no: write the test first.
|
||||
5. Does the change cross the CLOSE/FrameVerdict boundary? If yes: stop and open an ADR.
|
||||
6. Are all hashed payloads in canonical JSON with no floats? If no: fix before committing.
|
||||
|
||||
All six must be clean. If any is uncertain, surface it explicitly — do not silently assume it's fine.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 8. PR Merge-Readiness Audit
|
||||
|
||||
```text
|
||||
You are auditing a CORE PR for merge readiness.
|
||||
|
||||
Do not approve based on intent. Verify:
|
||||
1. Exact branch head SHA
|
||||
2. Diff scope vs PR claim
|
||||
3. Touched invariants
|
||||
4. Relevant tests/evals and exact outputs
|
||||
5. wrong_total == 0 where applicable
|
||||
6. No open-world/closed-world boundary leak
|
||||
7. No unreviewed corpus/pack/policy/identity mutation
|
||||
8. No hidden normalization, approximate recall, stochastic fallback, or dynamic execution surface
|
||||
|
||||
Return:
|
||||
- Verdict: MERGE / BLOCK / NEEDS PATCH
|
||||
- Blockers
|
||||
- Non-blocking concerns
|
||||
- Exact commands run
|
||||
- Files inspected
|
||||
- Residual risk
|
||||
```
|
||||
|
||||
## 9. Grok Build Implementation Session
|
||||
|
||||
```text
|
||||
You are working inside AssetOverflow/core.
|
||||
|
||||
First:
|
||||
- Read GROK.md, AGENTS.md, docs/runtime_contracts.md
|
||||
- Read the most recent HANDOFF-* if dated within 3 days
|
||||
- Run `core test --suite smoke -q`
|
||||
- State the exact scope and invariant you will preserve
|
||||
|
||||
Then:
|
||||
- Do not edit until you have traced all imports/callers for the target path
|
||||
- Keep the PR small
|
||||
- Write failing tests before behavior changes
|
||||
- Prefer refusal over wrong
|
||||
- Never add hidden normalization, approximate recall, stochastic fallback, or direct mutation of claim/pack/policy/identity state
|
||||
|
||||
End with:
|
||||
- Exact files changed
|
||||
- Tests run with outputs
|
||||
- Invariants verified
|
||||
- Handoff doc content
|
||||
```
|
||||
19
docs/examples/grok43.env.example
Normal file
19
docs/examples/grok43.env.example
Normal file
|
|
@ -0,0 +1,19 @@
|
|||
# Grok 4.3 + Grok Build Mastery Configuration for CORE (Example)
|
||||
# ----------------------------------------------------------------
|
||||
# Copy this file to your local .env (which is gitignored) and fill in values.
|
||||
# This is a reference/example only.
|
||||
|
||||
# === Model & Reasoning ===
|
||||
GROK_MODEL=grok-4.3
|
||||
GROK_REASONING_EFFORT=high
|
||||
GROK_CONTEXT_BUDGET=800000
|
||||
|
||||
# === Grok Build CLI Mastery Settings ===
|
||||
GROK_BUILD_SKILLS_DIR=skills/
|
||||
GROK_BUILD_PLAN_MODE_PREFERRED=true
|
||||
GROK_BUILD_ARENA_MODE=true
|
||||
GROK_BUILD_MAX_AGENTS=8
|
||||
GROK_BUILD_AUTO_INVOKE_SKILLS=true
|
||||
|
||||
# === API / Auth (put real key only in your local .env) ===
|
||||
# XAI_API_KEY=your_key_here
|
||||
172
docs/grokbuild/README.md
Normal file
172
docs/grokbuild/README.md
Normal file
|
|
@ -0,0 +1,172 @@
|
|||
# Using Grok 4.3 + Grok Build with CORE — Mastery Guide
|
||||
|
||||
This document defines the canonical, high-discipline way to use Grok 4.3 and Grok Build on the AssetOverflow/core repository.
|
||||
|
||||
The goal is not to make the model "smarter." The goal is to make the **engineering process** more disciplined, reproducible, and resistant to architectural drift while leveraging powerful agentic tooling.
|
||||
|
||||
Grok Build is treated as a **bounded engineering laboratory**, not an autonomous architecture mutator.
|
||||
|
||||
---
|
||||
|
||||
## 1. Philosophy & Mental Model
|
||||
|
||||
- Grok 4.3 is fast, high-context, and agentic. This is both its strength and its primary risk on CORE.
|
||||
- The system must remain **coherent by construction**. Any change that weakens `||F * reverse(F) - 1||_F < 1e-6`, epistemic rigor, or trust boundaries is a defect, not an optimization.
|
||||
- Human judgment remains the final authority. Grok proposes, sweeps, verifies, and documents. Humans decide.
|
||||
- Statelessness is a feature, not a bug. We compensate for it structurally (bootstrap skill + handoff docs + prompt library).
|
||||
|
||||
**Core Principle**: Prefer refusal over wrong. Prefer small, verifiable diffs over large ambitious changes.
|
||||
|
||||
---
|
||||
|
||||
## 2. Initial Setup (One-Time)
|
||||
|
||||
1. Clone the repo and checkout `feat/grok43-agent-config` (or main once merged).
|
||||
2. Copy `docs/examples/grok43.env.example` to your local `.env` and fill in your `XAI_API_KEY`.
|
||||
3. Install Grok Build CLI using the current official xAI instructions.
|
||||
Do not pipe installer scripts into a shell unless the source and any available checksum/signature have been verified.
|
||||
4. Run `grok inspect` inside the repo root to confirm skills are discovered.
|
||||
5. (Optional but recommended) Create a personal `skills/` override directory if you want local custom skills.
|
||||
|
||||
---
|
||||
|
||||
## 3. Standard Session Workflow (Recommended Loop)
|
||||
|
||||
Every productive session follows this pattern:
|
||||
|
||||
### Phase 0: Bootstrap (Mandatory)
|
||||
- Invoke the `core-bootstrap` skill (or run it manually via the Grok Build interface).
|
||||
- Read `GROK.md` + `AGENTS.md` + `docs/runtime_contracts.md`.
|
||||
- Run smoke suite.
|
||||
- Read most recent relevant `HANDOFF-*.md`.
|
||||
|
||||
### Phase 1: Context & Scope
|
||||
- Paste the **Session Entry / Context Load** prompt from `docs/core-rd-base-prompts.md`.
|
||||
- Clearly state the exact scope and the invariant(s) you will preserve.
|
||||
|
||||
### Phase 2: Planning (Plan Mode Preferred)
|
||||
- Use **Plan Mode** for anything non-trivial.
|
||||
- Produce a clear plan with:
|
||||
- Modules affected
|
||||
- Invariants touched
|
||||
- Tests/evals that will be impacted
|
||||
- Risk assessment
|
||||
|
||||
### Phase 3: Sweep
|
||||
- Run full import/call-site/eval sweep before any edit (use `pre-edit-sweep` skill when available).
|
||||
- Use the 1M context window aggressively.
|
||||
|
||||
### Phase 4: Implementation
|
||||
- Make minimal, load-bearing changes.
|
||||
- Write failing tests *before* behavior changes when possible.
|
||||
- Prefer explicit refusal over silent wrong answers.
|
||||
|
||||
### Phase 5: Verification
|
||||
- Run relevant test suites (smallest relevant first).
|
||||
- Run **Versor Coherence Guardian** checks on any algebra/field/vault/generate changes.
|
||||
- Run the **Standing Loop Axiom Check** (#7 from prompt library).
|
||||
|
||||
### Phase 6: Documentation & Handoff
|
||||
- Write/update the handoff document using `docs/handoff_template.md`.
|
||||
- Record exact invariants verified, tests run, and open tasks.
|
||||
|
||||
---
|
||||
|
||||
## 4. Using Grok Build Features at Mastery Level
|
||||
|
||||
### Plan Mode
|
||||
- Default for any change touching `algebra/`, `field/`, `vault/`, `generate/`, `teaching/`, `core/cognition/`, or `calibration/`.
|
||||
- Use it even for "small" refactors in sensitive areas.
|
||||
- Review the plan carefully before approval — this is your main defense against drift.
|
||||
|
||||
### Arena / Parallel Subagents
|
||||
- Powerful but high-risk if not structured.
|
||||
- Recommended pattern: Role separation
|
||||
- **Agent A**: ADR / invariant auditor
|
||||
- **Agent B**: Import + call-site sweeper
|
||||
- **Agent C**: Test/eval designer + verifier
|
||||
- **Agent D**: Minimal implementation proposer
|
||||
- **Agent E**: Adversarial reviewer / confuser generator
|
||||
- All subagent outputs are treated as **independent proposals**.
|
||||
- Human (or a final reconciliation agent) merges the reconciled result.
|
||||
- Every subagent must independently satisfy core invariants before its output is considered.
|
||||
|
||||
### Skills System
|
||||
- Prefer skills over ad-hoc prompting for repeated patterns.
|
||||
- Currently available high-value skills:
|
||||
- `core-bootstrap`
|
||||
- `versor-coherence-guardian`
|
||||
- `pre-edit-sweep`
|
||||
- `claim-proposal-guardian`
|
||||
- Use `/skillify` after successful sessions to capture new reusable workflows.
|
||||
|
||||
---
|
||||
|
||||
## 5. Prompt Library (`docs/core-rd-base-prompts.md`)
|
||||
|
||||
This is the canonical set of phase-specific guardrails.
|
||||
|
||||
**Key sections to use regularly**:
|
||||
- #1 Session Entry / Context Load (start of almost every session)
|
||||
- #7 Standing Loop Axiom Check (end of every session before commit)
|
||||
- #8 PR Merge-Readiness Audit (before opening or merging any PR)
|
||||
- #9 Grok Build Implementation Session (structured session protocol)
|
||||
|
||||
The other sections (#2–#6) are used situationally depending on the type of work.
|
||||
|
||||
---
|
||||
|
||||
## 6. Anti-Patterns to Avoid
|
||||
|
||||
- Treating Grok as the final authority on architecture
|
||||
- Running large changes without Plan Mode on sensitive modules
|
||||
- Letting Arena subagents edit without role separation and reconciliation
|
||||
- Skipping the bootstrap + smoke + handoff loop
|
||||
- Using statistical/approximate solutions for exact CGA or epistemic requirements
|
||||
- Bypassing review gates for claim/pack/policy/identity mutations
|
||||
- Assuming "it probably didn’t touch the invariant" without verification
|
||||
|
||||
---
|
||||
|
||||
## 7. PR & Merge Discipline
|
||||
|
||||
Before opening or merging any PR:
|
||||
|
||||
1. Run the **PR Merge-Readiness Audit** prompt (#8).
|
||||
2. Ensure the diff is minimal and load-bearing.
|
||||
3. Verify all touched invariants have explicit checks.
|
||||
4. Confirm relevant tests/evals are green with exact outputs recorded.
|
||||
5. Write a high-quality handoff document.
|
||||
|
||||
For docs/config/agent-governance PRs (like this one), smoke is usually sufficient. For runtime changes, full validation is required.
|
||||
|
||||
---
|
||||
|
||||
## 8. Long-Term Maintenance of This Governance Layer
|
||||
|
||||
- The files in this setup (`GROK.md`, `AGENTS.md`, skills, prompt library, handoff template) are living documents.
|
||||
- When CORE’s architecture evolves (new invariants, new modules, new boundaries), update the relevant governance files in the same PR or a follow-up.
|
||||
- Periodically review whether new high-value skills should be extracted from successful sessions.
|
||||
- Treat this layer with the same rigor as runtime code — it protects the architecture.
|
||||
|
||||
---
|
||||
|
||||
## 9. Quick Reference
|
||||
|
||||
```text
|
||||
# Bootstrap (in Grok Build TUI or via skill invocation)
|
||||
/core-bootstrap
|
||||
|
||||
# Verify core invariant
|
||||
core test --suite algebra -q
|
||||
|
||||
# Start Grok Build
|
||||
grok
|
||||
|
||||
# Inspect current skills and config
|
||||
grok inspect
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
This document, combined with the files it references, represents the current best-known method for using Grok 4.3 + Grok Build on CORE with high discipline and low risk of architectural regression.
|
||||
107
docs/handoff_template.md
Normal file
107
docs/handoff_template.md
Normal file
|
|
@ -0,0 +1,107 @@
|
|||
# HANDOFF — [AGENT] — [YYYY-MM-DD]
|
||||
|
||||
<!-- Copy this file, rename to HANDOFF-[agent]-YYYY-MM-DD.md, fill in all
|
||||
sections completely. This is the ONLY continuity mechanism for stateless
|
||||
agents (Grok 4.3 / Grok Build) across sessions. Do not leave placeholders. -->
|
||||
|
||||
## Agent and Session
|
||||
|
||||
- **Agent:** <!-- grok43 | gpt55 | claude | other -->
|
||||
- **Date:** <!-- YYYY-MM-DD -->
|
||||
- **Reasoning effort used:** <!-- high (mandatory for algebra/field) | medium | low -->
|
||||
- **Grok Build mode used:** <!-- TUI | Plan Mode | Arena (parallel subagents) | Headless -->
|
||||
- **Session entry point:** <!-- Exact task handed to this agent -->
|
||||
|
||||
---
|
||||
|
||||
## Smoke Suite + Bootstrap Status
|
||||
|
||||
```
|
||||
<!-- Paste output of: core test --suite smoke -q -->
|
||||
<!-- Confirm core-bootstrap skill completed successfully -->
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Modules Touched
|
||||
|
||||
<!-- List every file modified, created, or deleted this session. -->
|
||||
|
||||
| File | Change type | Summary |
|
||||
|---|---|---|
|
||||
| | | |
|
||||
|
||||
---
|
||||
|
||||
## Invariants Verified (Versor Coherence Guardian + Core)
|
||||
|
||||
<!-- For each relevant invariant, state how it was confirmed. Include Versor Coherence Guardian checks. -->
|
||||
|
||||
| Invariant | Check performed | Result | Notes |
|
||||
|---|---|---|---|
|
||||
| `||F * reverse(F) - 1||_F < 1e-6` (core closure) | Versor Coherence Guardian + tests/test_versor_closure.py | | |
|
||||
| versor_apply / cga_inner exactness | Manual trace + re-run of affected paths | | |
|
||||
| Normalization boundaries respected | Pre-edit sweep + code review | | |
|
||||
| No approximate recall (ANN/HNSW/cosine) | Full import/call-site sweep | | |
|
||||
| Claim status transitions via review gates only | Claim-proposal-guardian checks | | |
|
||||
| Safety/identity pack immutability | Safety-pack-auditor | | |
|
||||
| INV-21 / INV-24 / INV-29 (Vault & epistemic) | Explicit verification | | |
|
||||
| Other (name it) | | | |
|
||||
|
||||
---
|
||||
|
||||
## Subagent / Arena Reconciliation (if applicable)
|
||||
|
||||
<!-- If Arena/parallel subagents were used -->
|
||||
- Number of subagents spawned:
|
||||
- Each subagent independently verified versor closure? (Yes/No)
|
||||
- How were results reconciled before merge?
|
||||
|
||||
---
|
||||
|
||||
## Tests Run
|
||||
|
||||
```bash
|
||||
# Commands run and their exit status:
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Open Tasks / Next Session Entry Point
|
||||
|
||||
<!-- Be extremely specific. "Continue the work" is not acceptable. -->
|
||||
|
||||
1.
|
||||
2.
|
||||
3.
|
||||
|
||||
---
|
||||
|
||||
## Known Hazards / Do Not Touch
|
||||
|
||||
<!-- Mid-refactor state, fragile areas, or steps that must complete first. -->
|
||||
|
||||
---
|
||||
|
||||
## Architectural Decisions Made This Session
|
||||
|
||||
<!-- Any decision affecting future sessions (operator choices, boundary calls, ADR interpretations). -->
|
||||
|
||||
---
|
||||
|
||||
## What Must Not Be Forgotten
|
||||
|
||||
<!-- The single most important thing the next agent must know. Write it as if this is the only document they will read. -->
|
||||
|
||||
**Prompt Library Reference**: See `docs/core-rd-base-prompts.md` (especially sections #7 Standing Loop Axiom Check, #8 PR Merge-Readiness Audit, and #9 Grok Build Implementation Session). Use them as standing prefixes.
|
||||
|
||||
---
|
||||
|
||||
## Skills Used This Session
|
||||
|
||||
<!-- List which Grok Build skills were invoked (manual or auto-triggered) -->
|
||||
- core-bootstrap:
|
||||
- versor-coherence-guardian:
|
||||
- pre-edit-sweep:
|
||||
- claim-proposal-guardian:
|
||||
- Other:
|
||||
15
skills/claim-proposal-guardian.md
Normal file
15
skills/claim-proposal-guardian.md
Normal file
|
|
@ -0,0 +1,15 @@
|
|||
---
|
||||
name: claim-proposal-guardian
|
||||
description: Enforce review-gated claim status transitions and epistemic rigor. Prevents direct mutation of SPECULATIVE / COHERENT / CONTESTED / FALSIFIED status.
|
||||
triggers: ["pre_edit:teaching/", "pre_edit:core/cognition/", "pre_edit:vault/", "manual"]
|
||||
auto_invoke: true
|
||||
---
|
||||
|
||||
Before any change involving claim status, TeachingChainProposal, or epistemic_status:
|
||||
|
||||
1. Confirm the change goes through the defined review-gated proposal mechanism only.
|
||||
2. Verify no direct mutation of claim status or epistemic_status outside `vault/store.py` (INV-29).
|
||||
3. Ensure user-facing recall respects `min_status=COHERENT` (INV-24).
|
||||
4. Block or surface any attempt to bypass review gates.
|
||||
|
||||
This skill protects CORE's truth-seeking schema and epistemic integrity.
|
||||
17
skills/core-bootstrap.md
Normal file
17
skills/core-bootstrap.md
Normal file
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
name: core-bootstrap
|
||||
description: Mandatory statelessness compensation + smoke test + recent handoff check for CORE. Auto-invoked on session/subagent start.
|
||||
triggers: ["session_start", "new_subagent", "arena_spawn"]
|
||||
auto_invoke: true
|
||||
---
|
||||
|
||||
Execute the full **Session Start Checklist** from GROK.md in strict order:
|
||||
|
||||
1. Read GROK.md in full.
|
||||
2. Read AGENTS.md in full.
|
||||
3. Read docs/runtime_contracts.md in full.
|
||||
4. Run `core test --suite smoke -q` and report pass/fail.
|
||||
5. Check for and read any HANDOFF-*-YYYY-MM-DD.md from the last 3 days.
|
||||
6. State task scope in one clear sentence before any further action.
|
||||
|
||||
This skill must complete successfully before any editing, proposal, or subagent work. It is non-bypassable for Grok 4.3 / Grok Build sessions on CORE.
|
||||
15
skills/pre-edit-sweep.md
Normal file
15
skills/pre-edit-sweep.md
Normal file
|
|
@ -0,0 +1,15 @@
|
|||
---
|
||||
name: pre-edit-sweep
|
||||
description: Execute full import/call-site + eval/calibration trace before editing sensitive modules. Complements the Versor Coherence Guardian.
|
||||
triggers: ["pre_edit:algebra/", "pre_edit:field/", "pre_edit:vault/", "pre_edit:generate/", "pre_edit:core/cognition/", "pre_edit:teaching/", "pre_edit:calibration/", "manual"]
|
||||
auto_invoke: true
|
||||
---
|
||||
|
||||
Before editing any module in the triggered paths:
|
||||
|
||||
1. Use file-read and search tool chains to trace **every import** of the target module.
|
||||
2. Identify **all callers** of the specific function/class being changed.
|
||||
3. Check `calibration/` and `evals/` for tests exercising the changed path.
|
||||
4. Only after completing the sweep may you propose or apply edits.
|
||||
|
||||
Your 1M context window exists for this. Use it. Do not guess at impact.
|
||||
15
skills/versor-coherence-guardian.md
Normal file
15
skills/versor-coherence-guardian.md
Normal file
|
|
@ -0,0 +1,15 @@
|
|||
---
|
||||
name: versor-coherence-guardian
|
||||
description: Enforce Versor Coherence Guardian Protocol + exact algebraic closure before any change in algebra/, field/, vault/, or generate/. Auto-triggers on relevant paths.
|
||||
triggers: ["pre_edit:algebra/", "pre_edit:field/", "pre_edit:vault/", "pre_edit:generate/", "manual"]
|
||||
auto_invoke: true
|
||||
---
|
||||
|
||||
Before any edit or proposal in the triggered paths, execute the **Versor Coherence Guardian Protocol** from GROK.md:
|
||||
|
||||
1. Confirm `||F * reverse(F) - 1||_F < 1e-6` holds for affected FieldState(s).
|
||||
2. Verify that `versor_apply(V, F)` and `cga_inner(X, Y)` paths remain exact.
|
||||
3. Re-run relevant checks from `tests/test_versor_closure.py` (or current equivalent).
|
||||
4. Only proceed if all checks pass. Block or surface any violation immediately.
|
||||
|
||||
This skill is non-bypassable for the listed modules. It is the primary enforcement mechanism for CORE's core algebraic invariant.
|
||||
Loading…
Reference in a new issue