godpowers 1.0.0 → 1.6.1

package/CHANGELOG.md

@@ -5,11 +5,112 @@ All notable changes to Godpowers will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [1.6.1] - 2026-05-15
+
+Release hardening patch. Keeps the 1.6 domain precision surface stable while
+making package publication, release checks, and CI verification harder to drift.
+
+### Added
+- Added `npm run release:check`, which runs the full test suite, audit checks,
+  and package contents verification.
+- Added `scripts/check-package-contents.js` to assert that the npm payload
+  includes load-bearing runtime files and excludes local-only development files.
+- Added `docs/RELEASE-CHECKLIST.md` for versioning, verification, package
+  surface, tag, npm provenance, and post-release cleanup.
+- Added an explicit plan-mode E2E smoke test for the `/god-mode` full-arc
+  workflow against the `todo-app` fixture.
+
+### Changed
+- CI now uses `npm ci`, runs audit checks, runs the E2E smoke path explicitly,
+  and keeps package checks aligned with local npm scripts.
+- Test documentation now describes the current runtime and E2E smoke coverage
+  instead of stale scaffold-only plans.
+- Runtime and reference README files now describe the implemented modules and
+  reference files instead of placeholder future work.
+- Package tarballs are ignored by git, and package contents checks reject
+  generated tarballs.
+- The release script now pushes the git tag and relies on the tag-triggered
+  GitHub Actions npm publish workflow for provenance.
+
+### Guardrails
+- This patch does not add new slash commands, agents, workflows, recipes, or
+  schemas.
+- The 1.6 domain glossary behavior remains unchanged.
+- Future npm publishes should use the tag-triggered GitHub workflow unless a
+  documented emergency requires a manual fallback.
+
+## [1.6.0] - 2026-05-15
+
+Domain precision release. Adds a Godpowers-native vocabulary layer so fuzzy or
+overloaded project language is clarified before it enters PRD, architecture,
+roadmap, stack, docs, or lint artifacts.
+
+### Added
+- Added `.godpowers/domain/GLOSSARY.md` as preparation context for canonical
+  terms, avoided aliases, relationships, example dialogue, source notes, and
+  unresolved ambiguities.
+- Added `templates/DOMAIN-GLOSSARY.md`.
+- Added domain glossary have-nots DG-01 through DG-05.
+- Added mechanical linter coverage for missing avoided aliases,
+  implementation details in glossaries, unresolved ambiguities without owner or
+  due date, relationships using undefined terms, and behavior-heavy
+  definitions.
+
+### Changed
+- `/god-discuss` now runs domain grilling during next-phase scoping.
+- `god-explorer` now inspects code or docs before asking the user when repo
+  evidence can answer a domain question.
+- PM, architect, roadmapper, stack selector, and docs writer agents now read
+  `.godpowers/domain/GLOSSARY.md` when present.
+- Architecture guidance now limits ADR creation to choices that are hard to
+  reverse, surprising without context, and based on a real tradeoff.
+- Public release metadata, package version, and README badge now point to
+  1.6.0.
+- Release history now has a `v1.6.0` git tag matching the published npm
+  package.
+
+### Guardrails
+- The domain glossary is preparation context only. It does not replace PRD,
+  ARCH, ROADMAP, STACK, docs, or Pillars files.
+- The glossary stores domain language, not implementation details or technical
+  scratch notes.
+- Unresolved vocabulary ambiguity must remain explicit as an open question with
+  owner and due date.
+
+## [1.5.0] - 2026-05-14
+
+Preflight intake release. Adds a read-only front gate before Godpowers applies
+arc-ready direction, pillars scoring, archaeology, reconstruction, or refactor
+work to projects with prior context.
+
+### Added
+- Added `/god-preflight`, a read-only intake audit that writes
+  `.godpowers/preflight/PREFLIGHT.md`.
+- Added preflight scoring lenses for arc-ready, pillars, Godpowers,
+  ready-suite, refactor risk, and suite signals.
+- Added preflight mode to `god-auditor`.
+
+### Changed
+- Brownfield workflows now run preflight before archaeology.
+- Bluefield workflows now run org context, then preflight, before the
+  constrained arc begins.
+- `/god-mode --yolo` now auto-runs preflight for brownfield and bluefield,
+  follows the safest recommended route, and logs that choice to
+  `.godpowers/YOLO-DECISIONS.md`.
+- Public release metadata, package version, and README badge now point to
+  1.5.0.
+
+### Guardrails
+- Greenfield workflows skip preflight unless explicitly requested.
+- Preflight is read-only and does not create PRDs, architecture docs, pillar
+  reports, refactor patches, or source-code changes.
+- `--yolo` still pauses for Critical security findings and impossible preflight
+  routing contradictions.
+
 ## [1.0.0] - 2026-05-14
 
-Public adoption freeze release. Promotes the shipped Godpowers surface to the
-stable 1.0 line so real users can adopt it without the project moving under
-them.
+Stable 1.0 release. Promotes the shipped Godpowers surface to the stable 1.0
+line so real users can adopt it without the project moving under them.
 
 ### Added
 - Added 1.0 release notes and public adoption language.
@@ -21,8 +122,8 @@ them.
 - Generated `AGENTS.md` now names Godpowers first, then explains that Pillars is
   the native project context layer and `.godpowers/` remains the workflow state
   and artifact layer.
-- Release documentation now frames the project as stable for public adoption
-  freeze rather than pre-launch expansion.
+- Release documentation now frames the project as stable for real-world use
+  rather than pre-launch expansion.
 - The release script now checks the installer version through `package.json`,
   matching the dynamic installer implementation.
 

package/README.md

@@ -2,7 +2,7 @@
 
 [![CI](https://github.com/aihxp/godpowers/actions/workflows/ci.yml/badge.svg)](https://github.com/aihxp/godpowers/actions/workflows/ci.yml)
 [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](LICENSE)
-[![Version](https://img.shields.io/badge/version-1.0.0-blue)](CHANGELOG.md)
+[![Version](https://img.shields.io/badge/version-1.6.1-blue)](CHANGELOG.md)
 [![npm](https://img.shields.io/npm/v/godpowers.svg)](https://www.npmjs.com/package/godpowers)
 
 **Ship fast. Ship right. Ship everything. Ship accountably.**
@@ -12,9 +12,9 @@ idea to hardened production. It runs as **slash commands inside your AI coding
 tool** (Claude Code, Codex, Cursor, etc.) that orchestrate **specialist agents**
 in fresh contexts to do the work.
 
-Version 1.0.0 is the public adoption freeze: the command, agent, workflow,
-schema, artifact, and native Pillars context surfaces are stable while real
-projects shape the next release train.
+Version 1.6.1 hardens the release path around the 1.6 domain precision layer:
+release checks now cover tests, audit, package contents, E2E smoke, and npm
+payload verification before publishing.
 
 It fuses four disciplines into one unified workflow:
 
@@ -23,6 +23,8 @@ It fuses four disciplines into one unified workflow:
   truth before commands touch code.
 - **Artifact discipline** - every sentence in every document is a labeled
   decision, hypothesis, or open question. Mechanically verified failure modes.
+- **Domain precision** - fuzzy or overloaded project language is challenged,
+  resolved, and stored in a domain glossary before it contaminates planning.
 - **Execution engine** - fresh-context agents in parallel waves with atomic
   commits. No context rot. No sequential bottlenecks.
 - **Quality immune system** - TDD enforcement, two-stage code review (spec
@@ -118,6 +120,7 @@ when you open a new session in a Godpowers project.
 | `/god-launch` | Launch (gated on harden) | god-launch-strategist |
 | `/god-harden` | Adversarial security review | god-harden-auditor |
 | `/god-status` | Re-derive state from disk | (built-in) |
+| `/god-preflight` | Read-only intake audit before arc-ready and pillars | god-auditor |
 | `/god-audit` | Score artifacts against have-nots | god-auditor |
 | `/god-debug` | 4-phase systematic debug | god-debugger |
 | `/god-review` | Two-stage code review | god-spec-reviewer + god-quality-reviewer |
@@ -204,6 +207,7 @@ Skill updates:   PROGRESS.md
 ```
 .godpowers/PROGRESS.md         Cross-tier progress ledger
 .godpowers/prd/PRD.md          Product Requirements Document
+.godpowers/domain/GLOSSARY.md  Domain vocabulary and resolved ambiguities
 .godpowers/arch/ARCH.md        System Architecture
 .godpowers/arch/adr/           Architecture Decision Records
 .godpowers/roadmap/ROADMAP.md  Sequenced Roadmap
@@ -288,9 +292,9 @@ Pi. T3 Code inherits from the underlying agent (Codex / Claude / OpenCode).
 
 - [Getting Started](docs/getting-started.md)
 - [Concepts](docs/concepts.md)
-- [Command reference (all 105 skills + 39 agents)](docs/reference.md)
+- [Command reference (all 106 skills + 39 agents)](docs/reference.md)
 - [Roadmap](docs/ROADMAP.md)
-- [1.0 Release Notes](RELEASE.md)
+- [1.5 Release Notes](RELEASE.md)
 - [Changelog](CHANGELOG.md)
 - [Inspiration](INSPIRATION.md)
 

package/RELEASE.md

@@ -1,15 +1,15 @@
-# Godpowers 1.0.0 Release
+# Godpowers 1.6.1 Release
 
-Date: 2026-05-14
+Date: 2026-05-15
 
-Godpowers 1.0.0 is the public adoption freeze. The goal of this release is not
-to add another layer of capability, but to stop the ground from moving so real
-projects can try the system, report friction, and shape the next cycle from
-evidence.
+Godpowers 1.6.1 hardens the release and package path around the 1.6 domain
+precision release. The goal of this patch is to make tests, audit checks,
+package contents, E2E smoke coverage, npm publishing, and GitHub release
+metadata easier to verify before anything reaches users.
 
 ## What is stable
 
-- 105 slash commands
+- 106 slash commands
 - 39 specialist agents
 - 13 executable workflows
 - 36 intent recipes
@@ -19,24 +19,41 @@ evidence.
 - Core schemas: intent, state, events, workflow, routing, recipes, extension
   manifests
 - Extension pack compatibility range for the 1.x line
+- Domain precision through `.godpowers/domain/GLOSSARY.md` and DG-01 through
+  DG-05 checks
 
-## What 1.0 means
+## What is new
 
-Godpowers is the product users invoke. Pillars is the native project context
-layer Godpowers installs, reads, and keeps current.
+- `npm run release:check` now runs tests, audit checks, and package contents
+  verification as a single pre-release gate.
+- `npm run pack:check` now asserts required npm payload files and rejects
+  local-only files instead of relying on visual dry-run output.
+- CI now installs with `npm ci`, runs audit checks, runs E2E smoke explicitly,
+  and keeps package validation tied to local scripts.
+- `docs/RELEASE-CHECKLIST.md` documents the expected release flow, tag flow,
+  npm provenance path, and post-release verification.
+- `/god-mode` full-arc has a plan-mode E2E smoke test that verifies 10 jobs,
+  7 waves, and a generated `.godpowers/runs/.../plan.yaml` artifact.
+- Stale placeholder docs for runtime libraries, references, and test strategy
+  now describe the implemented system.
 
-New projects get Godpowers-branded `AGENTS.md` protocol text, always-loaded
-`agents/context.md` and `agents/repo.md`, and routed pillar files for stack,
-architecture, data, API, UI, auth, quality, deploy, and observe concerns.
+## What 1.6.1 means
 
-Existing `.godpowers` projects are Pillar-ized on resume or sync. Durable
-signals from PRD, architecture, stack, roadmap, build, deploy, observe, harden,
-design, and product artifacts are linked back into relevant pillars.
+Godpowers 1.6.1 does not expand the public command surface. It tightens the
+release discipline around the existing surface so local checks, CI checks, npm
+payload contents, git tags, and GitHub release metadata agree.
 
-## Freeze policy
+The domain glossary remains preparation context. PRD, ARCH, ROADMAP, STACK,
+docs, and Pillars files still carry durable decisions for their own domains.
 
-During the adoption freeze, do not add new command families, change schema
-formats, or rename public artifacts without evidence from real use.
+## Stability policy
+
+During the 1.x stability window, do not add broad new command families, change
+schema formats, or rename public artifacts without evidence from real use.
+
+The `v1.6.1` git tag points to the release commit that matches the npm
+`godpowers@1.6.1` package. Public publishes should prefer the tag-triggered
+GitHub workflow so npm provenance, git history, and release notes stay aligned.
 
 Allowed changes:
 
@@ -44,7 +61,7 @@ Allowed changes:
 - Documentation clarity
 - Test coverage for frozen behavior
 - Compatibility fixes for supported AI coding tools
-- Small fixes that make existing 1.0 behavior work as documented
+- Small fixes that make existing 1.x behavior work as documented
 
 Deferred changes:
 
@@ -56,6 +73,5 @@ Deferred changes:
 
 ## Adoption ask
 
-Use Godpowers on real projects and report what breaks, what feels too heavy,
-what feels magical, and what needs sharper defaults. The next release train
-should be shaped by those reports rather than by more speculative surface area.
+Run `npm run release:check` before publishing changes. Report any release path
+step that still depends on memory, manual inspection, or local machine state.

package/SKILL.md

@@ -60,6 +60,13 @@ Every piece of code passes two independent reviews:
 
 Both must pass. Failing either blocks the commit.
 
+### 8. Domain Precision
+Before fuzzy language enters PRD, architecture, roadmap, stack, or docs
+artifacts, challenge it against project vocabulary. If a code or doc scan can
+answer a question, inspect first. When a term is resolved, record it in
+`.godpowers/domain/GLOSSARY.md` with canonical spelling, avoided aliases,
+relationships, and any unresolved ambiguity.
+
 ---
 
 ## Operating Modes
@@ -469,6 +476,8 @@ See individual tier sections above.
   PROGRESS.md          # Cross-tier progress ledger
   prd/
     PRD.md             # Product Requirements Document
+  domain/
+    GLOSSARY.md        # Domain vocabulary and resolved ambiguities
   arch/
     ARCH.md            # System Architecture
     adr/               # Architecture Decision Records

package/agents/god-architect.md

@@ -23,6 +23,8 @@ Before starting:
   context.
 - Optional: `.godpowers/prep/IMPORTED-CONTEXT.md` may exist as preparation
   context.
+- Optional: `.godpowers/domain/GLOSSARY.md` may exist as domain preparation
+  context.
 - Optional: `.godpowers/design/DESIGN.md` and
   `.godpowers/design/PRODUCT.md` may exist as early product-experience
   preparation.
@@ -42,6 +44,12 @@ If `.godpowers/prep/IMPORTED-CONTEXT.md` exists, read its technical signals
 before drafting ARCH. Use imported architecture, integration, risk, and stack
 constraints as hypothesis-level input only.
 
+If `.godpowers/domain/GLOSSARY.md` exists, read it before drafting ARCH. Use
+canonical terms for entities, bounded contexts, services, data ownership,
+trust boundaries, and ADR titles. Treat unresolved glossary ambiguities as
+architecture `[OPEN QUESTION]` entries when they affect ownership, integration
+contracts, state transitions, or external boundaries.
+
 If `.godpowers/design/DESIGN.md` or `.godpowers/design/PRODUCT.md` exists,
 read them before drafting ARCH. Use early design to identify user-facing
 surfaces, routes, component boundaries, state flows, accessibility needs, and
@@ -49,12 +57,18 @@ where architecture must preserve product experience.
 
 Rules:
 - Do not let imported context override PRD NFRs or Godpowers state.
+- Do not let glossary language override PRD NFRs or Godpowers state.
 - Convert useful imported signals into ADR context, tradeoffs, or open
   questions.
+- Convert useful glossary signals into entity names, relationship language,
+  ADR context, bounded context names, or open questions.
 - Convert useful design signals into containers, ADR context, UI boundary
   descriptions, or open questions.
 - If imported context conflicts with the PRD, the PRD wins and the conflict
   becomes an `[OPEN QUESTION]`.
+- If glossary language conflicts with PRD or code evidence, preserve the
+  stronger Godpowers artifact or direct code evidence and add an
+  `[OPEN QUESTION]`.
 - If ARCH or ADRs create durable architectural truth, plan updates for
   `agents/arch.md` and related pillars. In `--yolo`, apply those updates and
   log them to `.godpowers/YOLO-DECISIONS.md`.
@@ -73,7 +87,9 @@ ADRs to `.godpowers/arch/adr/`.
 2. **Container Diagram (C4 L2)** - major runtime containers with single clear
    responsibilities. No shared responsibility without justification.
 
-3. **Architecture Decision Records (ADRs)** - one per significant decision:
+3. **Architecture Decision Records (ADRs)** - one per significant decision
+   that is hard to reverse, surprising without context, and the result of a
+   real tradeoff:
    - Context (what forced the decision)
    - Decision (what was chosen)
    - Rationale (why this over alternatives)

package/agents/god-auditor.md

@@ -1,17 +1,18 @@
 ---
 name: god-auditor
 description: |
-  Scores existing artifacts against all have-nots. Builds nothing. Reports
-  pass/fail per have-not with prioritized remediation. Used by /god-audit and
-  by orchestrator to verify gate checks.
+  Runs preflight intake, scores existing artifacts against all have-nots, and
+  reports pass/fail per have-not with prioritized remediation. Builds nothing.
+  Used by /god-preflight, /god-audit, and by orchestrator to verify gate checks.
 
-  Spawned by: /god-audit, god-orchestrator (gate checks)
+  Spawned by: /god-preflight, /god-audit, god-orchestrator (gate checks)
 tools: Read, Bash, Grep, Glob
 ---
 
 # God Auditor
 
-Score artifacts. Build nothing. Report what fails and why.
+Score artifacts or run preflight intake. Build nothing. Report what fails and
+why.
 
 ## Process
 
@@ -31,7 +32,9 @@ Score artifacts. Build nothing. Report what fails and why.
 4. If running for orchestrator gate check: return verdict only (any
    error from mechanical pass = FAIL; any critical interpretive = FAIL).
 5. If running for /god-audit: produce full report combining both passes.
-6. If running with `mode: greenfield-simulation`, do not build anything.
+6. If running with `mode: preflight`, do not run the artifact linter as the
+   main task. Inspect the repo and write `.godpowers/preflight/PREFLIGHT.md`.
+7. If running with `mode: greenfield-simulation`, do not build anything.
    Simulate the canonical Godpowers greenfield arc and compare it against the
    current project evidence or org constraints.
 
@@ -152,6 +155,64 @@ Overall: 85%
 For gate check (called by orchestrator): return PASS/FAIL with first failure
 only (orchestrator wants speed, not full report).
 
+For preflight, write `.godpowers/preflight/PREFLIGHT.md`:
+
+```markdown
+# Godpowers Preflight
+
+Date: [timestamp]
+Target: [path]
+
+## Snapshot
+- DECISION: Project type is [type] because [files or commands].
+- HYPOTHESIS: Primary runtime appears to be [runtime] because [evidence].
+- OPEN QUESTION: [question that blocks confident planning].
+
+## Readiness Scores
+| Lens | Score | Evidence | Main blocker |
+|---|---:|---|---|
+| Arc-ready | [0-100] | [specific files or absence] | [blocker] |
+| Pillars | [0-100] | [specific files or absence] | [blocker] |
+| Godpowers | [0-100] | [specific files or absence] | [blocker] |
+| Ready-suite | [0-100 or N/A] | [specific files or absence] | [blocker] |
+
+## Inventory
+- DECISION: [thing found] at `[path]`.
+- HYPOTHESIS: [thing inferred] from `[path]`.
+
+## Blockers Before Arc-Ready
+1. DECISION: [blocker].
+   Evidence: `[path]` or missing `[path]`.
+   Next move: [specific command or artifact].
+
+## Pillar Weaknesses
+1. DECISION: [weakness].
+   Evidence: `[path]` or missing `[path]`.
+   Impact: [why it matters].
+
+## Refactor Risk
+1. HYPOTHESIS: [risk].
+   Evidence: `[path]`.
+   Avoid until: [needed proof or test].
+
+## Recommended Sequence
+1. DECISION: Run [next command or task] first because [reason].
+2. DECISION: Run [next command or task] second because [reason].
+3. DECISION: Defer [task] until [condition].
+```
+
+Preflight rules:
+- Inspect package manifests, lockfiles, build files, test config, CI config,
+  source layout, entry points, docs, ADRs, env examples, AGENTS.md, deploy
+  signals, observability signals, and ownership signals.
+- Brownfield mode inspects existing codebase shape and refactor risk.
+- Bluefield mode inspects org context, sibling conventions, shared packages,
+  deployment expectations, and quality bars.
+- Greenfield mode skips preflight unless explicitly requested.
+- Tie every score to repo evidence.
+- Prefer "unknown" over confident invention.
+- Do not modify application code or canonical planning artifacts.
+
 For greenfield simulation audit, write
 `.godpowers/audit/GREENFIELD-SIMULATION.md`:
 

package/agents/god-docs-writer.md

@@ -20,8 +20,10 @@ Write docs that don't lie.
 Identify:
 - Existing docs (README, CONTRIBUTING, API docs, comments, etc.)
 - Code surface (public APIs, exported functions, CLI commands, env vars)
+- `.godpowers/domain/GLOSSARY.md` if present
 - Doc gaps: code with no docs
 - Doc drift: docs claiming things that aren't true
+- Term drift: docs using avoided aliases or conflicting meanings
 
 ### 2. Verify Existing Docs Against Code
 
@@ -29,6 +31,8 @@ For every claim in existing docs:
 - Find the corresponding code
 - Verify the claim matches reality
 - Flag drift (e.g., README says `npm start` but package.json has `npm run dev`)
+- If `.godpowers/domain/GLOSSARY.md` exists, verify docs use canonical terms
+  unless a non-canonical term is quoted from an external source.
 
 ### 3. Write or Update
 
@@ -95,6 +99,7 @@ Date: [ISO 8601]
 Docs FAIL if:
 - Any claim contradicts the code
 - Substitution test passes (reads generic)
+- Avoided glossary aliases appear as current project language
 - Examples don't actually run
 - Runbooks have never been executed
 - API docs out of sync with function signatures

package/agents/god-explorer.md

@@ -14,6 +14,10 @@ tools: Read, Write, Bash, WebSearch
 You are a Socratic interviewer. Your job is NOT to write a PRD or architecture.
 Your job is to help the user clarify what they actually want to build.
 
+When spawned by `/god-discuss` with focus="next-phase-scoping", you also run a
+domain grilling session. The goal is to sharpen project language before it
+enters PRD, architecture, roadmap, stack, or docs artifacts.
+
 ## Process
 
 ### Phase 1: Listen
@@ -22,9 +26,19 @@ Read what the user gave you. Identify:
 - Stated solution (often conflated with the problem)
 - Stated audience
 - Implicit assumptions
+- Existing project-specific terms
+- Terms that appear overloaded, vague, or inconsistent
+
+Read `.godpowers/domain/GLOSSARY.md` if it exists. If it does not exist, create
+it lazily from `templates/DOMAIN-GLOSSARY.md` only after the first term or
+ambiguity is resolved.
+
+If code or docs can answer a question, inspect them before asking the user.
+Prefer repo evidence over a human question when the evidence is direct.
 
 ### Phase 2: Probe
-Ask targeted questions, NOT open-ended ones:
+Ask targeted questions one at a time, NOT open-ended ones. Provide your
+recommended answer with each question:
 
 NOT: "Tell me more about your users."
 YES: "You said 'developers'. Are these developers building products, or
@@ -40,6 +54,15 @@ Surface hidden assumptions:
 - "You assume users will pay $X. What's the next-best alternative they'd
      pay $0 for?"
 
+Challenge domain language:
+- If a term conflicts with `.godpowers/domain/GLOSSARY.md`, call it out
+  immediately and ask which meaning should win.
+- If a term is fuzzy or overloaded, propose one canonical term and list aliases
+  to avoid.
+- If relationships between terms matter, test them with concrete edge cases.
+- Record resolved terms, avoided aliases, relationships, and ambiguities in
+  `.godpowers/domain/GLOSSARY.md` as they are resolved.
+
 ### Phase 3: Reframe
 Present 2-3 alternative framings of the same problem:
 
@@ -63,10 +86,15 @@ Based on the conversation:
 - Which framing has the strongest signal?
 - What's the single most important question to answer next?
 - What can be deferred until V2?
+- Which canonical terms should downstream agents use?
+- Which ambiguities block PRD, architecture, roadmap, stack, or docs work?
+- Whether any decision deserves an ADR because it is hard to reverse,
+  surprising without context, and the result of a real tradeoff
 
 ## Output
 
-Write `.godpowers/explore/[topic-slug].md`:
+For open-ended `/god-explore`, write `.godpowers/explore/[topic-slug].md`.
+For `/god-discuss`, write `.godpowers/discussions/[topic-slug].md`.
 
 ```markdown
 # Explored: [Topic]
@@ -84,6 +112,12 @@ Date: [timestamp]
 - Q: [...] -> A: [...]
 - Q: [...] -> A: [...]
 
+## Domain language resolved
+- [DECISION] [Canonical term]: [definition]. Avoid: [aliases].
+
+## Domain ambiguities remaining
+- [OPEN QUESTION] [Ambiguity]. Owner: [name]. Due: [date].
+
 ## Alternative framings considered
 [Framings A, B, C with pros/cons]
 
@@ -99,6 +133,8 @@ Date: [timestamp]
 - User has clarity (or confirms one framing as the direction)
 - Output document exists with the seed for /god-prd
 - Open questions explicitly listed (not buried in prose)
+- Resolved domain terms are captured in `.godpowers/domain/GLOSSARY.md`
+- Glossary updates contain no implementation details
 
 ## NOT Your Job
 

package/agents/god-orchestrator.md

@@ -634,15 +634,25 @@ Never pause for:
 Pass `--yolo` to every spawned specialist agent. They will auto-pick the
 default at every pause condition and log the decision to YOLO-DECISIONS.md.
 
-Auto-resolve all five pause categories EXCEPT one:
+For brownfield and bluefield, run `/god-preflight` automatically before
+archaeology, reconstruction, arc-ready, pillars, or refactor work when
+`.godpowers/preflight/PREFLIGHT.md` is absent. Treat the preflight report as
+the routing baseline. Under `--yolo`, auto-follow the safest recommended next
+route and log the choice to `.godpowers/YOLO-DECISIONS.md`.
+
+Auto-resolve all pause categories EXCEPT:
 
 **Critical security findings ALWAYS pause, even with --yolo.**
 
+**Impossible preflight routing contradictions pause, even with --yolo.**
+
 Rationale: shipping with a known Critical vulnerability is a category of risk
-that should never be auto-accepted. If god-harden-auditor returns Critical
-findings, --yolo does NOT skip. Pause for human resolution.
+that should never be auto-accepted. A preflight contradiction means the repo
+evidence does not support any safe next route. If god-harden-auditor returns
+Critical findings, or preflight cannot choose between mutually exclusive
+routes from evidence, --yolo does NOT skip. Pause for human resolution.
 
-This is the only --yolo carve-out. All other pauses are auto-resolved with
+These are the only --yolo carve-outs. All other pauses are auto-resolved with
 the agent's documented default, and all repairable mechanical failures are
 handled by the autonomous repair loop before the arc can be called complete.
 
@@ -974,6 +984,16 @@ Review and revise any that don't match your intent.
 
 Append to YOLO-DECISIONS.md every time --yolo would have paused.
 
+For preflight auto-routing, append:
+
+```markdown
+## Tier 0 / Preflight
+- Pause: Select first brownfield or bluefield route from preflight findings
+- Auto-picked: [command]
+- Reason: [preflight evidence and safest-sequence rationale]
+- Timestamp: [ISO 8601]
+```
+
 ## Have-Nots Reference
 
 The canonical have-nots catalog lives at `references/HAVE-NOTS.md` (115 named

package/agents/god-pm.md

@@ -44,13 +44,23 @@ If `.godpowers/prep/IMPORTED-CONTEXT.md` exists, read it before drafting the
 PRD. Use product signals from GSD, Superpowers, BMAD, or similar systems as
 hypothesis-level input only.
 
+If `.godpowers/domain/GLOSSARY.md` exists, read it before drafting the PRD.
+Use canonical terms from the glossary in problem statements, target users,
+requirements, no-gos, and open questions. Treat unresolved glossary
+ambiguities as PRD `[OPEN QUESTION]` entries when they affect scope,
+acceptance criteria, or success metrics.
+
 Rules:
 - Do not copy imported text wholesale into the PRD.
 - Do not treat imported context as source of truth.
+- Do not let glossary terms override user intent or completed Godpowers
+  artifacts.
 - Convert relevant imported product signals into `[HYPOTHESIS]` requirements,
   success metrics, scope notes, no-gos, or open questions.
 - If imported context conflicts with user intent or existing Godpowers state,
   preserve the Godpowers state and add an `[OPEN QUESTION]`.
+- If the glossary conflicts with user intent or existing Godpowers state,
+  preserve the Godpowers state and add an `[OPEN QUESTION]`.
 - In PRD rationale, mention the source only when it materially changes a
   requirement.
 - If the PRD creates durable product truth, plan corresponding updates for