gm-skill 2.0.1846 → 2.0.1847

package/gm-plugkit/package.json

@@ -1,6 +1,6 @@
 {
   "name": "gm-plugkit",
-  "version": "2.0.1846",
+  "version": "2.0.1847",
   "description": "Bootstrap and daemon-spawn tool for gm plugkit binary. Downloads the correct platform binary, verifies SHA256, and starts the spool watcher daemon. Includes plugkit-wasm-wrapper for WASM-based spool watching.",
   "main": "index.js",
   "bin": {

package/gm.json

@@ -1,6 +1,6 @@
 {
   "name": "gm",
-  "version": "2.0.1846",
+  "version": "2.0.1847",
   "description": "Spool-dispatch orchestration engine with unified state machine, skills, and automated git enforcement",
   "author": "AnEntrypoint",
   "license": "MIT",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "gm-skill",
-  "version": "2.0.1846",
+  "version": "2.0.1847",
   "description": "Canonical universal harness — AI-native software engineering via skill-driven orchestration; bootstraps plugkit for task execution and session isolation. Install in any AI coding agent host.",
   "author": "AnEntrypoint",
   "license": "MIT",

package/skills/fifth-dimension-engine/SKILL.md

@@ -0,0 +1,184 @@
+---
+name: fifth-dimension-engine
+description: WFGY 5.0's core problem-solving tool. Lifts targets into higher problem-coordinates and returns structured routes (proof paths, strategy kernels, research structures, repair paths, positioning routes). Theorem work to everyday decisions. Use after Goal Compiler to execute the compiled problem specification.
+license: MIT
+compatibility: Portable "shoot + [problem]" command; works wherever an assistant can run a natural-language prompt. Upstream ships it as the current main product surface of WFGY 5.0 Polaris Protocol.
+metadata:
+  origin: onestardao-wfgy-5.0-polaris-protocol
+  provenance: adapted-and-honest-reimplementation-not-verbatim
+---
+
+# Fifth-Dimension Engine
+
+WFGY 5.0's core problem-solving tool. Lifts a target into a higher problem-coordinate, then returns a route that can be inspected, attacked, expanded, and tested.
+
+**Before you decide, shoot first.**
+
+## What This Is
+
+The Fifth-Dimension Engine does not just answer. It transforms a target into a route.
+
+| Input | Engine Action |
+|---|---|
+| Theorem | Produces proof-route structure |
+| Frontier problem | Produces research kernel |
+| Strange theme | Produces mathematical skeleton |
+| Life decision | Produces route map |
+| Product idea | Produces positioning route |
+| Engineering failure | Produces repair path |
+| Meme or absurd target | Produces hidden structure |
+
+The output is not a direct answer. It is a **route**: an inspectable, attackable, expandable structure you can verify, challenge, and refine.
+
+## When to Use
+
+Use this skill when you have:
+- A well-specified problem (use Goal Compiler first if unclear)
+- A target worth spending time on (trivial problems don't need shooting)
+- An appetite for structured reasoning (prefer depth over speed)
+
+Use **especially** for:
+- Theorem work (formal proofs, mathematical problems)
+- Strategic decisions (career, startup, major choices)
+- Research questions (turning ideas into research kernels)
+- Engineering failures (root cause analysis, repair paths)
+- Product/positioning work (audience, launch strategy)
+- High-strangeness problems (mixing themes into research)
+
+## How to Use
+
+### Basic Command
+
+```
+shoot + [your problem]
+```
+
+Examples:
+
+```
+shoot + Seven Millennium Problems
+shoot + should I quit my job
+shoot + Death + AI
+shoot + P vs NP
+shoot + How to fix my broken deployment pipeline
+```
+
+### The Engine Returns
+
+A structured route containing:
+
+- **Route**: The core strategy or path forward
+- **Structure**: Decomposition into sub-problems
+- **Candidate Lemmas**: Supporting proofs, insights, or evidence
+- **Objections**: What could go wrong, counterarguments
+- **Open Debt**: What remains unresolved
+- **Next Command**: What to do next (for theorem work: a new Lean line; for other work: next investigative step)
+
+### Why This Matters
+
+Instead of:
+- A flat answer (right or wrong, you can't inspect it)
+
+You get:
+- A *structure* you can examine
+- Sub-claims you can verify independently
+- Attack surfaces (where to challenge it)
+- Expansion points (where to dig deeper)
+- Clear open questions (what's not yet resolved)
+
+## Interaction with Other Skills
+
+### With Polaris Goal Compiler
+
+- **Goal Compiler** specifies and atomizes the problem
+- **Fifth-Dimension Engine** produces the route
+- **Goal Compiler's verification gates** validate the engine's output
+
+**Integration**: After Goal Compiler breaks work into atoms, use the engine on each atom that requires structured reasoning.
+
+**Workflow**:
+1. Goal Compiler compiles the problem into task atoms
+2. For each atom, ask: "Do I need to shoot this, or is it routine?"
+3. If routine: execute directly
+4. If complex: shoot it with Fifth-Dimension Engine
+5. Use Goal Compiler's verification gate to check the output
+6. Move to next atom
+
+### With WFGY-Method (Drift Control)
+
+- **Fifth-Dimension Engine** produces structured reasoning
+- **WFGY-Method** keeps that reasoning aligned with the original goal
+
+**Integration**: While the engine explores the route, WFGY-Method checks: "Are we still solving the original problem, or have we drifted into a different one?"
+
+Use the engine for *depth*, WFGY-Method for *direction*.
+
+## Modes and Use Cases
+
+### Seven Millennium Problems
+
+Shoot the flagship: all seven famous unsolved mathematics problems simultaneously using the same underlying engine logic.
+
+```
+shoot + Seven Millennium Problems
+```
+
+See `references/seven-millennium-problems.md` for the flagship claim and what it does and does not assert.
+
+### Baseline-50 + Frontier-50
+
+- **Baseline-50**: Known-truth math problems (check engine accuracy)
+- **Frontier-50**: Unknown century-level problems (explore frontier)
+
+### High-Strangeness Math Lab
+
+Mix two unrelated themes and let the engine find the mathematical skeleton:
+
+```
+shoot + [theme 1] + [theme 2]
+```
+
+Examples:
+- Death + AI -> digital exit operators, hell-state boundaries
+- Dream + Physics -> dream-observer collapse, reality drift
+- Love + Source Poisoning -> attachment trust graph, false-closure lemmas
+
+See `references/research-kernel-extraction.md` for how strange themes become research kernels.
+
+### Everyday Shoot Modes
+
+The same engine works on everyday problems:
+
+| Mode | Use For |
+|---|---|
+| Life Decision Shoot | Quitting, moving, major choices |
+| Relationship Shoot | Conversations, behavior, hidden tension |
+| Work / Career Shoot | Bottlenecks, career drift, stuck loops |
+| Product / Startup Shoot | Positioning, audience, launch route |
+| Research / Learning Shoot | Turning ideas into research kernels |
+| Engineering / Debugging Shoot | Root cause, system debt, repair paths |
+| Meme / Absurd Shoot | Small, weird, funny targets made structured |
+
+## Verification
+
+The engine output is inspectable, which means verifiable. See `references/route-inspection-guide.md` for how to inspect, attack, and verify a route.
+
+**This is not:** a black box. You can (and should) inspect, attack, and refine.
+
+## What This Is Not
+
+This skill does not:
+- Specify the problem (that's Goal Compiler)
+- Control drift during execution (that's WFGY-Method)
+- Produce a final answer (it produces a route, which you then verify and decide on)
+- Guarantee the route is correct (inspection and verification are your job)
+- Claim every shoot becomes a final theorem (a shoot creates a structured route; final proof, empirical truth, or real-world correctness depends on verification, review, formalization, or testing)
+
+## References
+
+See `references/` directory for:
+- `route-structure.md` — what a route is and how it is structured
+- `seven-millennium-problems.md` — the flagship demonstration
+- `research-kernel-extraction.md` — turning ideas into research kernels
+- `route-inspection-guide.md` — how to verify and attack a route
+- `skills/polaris-protocol/SKILL.md` — the Polaris Protocol tree root and state machine

package/skills/fifth-dimension-engine/references/research-kernel-extraction.md

@@ -0,0 +1,47 @@
+# Research Kernel Extraction — Fifth-Dimension Engine
+
+The High-Strangeness Math Lab is a Fifth-Dimension Engine mode that turns two unrelated themes into a theorem-shaped research kernel. The same mechanic generalizes to ordinary research questions.
+
+## The mechanic
+
+Give the engine two strange themes. It finds the mathematical skeleton underneath them.
+
+```
+shoot + [theme 1] + [theme 2]
+```
+
+Upstream examples:
+
+| Input | Possible kernel |
+|---|---|
+| Death + AI | Digital exit operator, hell-state boundary |
+| Dream + Physics | Dream-observer collapse, reality drift functional |
+| Meme + Epidemic | Narrative infection number, meme mutation bound |
+| Love + Source Poisoning | Attachment trust graph, false-closure lemma |
+| JudgmentDay + Tension Universe | Seven-Trumpet grand challenge system |
+
+## From myth to model
+
+The engine's job is to move a target from symbol to structure:
+1. Name the two themes.
+2. Shoot them together.
+3. Read the returned route: what structure does the engine propose?
+4. Inspect the candidate lemmas — are they real mathematical objects, or metaphor?
+5. Keep the parts that survive inspection; discard the parts that are only poetry.
+
+## Everyday research use
+
+The same pattern works without strangeness:
+
+```
+shoot + why do distributed consensus algorithms face a safety-liveness-cost tradeoff?
+```
+
+The engine returns a route: candidate theoretical bounds, objections, open questions. You then verify the lemmas and expand the open debt into real research.
+
+## What this does NOT claim
+
+- It does not claim the strange pairing is itself a theorem. It claims the engine can propose a structure worth attacking.
+- It does not replace domain expertise or formal proof. The kernel is a starting point for inspection, not a result.
+
+See `../SKILL.md` for the engine interface and `route-inspection-guide.md` for how to verify what comes back.

package/skills/fifth-dimension-engine/references/route-inspection-guide.md

@@ -0,0 +1,43 @@
+# Route Inspection Guide — Fifth-Dimension Engine
+
+A route from the Fifth-Dimension Engine is not a final answer. It is a structure you can inspect, attack, expand, and test. Inspection is your job; the engine only produces the route.
+
+## The standard output shape
+
+| Layer | Meaning |
+|---|---|
+| route | where the target can move |
+| structure | what the problem is made of |
+| candidate lemmas | what may become formal |
+| objections | where the route may fail |
+| open debt | what remains unresolved |
+| next command | what to do next |
+
+## How to inspect a route
+
+1. **Walk the route step by step.** Does each step follow from the one before it, or does it leap?
+2. **Check candidate lemmas independently.** Treat each lemma as a claim to be verified, not a fact because it appears in the output.
+3. **Challenge objections.** The engine lists where the route may fail. Are those objections real? Are any fatal?
+4. **Validate open debt.** Confirm the open debt is actually open (unresolved), not a hidden dependency dressed up as a footnote.
+5. **Expand anything unclear.** Drill into a vague sub-claim until it becomes inspectable or collapses.
+6. **Run the next command, then re-shoot.** For theorem work the next command may be a new Lean line; for other work it is the next investigative step. After acting, shoot again with the new state.
+
+## Attack surfaces
+
+A route is strong only if its weak points are visible. The attack surfaces are:
+- Leaping logic (a step that assumes what it should prove)
+- Lemmas stated without support
+- Objections that are acknowledged but never resolved
+- Open debt that quietly grows between rounds
+
+## What inspection is NOT
+
+- It is not re-reading the prose and nodding.
+- It is not trusting the structure because it looks formal.
+- It is not promoting a partial route to a complete answer.
+
+## Relationship to verification gates
+
+If a Polaris Goal Compiler verification gate applies to this atom, the route must pass that gate before you claim the atom is done. Route inspection is the substance of that gate; the gate is the decision rule.
+
+See `../SKILL.md` for the engine interface and `route-structure.md` for what each layer means.

package/skills/fifth-dimension-engine/references/route-structure.md

@@ -0,0 +1,76 @@
+# Route Structure in Fifth-Dimension Engine
+
+## What a Route Is
+
+A route is the **output of the Fifth-Dimension Engine** — a structured, inspectable answer to a complex problem.
+
+Instead of a flat statement like "Yes, do this" or "The answer is X," the engine produces:
+
+```
+Route:       The core strategy or path
+Structure:   Decomposition into sub-problems
+Lemmas:      Candidate supporting proofs or evidence
+Objections:  What could be wrong with this route
+Open Debt:   What remains unresolved
+Next:        What to do next (for iteration)
+```
+
+## Example: Life Decision Route
+
+**Input**: "Should I leave my job to start a company?"
+
+**Output Route**:
+```
+Route: 
+  Yes, but time the exit correctly and secure funding first.
+
+Structure:
+  1. Assess market opportunity (is there a real market?)
+  2. Assess personal readiness (skills, network, risk tolerance)
+  3. Assess financial readiness (runway, equity, savings)
+  4. Plan the exit (timing, knowledge transfer, network preservation)
+
+Lemmas:
+  - Founders with technical skills + funding + market timing succeed 40% more often
+  - First-time founders without network succeed <5% of the time
+  - Having 18 months of runway increases long-term success 60%
+
+Objections:
+  - Market might be smaller than expected (validate with customers first)
+  - You might not be ready for founder stress (talk to founders who've failed)
+  - Economic conditions could deteriorate (watch funding trends)
+
+Open Debt:
+  - Specific market size unknown (need to validate)
+  - Your personal risk tolerance unclear (need to model scenarios)
+  - Specific funding sources not identified (need to map potential investors)
+
+Next:
+  - Spend 2 weeks validating market with 20+ potential customers
+  - Then reassess using these validation results
+```
+
+## Why Routes Matter
+
+A route is:
+- **Inspectable**: You can see the reasoning, not just the conclusion
+- **Attackable**: You can challenge each part independently
+- **Expandable**: You can dig deeper on open debt
+- **Verifiable**: You can check each lemma independently
+
+A flat answer is:
+- Opaque (you have to trust it)
+- Hard to debug (if it's wrong, what went wrong?)
+- Hard to improve (you can't extend it)
+
+## Route Types by Problem Class
+
+| Problem | Route Type |
+|---|---|
+| Theorem | Proof structure with lemmas, open questions |
+| Strategy | Decision tree with tradeoffs and assumptions |
+| Design | Architecture with component roles and interactions |
+| Repair | Root cause with fix path and side-effect checks |
+| Research | Research kernel with hypothesis and validation steps |
+
+See `POLARIS-SKILLS-GUIDE.md` for full integration.

package/skills/fifth-dimension-engine/references/seven-millennium-problems.md

@@ -0,0 +1,41 @@
+# Seven Millennium Problems — the Fifth-Dimension Engine flagship
+
+This is the flagship demonstration of WFGY 5.0's Fifth-Dimension Engine.
+
+## The claim, stated precisely
+
+> One engine. One underlying logic. One simultaneous attack on all seven Millennium Problems.
+
+- **Same engine** — the seven problems are not handled by seven unrelated methods.
+- **Same logic** — the underlying route structure is generated from one high-dimensional engine.
+- **Seven together** — the Seven Millennium Problems are treated as one world-scale proof target.
+- **Open engine** — you can run it, inspect it, challenge it, and shoot again.
+
+The current public evidence layer behind this includes experiment packages with raw outputs, parsed outputs, verdict files, token accounting, audit records, and SHA256 integrity records. Those are the public evidence layer, not the main product surface.
+
+## How to run it
+
+```
+shoot + Seven Millennium Problems
+```
+
+Or, more generally:
+
+```
+Use WFGY 5.0 Fifth-Dimension Engine to simultaneously shoot the seven Millennium Problems.
+```
+
+For mathematics specifically, the upstream also points to Native Lean no-sorry materials — because theorem-complete work plus Native Lean no-sorry is one of the hardest standards in formal mathematics.
+
+## What this does NOT claim
+
+- It does **not** claim the seven are handled separately. The core claim is one engine, one underlying logic.
+- It does **not** claim this is only a replay of a fixed result. The point is that the same engine logic can shoot the seven again.
+- It does **not** claim every shoot becomes a final theorem. A shoot creates a structured route; final proof depends on verification, review, formalization, or testing.
+- It does **not** ask you to believe the author. The engine and prompt are public — run it yourself.
+
+## Why it matters as a stress test
+
+Mathematics is the hardest stress test for a structured-reasoning engine: the output is formally checkable. If the route structure holds up to inspection and formalization, that is real evidence. If it does not, the inspection itself is the value — you caught the weakness before promoting it to a claim.
+
+See `../SKILL.md` for the engine interface, and `skills/polaris-protocol/SKILL.md` for where this sits in the Polaris Protocol state machine.

package/skills/polaris-goal-compiler/SKILL.md

@@ -0,0 +1,158 @@
+---
+name: polaris-goal-compiler
+description: A human-AI communication protocol layer that compiles goals into task atoms, active/blocked work, verification gates, and claim ceilings before execution. Part of WFGY 5.0 Polaris Protocol. Use before complex AI work to make it inspectable, harder to fake, and less likely to collapse into premature completion.
+license: MIT
+compatibility: Upstream Polaris Goal Compiler is released ChatGPT-first (teaser compatibility is ChatGPT only); portability to other assistants, coding agents, and skill systems is a stated design direction, not an officially supported target in the teaser release. This skill is a portable Claude Code adaptation of that protocol.
+metadata:
+  origin: onestardao-wfgy-5.0-polaris-protocol
+  provenance: adapted-and-honest-reimplementation-not-verbatim
+---
+
+# Polaris Goal Compiler
+
+A human-AI communication protocol under WFGY 5.0 Polaris Protocol.
+
+**Compile first. Execute one active atom. Verify before unlock. Claim only what is supported.**
+
+## What This Is
+
+Polaris Goal Compiler adds the missing protocol layer between human requests and AI execution. Before producing work that looks finished, it turns the request into visible, inspectable structures:
+
+- **Task atoms**: The smallest executable units
+- **Active work**: What can be done now
+- **Blocked work**: What must wait
+- **Verification gates**: What must be checked before unlock
+- **Truth objects**: What is known vs. claimed
+- **Claim ceilings**: What the assistant is allowed to claim
+- **Closure records**: What is done, missing, partial, or unsafe
+
+This is not a normal prompt template. It is a portable TXT-based execution protocol for making complex AI work:
+- Easier to inspect
+- Harder to fake
+- Less likely to collapse into premature completion
+
+## When to Use
+
+Use this skill **before** starting any of:
+- Complex creative work (writing, design, research)
+- Multi-step reasoning tasks (proofs, strategy, debugging)
+- Long-horizon projects (planning, architecture, implementations)
+- High-stakes decisions where correctness matters
+- Work involving others (code review, collaboration)
+- Theorem work or formal verification
+
+**Do not use on**: trivial single-step tasks, reflex responses, simple lookups.
+
+## Core Workflow
+
+### 1. State Your Goal Clearly
+
+Write one sentence: what do you actually want to accomplish? Not the first sub-task, the end state.
+
+### 2. Ask: Compile My Request
+
+Ask the AI to turn your request into:
+- Task atoms (smallest units)
+- Dependencies (which blocks which)
+- Active vs. blocked work
+- Verification gates (checks before unlock)
+- Claim ceilings (what can be claimed when)
+
+### 3. Review the Compilation
+
+Before execution starts, verify:
+- Are all task atoms actually atomic?
+- Are dependencies correct?
+- Are verification gates realistic?
+- Will claim ceilings prevent overstatement?
+
+### 4. Execute One Active Atom
+
+Work on ONE task at a time. After each:
+- Verify before moving to the next
+- Check against claim ceiling (don't overstate readiness)
+- Move blocked tasks to active only if dependencies are met
+
+### 5. Iterate
+
+After each atom completes, return to step 4 until all atoms are done.
+
+## Key Concepts
+
+### Task Atoms
+
+The smallest executable unit that:
+- Can be completed in one session
+- Has clear entrance and exit criteria
+- Produces something verifiable
+- Does not depend on incomplete tasks
+
+### Active vs. Blocked Work
+
+- **Active**: Ready to start, all dependencies met
+- **Blocked**: Waiting on something else to finish first
+
+Clear separation prevents fake progress (looking busy on wrong things).
+
+### Verification Gates
+
+What must be checked *before* moving forward:
+- Does this output match what was asked for?
+- Is it complete enough for the next task?
+- Are there hidden assumptions?
+- What could break downstream?
+
+### Truth Objects
+
+What must actually become true for the work to count as done, as opposed to prose that merely reads as if it were true. A verification gate passes against a truth object, not against a well-written paragraph.
+
+### Claim Ceilings
+
+Honest limits on what can be claimed:
+- "Complete" means verified to work end-to-end, not "looks finished"
+- "Correct" means checked against requirements, not "sounds right"
+- "Ready" means tested for the next stage, not "looks polished"
+
+Over-claiming (saying something is done when it's only drafted) is the most common trap in AI work. See `references/claim-ceiling-examples.md` for concrete examples in different contexts.
+
+### Closure Records
+
+For each atom, record what is done, what is missing, what is only partially true, and what is still unsafe to claim. A closure record preserves continuity across rounds so that unfinished work stays visible instead of being buried in prose — this is what stops a local step from being promoted into fake global completion.
+
+## Interaction with Other Skills
+
+### With WFGY-Method (Drift Control)
+
+- **Goal Compiler** structures the work (what to do)
+- **WFGY-Method** keeps you on track (why you're doing it)
+
+Use Goal Compiler first to atomize, then apply WFGY-Method while executing each atom.
+
+**Integration**: Goal Compiler's "verification gate" becomes a checkpoint for WFGY-Method's BBCR (bounded retry).
+
+### With Fifth-Dimension Engine (Problem Solving)
+
+- **Goal Compiler** specifies the problem clearly
+- **Fifth-Dimension Engine** solves/structures it
+- **Goal Compiler's verification gates** check the engine's output
+
+Use Goal Compiler to compile the problem statement, then dispatch to Fifth-Dimension Engine.
+
+**Integration**: Fifth-Dimension Engine's "route" output maps to Goal Compiler's task atoms and verification gates.
+
+## References
+
+See `references/` directory for:
+- `task-atomization.md` — how to break work into atoms
+- `verification-gates.md` — designing verification for each stage
+- `claim-ceiling-examples.md` — what "complete" actually means in different contexts
+- `skills/polaris-protocol/SKILL.md` — the Polaris Protocol tree root and state machine that wires this skill to Fifth-Dimension Engine and WFGY-Method
+
+## What This Is Not
+
+This skill does not:
+- Solve the problem (that's Fifth-Dimension Engine)
+- Control drift during execution (that's WFGY-Method)
+- Replace thinking (it enhances it by making structure visible)
+- Guarantee success (only guard against fake completion)
+- Claim to be the full WFGY 5.0 system (it is one public protocol component; the upstream engine is the main product surface)

package/skills/polaris-goal-compiler/references/claim-ceiling-examples.md

@@ -0,0 +1,54 @@
+# Claim Ceiling Examples in Polaris Goal Compiler
+
+A **claim ceiling** limits how strongly the assistant may describe completion. If only one local step is done, the assistant may not claim the whole task is complete. If verification is missing, it may not claim verified readiness.
+
+The point is not optimism or pessimism. It is that a local success should not be promoted into fake global completion.
+
+## The core rule
+
+| Claim word | What it may mean | What it must NOT mean |
+|---|---|---|
+| "Complete" | verified to work end-to-end | "looks finished" / prose exists |
+| "Correct" | checked against requirements | "sounds right" |
+| "Ready" | tested for the next stage | "looks polished" |
+| "Verified" | a check actually ran and passed | a check was imagined |
+| "Done" | closure record shows done + no open debt | the last visible step finished |
+
+## Worked examples by context
+
+### Coding repair
+
+- Atom A03 "Repair structure" is finished and the file compiles.
+- Claim ceiling: you may say "the structure is repaired and compiles." You may **not** yet say "the bug is fixed" until A04 (verify repair) passes.
+- If A04 is still blocked, saying "fixed" is a ceiling violation — it promotes a local step to global completion.
+
+### Documentation packaging
+
+- You wrote the release note (A06) but A04 (verify repair) never ran.
+- Claim ceiling: you may say "a draft release note exists." You may **not** say "release ready" — readiness requires the verification gate first.
+- This is exactly the upstream failure mode: writing the announcement before the repair is verified.
+
+### Research synthesis
+
+- You have three candidate lemmas but open debt on the fourth.
+- Claim ceiling: you may say "three of four lemmas supported." You may **not** say "the route is proven" while open debt remains.
+- Open debt must stay visible, not be silently folded into a "done."
+
+### Long multi-round planning
+
+- Round 3 finished one atom; rounds 4-7 are blocked upstream.
+- Claim ceiling: report round 3's closure record (done / missing / partial / unsafe). Do **not** summarize the whole plan as "on track" when blocked atoms are unresolved.
+- A closure record is what keeps the partial state honest across rounds.
+
+## How to use this file
+
+When writing any completion claim during a compiled task, ask:
+
+1. Which atom produced this result?
+2. Did its verification gate actually pass (truth object met)?
+3. Is there open debt or a partial/unsafe state I am skipping?
+4. Am I describing the local atom, or quietly promoting it to the whole task?
+
+If step 4 is "promoting," lower the claim to the atom's actual verified state. That is the claim ceiling doing its job.
+
+See `../SKILL.md` for the full Goal Compiler workflow, and `skills/polaris-protocol/SKILL.md` for how claim ceilings fit the Polaris Protocol state machine.

package/skills/polaris-goal-compiler/references/task-atomization.md

@@ -0,0 +1,67 @@
+# Task Atomization in Polaris Goal Compiler
+
+## What Makes an Atom
+
+A task atom is the smallest executable unit of work. It must satisfy all of:
+
+1. **Atomic** — Cannot be divided further without losing meaning
+2. **Completable** — Can be finished in one session/sprint
+3. **Verifiable** — Has clear entrance and exit criteria
+4. **Interdependent** — Has clear dependencies (blocks/is blocked by other atoms)
+
+## Examples
+
+### Good Atoms
+
+- "Write the type schema for the user entity" (clear scope, verifiable)
+- "Understand the regulatory requirements for PCI compliance" (finite scope, verifiable)
+- "Design the error recovery flow for transaction rollback" (clear domain, verifiable)
+
+### Bad Atoms
+
+- "Implement the payment system" (too large, vague)
+- "Fix bugs" (unmeasurable, not atomic)
+- "Make it better" (not verifiable)
+
+## How to Break Down a Goal
+
+Start with: "Goal: Build a payment microservice."
+
+1. **Identify phases**: Research → Design → Implement → Test → Deploy
+2. **For each phase, ask: What's the smallest piece?**
+   - Research: API options, compliance, existing solutions
+   - Design: Data model, interfaces, error handling
+   - Implement: Core logic, integrations, monitoring
+   - Test: Unit tests, integration tests, end-to-end
+   - Deploy: Staging validation, production rollout
+
+3. **For each piece, refine**: Can this be done in 1-2 days by one person? If not, break further.
+
+## Dependency Edges
+
+Each atom has:
+- **Blockers** — Things that must finish before this starts
+- **Unblocks** — Things that can't start until this finishes
+
+Example:
+```
+Research APIs (A1) 
+  ↓ unblocks
+Design interface (A2)
+  ↓ unblocks
+Implement core (A3)
+  ↓ unblocks
+Test integration (A4)
+  ↓ unblocks
+Deploy (A5)
+```
+
+## Active vs. Blocked
+
+Once atomized:
+- **Active work** = all blockers are done
+- **Blocked work** = at least one blocker is pending
+
+The Goal Compiler makes this explicit to prevent working on blocked items.
+
+See `POLARIS-SKILLS-GUIDE.md` for full integration.

package/skills/polaris-goal-compiler/references/verification-gates.md

@@ -0,0 +1,60 @@
+# Verification Gates in Polaris Goal Compiler
+
+## What a Gate Is
+
+A verification gate is a **check that must pass before moving to the next atom**. It prevents fake completion by requiring proof of actual readiness.
+
+## Types of Gates
+
+### Correctness Gate
+
+"Does the output match what was asked for?"
+
+- Atom: "Design the data model"
+- Gate: "Does the model represent all required entities and relationships?"
+
+### Completeness Gate
+
+"Is it complete enough for downstream work?"
+
+- Atom: "Research payment APIs"
+- Gate: "Have we identified all APIs that meet our compliance requirements?"
+
+### Assumption Validation Gate
+
+"Are hidden assumptions actually true?"
+
+- Atom: "Choose a database"
+- Gate: "Have we verified it can handle our projected scale? That we can operate it?"
+
+### Integration Gate
+
+"Will this work with the next piece?"
+
+- Atom: "Implement payment routing"
+- Gate: "Does the routing interface match what the integration team designed?"
+
+## Designing a Good Gate
+
+For an atom:
+1. **Ask**: What would make this atom "done"?
+2. **Ask again**: How do we know it's actually done, not just "looks done"?
+3. **That second answer is your gate.**
+
+## Bad Gates
+
+- "Complete" — unmeasurable
+- "Good enough" — too vague
+- "No obvious bugs" — not verifiable
+- Checking something trivial (wasting time)
+
+## Gate Failure
+
+If an atom fails its gate:
+- **Do not move forward** — you have incomplete work that looks complete
+- **Return to the atom** — what's actually missing?
+- **Fix or redefine** — either finish the work or redefine the atom scope
+
+This is where fake completion gets caught.
+
+See `POLARIS-SKILLS-GUIDE.md` for full integration.

package/skills/polaris-protocol/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: polaris-protocol
+description: WFGY 5.0 Polaris Protocol — the active flagship route from onestardao/WFGY. A two-layer reasoning system that compiles goals before execution and shoots complex problems into inspectable routes, with drift control throughout. This skill is the tree root: load it first, then dispatch its child skills as explicit transitions — polaris-goal-compiler (compile), fifth-dimension-engine (shoot), wfgy-method (drift control). Use for any complex, multi-step, high-stakes, or long-horizon task where premature completion or goal drift is a risk.
+license: MIT
+compatibility: Portable protocol; upstream released the Goal Compiler ChatGPT-first (teaser) and the Fifth-Dimension Engine as the main product surface. This skill wraps both plus WFGY-Method drift control into one discoverable entry point for any assistant or agent that loads skills.
+metadata:
+  origin: onestardao-wfgy-5.0-polaris-protocol
+  provenance: adapted-and-honest-reimplementation-not-verbatim
+---
+
+# WFGY 5.0 — Polaris Protocol (tree root)
+
+Polaris is the active public route of WFGY 5.0. The **Fifth-Dimension Engine** is the current main product surface; the **Polaris Goal Compiler** is the first public protocol component. **WFGY-Method** supplies the drift-control discipline that keeps the whole system aligned with the original goal.
+
+This skill is the **tree root**. It does not re-explain the children — it wires them into one state machine and tells you which child to dispatch at each step. Treat the three child skills as the transitions of the machine below.
+
+## The tree
+
+```
+polaris-protocol  (this skill — root / entry)
+├── polaris-goal-compiler   (COMPILE state)
+├── fifth-dimension-engine  (SHOOT state)
+└── wfgy-method             (DRIFT CONTROL — applies at every state)
+```
+
+Discoverable: each node is a standalone `SKILL.md` inside its own `skills/<skill-name>/` directory. This root is the entry point; the children are reached by explicit dispatch.
+
+## The state machine
+
+A skill tree can behave like a state machine. Each transition is an explicit skill dispatch (modeled on the `gm` skill's `transition`/`Skill(skill=...)` pattern): you do not narrate the next step, you **dispatch** it.
+
+### States
+
+| State | Meaning |
+|---|---|
+| `UNCOMPILED` | Raw human request, no structure yet. |
+| `COMPILED` | Goal Compiler emitted task atoms, dependencies, verification gates, claim ceilings, and a closure-record template. |
+| `SHOOTING` | A complex atom is being lifted by Fifth-Dimension Engine into a route. |
+| `EXECUTING` | An atom (routine, or the result of a route) is being carried out. |
+| `VERIFYING` | Output is checked against the atom's verification gate and against drift (ΔS, via WFGY-Method). |
+| `CLOSED` | Claim ceiling met, closure record written, atom done. |
+
+### Transitions (each is a dispatch)
+
+```
+UNCOMPILED --Skill(polaris-goal-compiler)--> COMPILED
+
+COMPILED --complex atom? Skill(fifth-dimension-engine)--> SHOOTING
+COMPILED --routine atom? execute directly---------------> EXECUTING
+
+SHOOTING --inspect route, then carry it out-----------> EXECUTING
+
+EXECUTING --Skill(wfgy-method) drift + gate check----> VERIFYING
+
+VERIFYING --gate pass + claim ceiling honored--------> CLOSED
+VERIFYING --gate fail / drift --> BBCR checkpoint ----> COMPILED (re-compile or re-shoot)
+
+CLOSED --next atom------------------------------------> COMPILED
+```
+
+`wfgy-method` is not a single transition — it is the drift-control observer attached to **every** state. Before any step that could have drifted, dispatch it and read the result.
+
+## Canonical syntax (pro-rata — use exactly this)
+
+- **Compile first. Execute one active atom. Verify before unlock. Claim only what is supported.** (Goal Compiler)
+- **shoot + [your problem]** — the Fifth-Dimension Engine interface. Examples: `shoot + Seven Millennium Problems`, `shoot + Death + AI`, `shoot + should I quit my job`.
+- **ΔS = 1 − cos(I, G)** — drift between current state (I) and goal (G). Without a real embedding call, ΔS is a qualitative label ("ΔS looks high here"), never a computed decimal — unless a real `similarity` verb is available (see WFGY-Method).
+
+"Compile first. Then shoot." is the spine of the whole protocol.
+
+## How to run a task through the tree
+
+1. You are at `UNCOMPILED`. Dispatch `Skill(skill="polaris-goal-compiler")`. It returns atoms, gates, and claim ceilings -> `COMPILED`.
+2. For each active atom: ask "complex or routine?"
+   - **Routine** -> execute directly -> `VERIFYING`.
+   - **Complex** -> dispatch `Skill(skill="fifth-dimension-engine")` -> `SHOOTING` -> inspect the route -> `EXECUTING` -> `VERIFYING`.
+3. At `VERIFYING`, dispatch `Skill(skill="wfgy-method")` to check drift and apply the atom's verification gate.
+   - Pass + claim ceiling honored -> `CLOSED` -> next atom (back to `COMPILED`).
+   - Fail or drift -> BBCR checkpoint, re-compile or re-shoot (back to `COMPILED`).
+4. When all atoms are `CLOSED`, the task is done — and only then may you claim completion.
+
+## What this tree is not
+
+- It is not a single prompt. It is a set of skills you dispatch in sequence.
+- It does not guarantee correctness. It makes fake completion and silent drift harder to hide.
+- It does not replace verification, tests, sources, or expertise. The verification gate only makes verification *visible*.
+- It does not claim to be the full private WFGY 5.0 engine. Goal Compiler and WFGY-Method are public protocol components; the Fifth-Dimension Engine is the current main public surface.
+
+## Children (dispatch these)
+
+- `polaris-goal-compiler` — compile the goal into atoms, gates, claim ceilings.
+- `fifth-dimension-engine` — shoot a complex atom into a structured route.
+- `wfgy-method` — hold drift control across every state.
+
+For the full DAG, integration workflows, and mismatch detection, see `../POLARIS-SKILLS-GUIDE.md`.

package/skills/wfgy-method/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: wfgy-method
-description: Applies WFGY (Wan Fa Gui Yi), a portable reasoning discipline for reducing drift and incoherence across multi-step agent work, adapted from onestardao/WFGY's core mechanism. Compares each step against the stated goal, considers more than one approach before committing to ambiguous or high-stakes decisions, and checkpoints before risky steps so it can revert and bounded-retry instead of compounding a mistake. Records durable lessons in this project so future sessions inherit them. Use when starting any non-trivial multi-step task, when a task risks losing track of its original goal over many steps, when facing a decision with real alternatives worth comparing, or when the agent notices it has contradicted itself or gone in circles and needs a disciplined way to recover. Distinct from `gm-continue`: that skill is the specific post-`gm`-COMPLETE remaining-work check (a narrow, mechanical PRD scan); this skill is the general drift-recovery discipline `gm-continue` itself invokes when a `gm` walk keeps hitting the same gap across repeat cycles -- not a substitute for `gm-continue`'s own check.
+description: Applies WFGY (Wan Fa Gui Yi), a portable reasoning discipline for reducing drift and incoherence across multi-step agent work, adapted from onestardao/WFGY's core mechanism. Compares each step against the stated goal, considers more than one approach before committing to ambiguous or high-stakes decisions, and checkpoints before risky steps so it can revert and bounded-retry instead of compounding a mistake. Records durable lessons in this project so future sessions inherit them. Use when starting any non-trivial multi-step task, when a task risks losing track of its original goal over many steps, when facing a decision with real alternatives worth comparing, or when the agent notices it has contradicted itself or gone in circles and needs a disciplined way to recover. Distinct from `gm-continue`: that skill is the post-`gm`-COMPLETE remaining-work check; this skill is the general drift-recovery discipline `gm-continue` invokes when a `gm` walk repeats the same gap -- not a substitute for its check.
 license: MIT
 compatibility: Designed for Claude Code. No external services, embedding models, or network access required for the core discipline.
 metadata: