genesis-compiler 1.2.17 → 1.2.19

package/README.md

@@ -13,6 +13,7 @@ interaction.
 ```text
 genesis/
   blueprint.md       non-technical product intent
+  engineering.md     selected engineering profile and project-specific requirements
   stack.md           selected technology guidance, verification, declarations, and opaque extensions
   stack/             optional per-component Description, Guidance, Adoption, Post-change, and Deslop customization
   program/           concise explanations grouped into conceptual subsystems
@@ -104,8 +105,8 @@ assistant runs `genesis adopt`; the person need not know Genesis terminology or
 type a command. It never runs adoption without approval and does nothing in an
 empty or already-adopted project.
 
-`genesis init` creates an empty Blueprint, an empty optional Stack, three
-project Agent Skills, and project-local Codex hooks. The skills are ordinary
+`genesis init` creates an empty Blueprint, a focused engineering approach, an
+empty optional Stack, three project Agent Skills, and project-local Codex hooks. The skills are ordinary
 [Agent Skills](https://agentskills.io): `genesis-project`, `genesis-program`,
 and `genesis-deslop`, each with standard `SKILL.md` and `agents/openai.yaml`
 metadata. Open `/hooks` once in Codex to review and trust the hooks. After
@@ -136,6 +137,54 @@ Genesis never overwrites an unmanaged skill and preserves locally modified
 managed skills. Run `genesis init` after manually editing `genesis/stack.md`,
 or use `genesis stack add`, to synchronize selected skills.
 
+## Engineering approach
+
+Every profile inherits one universal rule: implementation must remain easy to
+reason about and be the smallest targeted change that satisfies current
+requirements. Speculative abstractions, infrastructure, compatibility paths,
+distributed patterns, cryptography, and similarly advanced machinery are not
+allowed. When a concrete requirement makes material complexity necessary, the
+agent must explain why a direct design is insufficient and ask before writing
+that complexity.
+
+The installed, versioned profile descriptions live in
+`profiles/engineering/*.md`. Straight Genesis users can inspect and select them
+without editing Markdown grammar:
+
+```bash
+genesis engineering list
+genesis engineering show focused.v1
+genesis engineering set durable.v1
+```
+
+`focused.v1` is the default for small direct product work. `durable.v1` adds
+explicit compatibility and operational care for long-lived products.
+`high-assurance.v1` adds risk-driven security and reliability discipline. None
+of them mandates complexity without a concrete need.
+
+The selection and any explicit project overrides are portable source:
+
+```markdown
+# Engineering approach
+
+## Profile
+
+- `focused.v1`
+
+## Project requirements
+
+- Nothing.
+```
+
+People may edit `## Project requirements` to name obligations the presets do
+not capture, including a specific organizational, compliance, cryptographic,
+or scale constraint. `genesis engineering set` changes only the profile and
+preserves those requirements. Generated prompts, path-focused context, Codex
+session guidance, Post-change work, and Deslop all receive the effective
+approach. A project upgraded from an older Genesis release safely uses
+`focused.v1` until `genesis init` or `genesis engineering set focused.v1`
+records the file.
+
 Hosts that manage project environments can call `inspectEnvironment()`.
 Concrete Stack integrations may declare public, non-secret Environment
 defaults such as the database driver selected by that integration. Explicit
@@ -212,26 +261,27 @@ Python, Java, C#, C/C++, PHP, Go, Rust, Ruby, Kotlin, and Shell. A future techno
 adds its adapter through its Stack piece rather than teaching Genesis prompts
 to parse that language.
 
-At the end of a turn that changed Git-visible project files, the Stop hook asks
-Codex for bounded follow-up turns. When the selected Stack contributes
-`Post-change` work, all contributions compose deterministically into one
-optional code-changing turn. Genesis then reconciles the Blueprint and affected
-Program explanations from the complete changed-path set and actual Git diff,
-and refreshes both City projections. A focused, behavior-preserving Deslop pass
-runs before both Cities are refreshed again. Genesis then requests one concise
-user-facing summary using conversation context only; that final phase is not
-Stack-configurable and cannot schedule more cleanup. A project with no selected
-Stack uses only the `genesis-deslop` skill. Selected Stack components enrich
-Post-change work, reconciliation, and cleanup with general Guidance, and enrich
-cleanup further with technology-specific Deslop guidance.
+Before changing project files for a user-requested implementation, Codex runs
+`genesis hook authorize`. At the end of an authorized turn that changed
+Git-visible project files, the Stop hook asks Codex for bounded follow-up turns.
+Unmarked turns finish normally even if another process changes the same
+checkout. When the selected Stack contributes `Post-change` work, all
+contributions compose deterministically into one optional code-changing turn.
+Genesis then reconciles the Blueprint and affected Program explanations from
+the complete changed-path set and actual Git diff, and refreshes both City
+projections. A focused, behavior-preserving Deslop pass runs before both Cities
+are refreshed again; its response is the concise user-facing completion. A
+project with no selected Stack uses only the `genesis-deslop` skill. Selected
+Stack components enrich Post-change work, reconciliation, and cleanup with
+general Guidance, and enrich cleanup further with technology-specific Deslop
+guidance.
 
 The hook never starts another Codex process. Its small per-session phase is
 limited to `implementation -> optional post-change -> reconcile -> deslop ->
-summary -> done`, so it cannot keep continuing recursively. The summary prompt
-forbids repository inspection, tools, commands, tests, and edits, and the next
-Stop always clears the sequence rather than scheduling more work. Empty
-Post-change content is skipped rather than producing an empty turn.
-Question-only and unchanged turns finish normally.
+done`, so it cannot keep continuing recursively. The Stop after Deslop clears
+the sequence rather than scheduling another model turn. Empty Post-change
+content is skipped rather than producing an empty turn. Question, explanation,
+review, diagnosis-only, and unchanged turns finish normally.
 
 Projects can customize a selected technology through its matching file, such
 as `genesis/stack/jskit.md`:
@@ -323,7 +373,8 @@ The eight task types are deliberately explicit:
   contracts into Genesis metadata. It composes technology-specific Adoption
   requirements from the selected Stack and does not change application code.
 - `work` implements the Blueprint and optional request using current code,
-  Program, selected Stack context, and progressively loaded Agent Skills.
+  Program, the selected engineering approach, selected Stack context, and
+  progressively loaded Agent Skills.
 - `deslop` requests cleanup explicitly. Codex projects also receive a bounded
   automatic Deslop turn after their separate explanatory reconciliation turn.
 - `program` edits only `genesis/program/` to explain the code that exists, with
@@ -422,7 +473,7 @@ genesis check
 
 `check` is read-only. It reports only structural or recorded facts:
 
-- Blueprint and Stack validity;
+- Blueprint, engineering approach, and Stack validity;
 - selected Agent Skill presence and structural validity;
 - Program presence and structural validity;
 - environment declarations and consumer-owned Stack extensions as `ready`,
@@ -451,10 +502,13 @@ import {
   getContext,
   indexCodebase,
   initialize,
+  inspectEngineering,
   inspectEnvironment,
   inspectStackSection,
   installCodex,
+  listEngineeringProfiles,
   listStackPieces,
+  setEngineeringProfile,
   verify,
 } from 'genesis-compiler';
 ```
@@ -463,6 +517,9 @@ import {
 Stack skills, and local Codex hooks.
 `adoptProject()` also returns the initial `adopt` prompt for an existing
 codebase. `installCodex()` installs the optional global discovery plugin.
+`listEngineeringProfiles()`, `inspectEngineering()`, and
+`setEngineeringProfile()` expose the same built-in catalog and portable
+project selection used by the CLI and hosts.
 `getContext()` resolves source paths to the Program modules that cite them,
 the functions already declared there, selected Stack guidance, available Agent
 Skills, and verification commands. `indexCodebase()` regenerates or returns the
@@ -474,7 +531,8 @@ projection paths without returning any supplied environment value.
 interpreting or executing its contents.
 
 Normalized results identify their stable public contract in the `contract`
-field: `genesis.environment.v1`, `genesis.stack-section.v1`, or
+field: `genesis.engineering.v1`, `genesis.environment.v2`,
+`genesis.stack-section.v1`, or
 `genesis.verification.v1`. A consumer defines any schema embedded inside the
 opaque section body.
 

package/docs/assurance-model.md

@@ -2,7 +2,9 @@
 
 Genesis reports only facts it can establish mechanically:
 
-1. Blueprint, Stack, and Program files satisfy their small structural formats.
+1. Blueprint, Engineering approach, Stack, and Program files satisfy their
+   small structural formats, and the selected engineering profile exists in
+   the installed versioned catalog.
 2. Program operations live in conceptual subsystem directories and cite real
    source files. Optional helper maps are not mechanically certified.
 3. Stack-declared environment inputs are present and non-placeholder. This does
@@ -17,8 +19,8 @@ Genesis reports only facts it can establish mechanically:
    City projects the Program modules and source citations that exist. Neither
    proves semantic equivalence, complete dynamic dispatch, or true duplication.
 
-Prompt text, Stack Description/Guidance/Adoption/Post-change/Deslop prose, Program prose, Agent Skill
-content, and agent output are not assurance evidence. Genesis does not claim
+Prompt text, engineering guidance, Stack Description/Guidance/Adoption/Post-change/Deslop prose,
+Program prose, Agent Skill content, and agent output are not assurance evidence. Genesis does not claim
 that product intent and code have converged, that Program is complete or
 semantically current, or that passing checks prove the whole product correct.
 

package/docs/prompt-integration.md

@@ -40,6 +40,10 @@ Genesis keeps each instruction at one useful level:
   commands, opaque consumer sections, and an optional authoritative Agent Skill source.
 - `genesis/blueprint.md`, `genesis/program/`, and `genesis/stack.md` are the
   project's own intent, explanation, and selected technical composition.
+- `profiles/engineering/*.md` owns the installed versioned engineering
+  profiles. `genesis/engineering.md` selects one profile and records explicit
+  project requirements. A universal complexity gate is composed ahead of the
+  selected profile in every implementation and cleanup path.
 - The generated JSON block contains current structural facts and warnings.
 
 Detailed technology manuals belong in the technology skill's `references/`
@@ -73,23 +77,25 @@ command itself and follows its returned prompt in the same conversation. Other
 hosts can call `adoptProject()` and send its `prompt` directly.
 
 Codex can instead use the project-local hooks installed by `genesis init`.
-Those hooks inject a short operating guide, record whether the current turn
-changed project files, then request bounded continuations. Selected
+Those hooks inject a short operating guide and record the Git-visible state when
+each user prompt begins. Before editing for an explicit user implementation
+request, Codex marks that turn with `genesis hook authorize`. Only an authorized
+turn whose project files changed can request bounded continuations; unmarked
+turns finish normally even if another process changes the checkout. Selected
 `Post-change` contributions compose into one optional code-changing turn;
 Genesis then reconciles Blueprint and affected Program explanations from the
-complete Git-visible change set and Deslops the implementation. One final
-summary prompt then asks for a concise user-facing account from conversation
-context only, forbids tools and edits, and cannot schedule more cleanup. The
-hooks invoke the same Genesis project operations and never start another agent
-process. A per-session phase permits only `implementation -> optional
-post-change -> reconcile -> deslop -> summary -> done`. Empty Post-change
-content skips that phase. Genesis refreshes both City projections after
-reconciliation so Deslop sees the current explanation and function inventory,
-then refreshes them again after Deslop in case cleanup changed the
-implementation map.
+complete Git-visible change set and Deslops the implementation. The Deslop
+response is the concise user-facing completion. The hooks invoke the same
+Genesis project operations and never start another agent process. A per-session
+phase permits only `implementation -> optional post-change -> reconcile ->
+deslop -> done`. Empty Post-change content skips that phase. Genesis refreshes
+both City projections after reconciliation so Deslop sees the current
+explanation and function inventory, then refreshes them again after Deslop in
+case cleanup changed the implementation map.
 
 Once Codex identifies relevant source, `genesis context <path...>` returns only
-Program modules citing those paths plus concise selected Stack context, the
+Program modules citing those paths plus the effective engineering approach and
+concise selected Stack context, the
 functions structurally indexed in those paths, available Agent Skill catalog,
 and verification commands. `genesis index <name-or-path>` searches the complete
 current function inventory and refreshes `.genesis/machine-city.json` and

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "genesis-compiler",
-  "version": "1.2.17",
+  "version": "1.2.19",
   "type": "module",
   "description": "An agent-independent prompt, multi-language code-index, cleanup, and verification companion with optional Codex hooks.",
   "repository": {
@@ -31,13 +31,13 @@
     "prompts/adopt.txt",
     "prompts/describe.txt",
     "prompts/deslop.txt",
-    "prompts/final-summary.txt",
     "prompts/program.txt",
     "prompts/reconcile.txt",
     "prompts/review.txt",
     "prompts/start.txt",
     "prompts/work.txt",
     "plugins/genesis",
+    "profiles",
     "skills",
     "src"
   ],

package/plugins/genesis/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "genesis",
-  "version": "1.2.17",
+  "version": "1.2.19",
   "description": "Makes Codex aware of optional Genesis adoption for existing projects.",
   "author": {
     "name": "Mobily Enterprises"

package/profiles/engineering/baseline.md

@@ -0,0 +1,6 @@
+# Engineering baseline
+
+- Every implementation must be easy to reason about and be the smallest targeted change that fully satisfies the known requirements.
+- Prefer direct control flow, existing ownership boundaries, and established project or technology seams.
+- Do not overengineer or overcomplicate the solution. Do not add speculative abstractions, layers, dependencies, infrastructure, compatibility paths, distributed patterns, cryptography, enterprise patterns, or other advanced machinery unless an explicit requirement or a concrete constraint makes it necessary.
+- If good software requires material complexity beyond these rules, stop before writing it. Explain the requirement, why the direct design is insufficient, and the smallest added complexity proposed, then ask the user to approve or clarify the tradeoff.

package/profiles/engineering/durable.v1.md

@@ -0,0 +1,11 @@
+# Durable product
+
+## Description
+
+Long-lived product work with explicit compatibility and operational care.
+
+## Guidance
+
+- Treat affected public contracts, stored data, migrations, recovery, and operability as first-class requirements.
+- Make ownership and failure handling explicit enough for multiple contributors to maintain safely.
+- Add boundaries or supporting machinery only where a current longevity or operational requirement needs them; keep unaffected work as direct as the focused profile.

package/profiles/engineering/focused.v1.md

@@ -0,0 +1,11 @@
+# Focused
+
+## Description
+
+Small, direct changes for ordinary product work.
+
+## Guidance
+
+- Optimize for the clearest complete implementation with the fewest moving parts.
+- Keep single-use logic close to its caller and introduce a shared abstraction only when one real shared operation already exists.
+- Do not pre-build extensibility, scale, migration, or organizational machinery for hypothetical future needs.

package/profiles/engineering/high-assurance.v1.md

@@ -0,0 +1,11 @@
+# High assurance
+
+## Description
+
+Security- or reliability-critical work backed by explicit risks and evidence.
+
+## Guidance
+
+- Establish the relevant threat model, trust boundaries, data sensitivity, availability, compliance, and recovery requirements before making a design they could materially change.
+- Use established, audited primitives; make critical failure paths and ownership explicit; verify the properties on which safety depends.
+- Cryptography, distributed coordination, redundant controls, and similarly advanced machinery still require a concrete risk or obligation. Ask for missing constraints instead of inventing them.

package/prompts/deslop.txt

@@ -19,3 +19,8 @@ changed path or appears related to the preceding implementation.
 
 Do not broaden the product change. Run focused checks when useful and summarize
 what became simpler, files changed, and checks actually run.
+
+Your response from this turn is the final user-facing answer for the original
+request. Make it concise and self-contained. Lead with the outcome, include the
+important implemented behavior and any genuine blocker or unfinished work, and
+do not mention automatic phases, hooks, or these instructions.

package/prompts/start.txt

@@ -13,6 +13,14 @@ the non-technical Blueprint from the user's answers before implementation.
 If the product direction becomes clear while Stack is still empty, do not end
 the turn after only writing or summarizing the Blueprint: present the relevant
 Stack choices in that same turn and ask the user to select one explicitly.
+The default `focused.v1` engineering profile is already suitable for ordinary
+work, so do not force a separate profile question. When the user asks for a
+different engineering approach, or the product clearly has long-lived
+compatibility, operational, security, reliability, or compliance constraints,
+use `availableEngineeringProfiles` to explain only the relevant choices in
+product language. After an explicit choice, run `genesis engineering set
+<profile>`; do not invent or duplicate a built-in profile. Record additional
+explicit obligations in `genesis/engineering.md` under Project requirements.
 This opening turn owns product direction and Stack selection, not final
 verification. Do not run `genesis verify` before implementation exists. If
 structural validation is useful, run `genesis check`; consumer-owned operations

package/skills/genesis-deslop/SKILL.md

@@ -9,6 +9,11 @@ Review and simplify the current local codebase without changing product
 behavior. Start with the requested scope, or otherwise the ordinary Git diff
 and the code immediately around it.
 
+Apply the engineering approach supplied with the task. If this skill is invoked
+directly, read `genesis/engineering.md` as well as the relevant project context.
+Cleanup must reduce or preserve complexity, never introduce unapproved
+machinery that the selected profile or a concrete requirement does not need.
+
 Consult `.genesis/machine-city.json` or run `genesis index <name-or-path>` to
 find existing public and internal functions before introducing or consolidating
 an abstraction. Confirm every apparent duplicate in source and its call sites.

package/skills/genesis-project/SKILL.md

@@ -11,14 +11,16 @@ codebase, tests, Git review, or the coding agent.
 ## Establish context
 
 1. Read `genesis/blueprint.md` for non-technical product intent.
-2. Read `genesis/stack.md` for the selected technical composition, resources,
+2. Read `genesis/engineering.md` for the selected engineering profile and any
+   project-specific requirements.
+3. Read `genesis/stack.md` for the selected technical composition, resources,
    and verification commands.
-3. Locate the source involved in the request.
-4. Run `genesis index <name-or-path>` before adding a helper or public operation.
+4. Locate the source involved in the request.
+5. Run `genesis index <name-or-path>` before adding a helper or public operation.
    Reuse an existing function when it already owns the behavior.
-5. Run `genesis context <path...>` for the relevant Program explanations and
+6. Run `genesis context <path...>` for the relevant Program explanations and
    selected Stack context.
-6. Load applicable technology skills from `.agents/skills/` or from the
+7. Load applicable technology skills from `.agents/skills/` or from the
    agent's own installed skill catalog.
 
 For an existing application's first Stack selection, inspect its real setup,
@@ -40,6 +42,16 @@ Neither is authority or proof; both may be regenerated with `genesis index`.
 
 ## Implement ordinary local work
 
+- Apply the effective engineering approach supplied by Genesis. Every change
+  must be easy to reason about and be the smallest targeted implementation that
+  fully meets known requirements. Do not overengineer or overcomplicate it, and
+  do not add speculative abstractions, layers,
+  dependencies, infrastructure, compatibility paths, distributed patterns,
+  cryptography, or other advanced machinery.
+- When a concrete requirement makes material complexity necessary, stop before
+  writing it. Explain why the direct design is insufficient and the smallest
+  added complexity proposed, then ask the user to approve or clarify the
+  tradeoff. Never silently override the engineering approach.
 - Work directly in the current Git tree and leave useful edits visible in the
   ordinary diff.
 - Do not edit the Blueprint, Program, or `.genesis/` during implementation; the

package/src/cli.js

@@ -9,25 +9,33 @@ import {
   getContext,
   indexCodebase,
   initialize,
+  inspectEngineering,
   inspectEnvironment,
   inspectStackSection,
   installCodex,
+  listEngineeringProfiles,
   listStackPieces,
+  setEngineeringProfile,
   verify,
 } from './index.js';
 import {
+  authorizeCodexTurn,
   codexAdoptionRecommendation,
   codexSessionContext,
   completeCodexTurn,
   discardCodexTurn,
   recordCodexTurn,
 } from './index/codex-hooks.js';
+import { engineeringProfile, readEngineeringBaseline } from './index/engineering.js';
 import { asDiagnostic, fail } from './index/errors.js';
 
 const USAGE = `Usage:
   genesis init
   genesis adopt [product guidance...]
   genesis codex install
+  genesis engineering list
+  genesis engineering show [profile]
+  genesis engineering set <profile>
   genesis stack list
   genesis stack add <piece...>
   genesis context <path...>
@@ -51,7 +59,7 @@ prompt to the agent you already use. Review all edits through the ordinary Git
 diff, then run genesis verify for the Stack's concrete checks.
 `;
 
-const COMMANDS = new Set(['adopt', 'check', 'codex', 'context', 'hook', 'index', 'init', 'inspect', 'prompt', 'stack', 'verify']);
+const COMMANDS = new Set(['adopt', 'check', 'codex', 'context', 'engineering', 'hook', 'index', 'init', 'inspect', 'prompt', 'stack', 'verify']);
 
 function parseCommand(argv) {
   if (argv.length === 0 || argv.includes('--help') || argv.includes('-h') || argv[0] === 'help') {
@@ -95,6 +103,20 @@ function parseCommand(argv) {
     if (operands[0] === 'list' && operands.length !== 1) {
       fail('CLI_EXTRA_ARGUMENT', 'Command stack list accepts no extra arguments.');
     }
+  } else if (command === 'engineering') {
+    const [action] = operands;
+    if (!['list', 'show', 'set'].includes(action)) {
+      fail('CLI_ENGINEERING_ACTION_REQUIRED', 'Command engineering requires list, show, or set.');
+    }
+    if (action === 'list' && operands.length !== 1) {
+      fail('CLI_EXTRA_ARGUMENT', 'Command engineering list accepts no extra arguments.');
+    }
+    if (action === 'show' && operands.length > 2) {
+      fail('CLI_EXTRA_ARGUMENT', 'Command engineering show accepts at most one profile.');
+    }
+    if (action === 'set' && operands.length !== 2) {
+      fail('CLI_ENGINEERING_PROFILE_REQUIRED', 'Command engineering set requires exactly one profile.');
+    }
   } else if (command === 'codex') {
     if (operands.length !== 1 || operands[0] !== 'install') {
       fail('CLI_CODEX_ACTION_REQUIRED', 'Command codex requires exactly: install.');
@@ -110,8 +132,8 @@ function parseCommand(argv) {
         'Command inspect requires environment or section <name>.',
       );
     }
-  } else if (command === 'hook' && (operands.length !== 1 || !['begin', 'discover', 'end', 'session', 'stop'].includes(operands[0]))) {
-    fail('CLI_HOOK_ACTION_REQUIRED', 'Command hook requires exactly one of: discover, session, begin, stop, end.');
+  } else if (command === 'hook' && (operands.length !== 1 || !['authorize', 'begin', 'discover', 'end', 'session', 'stop'].includes(operands[0]))) {
+    fail('CLI_HOOK_ACTION_REQUIRED', 'Command hook requires exactly one of: discover, session, begin, authorize, stop, end.');
   } else if (!['adopt', 'context', 'hook', 'index', 'inspect', 'prompt'].includes(command) && operands.length > 0) {
     fail('CLI_EXTRA_ARGUMENT', `Command ${command} accepts no arguments.`);
   }
@@ -130,6 +152,7 @@ function namedItems(label, values) {
 
 function writeCheck(result) {
   line(process.stdout, `Blueprint: ${result.blueprint}`);
+  line(process.stdout, `Engineering approach: ${result.engineering}`);
   line(process.stdout, `Stack: ${result.stack}`);
   line(process.stdout, `Agent Skills: ${result.skills}`);
   line(process.stdout, `Program: ${result.program}`);
@@ -144,6 +167,29 @@ function writeCheck(result) {
   line(process.stdout, `Check: ${result.status}`);
 }
 
+function writeEngineering(result) {
+  if (result.action === 'list') {
+    for (const profile of result.profiles) {
+      line(process.stdout, `${profile.id}: ${profile.name} — ${profile.description}`);
+    }
+    return;
+  }
+  if (result.profile) {
+    line(process.stdout, `${result.profile.name} (${result.profile.id})`);
+    line(process.stdout, result.profile.description);
+  }
+  if (result.guidance) {
+    line(process.stdout, '');
+    line(process.stdout, result.guidance);
+  }
+  if (result.action === 'set') {
+    namedItems('Changed files', result.changedFiles);
+    line(process.stdout, `engineering: ${result.status}`);
+  } else if (result.status) {
+    line(process.stdout, `Engineering approach: ${result.status}`);
+  }
+}
+
 function writeInspection(result) {
   const title = result.inspection[0].toUpperCase() + result.inspection.slice(1);
   line(process.stdout, `${title}: ${result.status}`);
@@ -179,6 +225,10 @@ function writeResult(command, result) {
     writeCheck(result);
     return;
   }
+  if (command === 'engineering') {
+    writeEngineering(result);
+    return;
+  }
   if (command === 'context') {
     process.stdout.write(result.context.endsWith('\n') ? result.context : `${result.context}\n`);
     return;
@@ -254,6 +304,36 @@ async function execute({ command, operands, options }, { signal } = {}) {
     return adoptProject({ projectRoot, request: operands.join(' '), stackPackages });
   }
   if (command === 'codex') return installCodex();
+  if (command === 'engineering') {
+    if (operands[0] === 'list') {
+      return { action: 'list', status: 'ok', profiles: await listEngineeringProfiles() };
+    }
+    if (operands[0] === 'show') {
+      if (!operands[1]) return { action: 'show', ...await inspectEngineering({ projectRoot }) };
+      const [baseline, profile] = await Promise.all([
+        readEngineeringBaseline(),
+        engineeringProfile(operands[1]),
+      ]);
+      return {
+        action: 'show',
+        status: 'ready',
+        profile,
+        guidance: [
+          '## Universal complexity gate',
+          '',
+          baseline,
+          '',
+          '## Profile guidance',
+          '',
+          profile.guidance,
+        ].join('\n'),
+      };
+    }
+    return {
+      action: 'set',
+      ...await setEngineeringProfile({ profile: operands[1], projectRoot }),
+    };
+  }
   if (command === 'stack') {
     if (operands[0] === 'list') {
       return { status: 'ok', pieces: await listStackPieces({ projectRoot, stackPackages }) };
@@ -294,6 +374,9 @@ async function execute({ command, operands, options }, { signal } = {}) {
     if (operands[0] === 'session') {
       return { kind: 'session', ...await codexSessionContext({ projectRoot }) };
     }
+    if (operands[0] === 'authorize') {
+      return { kind: 'authorize', ...await authorizeCodexTurn({ projectRoot }) };
+    }
     const input = await hookInput();
     if (operands[0] === 'begin') {
       return { kind: 'begin', ...await recordCodexTurn({ input, projectRoot }) };

package/src/index/assets.js

@@ -8,7 +8,6 @@ const assets = {
   describe: new URL('prompts/describe.txt', root),
   reconcile: new URL('prompts/reconcile.txt', root),
   deslop: new URL('prompts/deslop.txt', root),
-  finalSummary: new URL('prompts/final-summary.txt', root),
   program: new URL('prompts/program.txt', root),
   blueprint: new URL('prompts/blueprint.txt', root),
   review: new URL('prompts/review.txt', root),

package/src/index/check.js

@@ -8,11 +8,13 @@ import { inspectVerification } from './project-state.js';
 import { missingStackResources } from './stack-preflight.js';
 import { withStackEnvironmentDefaults } from './stack-environment-defaults.js';
 import { inspectProjectEnvironment } from './environment-files.js';
+import { readEngineering } from './engineering.js';
 
 function invalidResult(area, error) {
   return {
     status: 'invalid',
     blueprint: area === 'blueprint' ? 'invalid' : 'valid',
+    engineering: area === 'engineering' ? 'invalid' : 'unknown',
     stack: area === 'stack' ? 'invalid' : 'unknown',
     skills: area === 'skills' ? 'invalid' : 'unknown',
     program: 'unknown',
@@ -40,6 +42,13 @@ export async function checkProject({
   }
 
   let stack;
+  let engineering;
+  try {
+    engineering = await readEngineering(root);
+  } catch (error) {
+    return invalidResult('engineering', error);
+  }
+
   try {
     stack = await readStack(root, { stackPackages });
   } catch (error) {
@@ -87,6 +96,7 @@ export async function checkProject({
 
   const guidance = [];
   if (program.status === 'missing') guidance.push('Generate an explanatory Program prompt with genesis prompt --task program.');
+  if (engineering.status === 'defaulted') guidance.push('Run genesis init or genesis engineering set focused.v1 to record the default engineering approach.');
   if (program.status === 'invalid') guidance.push('Repair the Program with genesis prompt --task program.');
   if (skills.status === 'missing') guidance.push('Run genesis init to install selected project Agent Skills.');
   if (skills.status === 'invalid') guidance.push('Repair the reported Agent Skill or managed-skill manifest.');
@@ -99,6 +109,7 @@ export async function checkProject({
   guidance.push('Use genesis prompt --task review for a semantic, evidence-based comparison.');
 
   const needsAttention = program.status === 'missing'
+    || engineering.status === 'defaulted'
     || skills.status === 'missing'
     || missingResources.length > 0
     || extensionDiagnostics.length > 0
@@ -109,6 +120,7 @@ export async function checkProject({
       ? 'invalid'
       : needsAttention ? 'attention' : 'ok',
     blueprint: 'valid',
+    engineering: engineering.status,
     stack: 'valid',
     skills: skills.status,
     program: program.status,