@sireai/optimus 0.1.1

package/harness/CHECKLIST.md

@@ -0,0 +1,44 @@
+# Checklist
+
+Run this after any meaningful code, design, validation, or doc change.
+
+## Engineering
+
+- layering still matches `runtime / orchestration / runner / storage`
+- new behavior lives in the right module
+- commands, config, runtime paths, and docs still agree
+- setup, auth, and doctor entrypoints stay simple
+- task status, health, and result return still have clear inspection paths
+
+## Product and Architecture
+
+- product still behaves like a task-execution agent
+- CLI direction still converges on installable, diagnosable, recoverable operation
+- docs still match the main flow: triage -> executor -> status return
+- harness still means task-type control artifacts, not loose prompts
+
+## Operations
+
+- common command errors point to the exact bad input
+- `doctor` distinguishes blockers from degradations
+- failure output answers: what failed, why, next action
+
+## Validation
+
+- key signals and failure criteria are defined
+- the change explains why tasks fail, stall, or do not start
+- if observability is missing, add that before adding more features
+
+## Docs
+
+- architecture changes updated `doc/optimus_architecture_design.md`
+- product changes updated `doc/optimus_product_prd.md`
+- harness-boundary changes updated `harness/FRAMEWORK.md`
+- stage changes updated `GOAL.md`, `TASK_PLAN.md`, or `HANDOFF.md`
+
+## Before Push
+
+- `npm run typecheck`
+- `npm run build`
+- `npm test`
+- `npm run db-inspect`

package/harness/CONSTRAINTS.md

@@ -0,0 +1,60 @@
+# Constraints and Invariants
+
+This is the single constraint file for relay work on Optimus.
+
+## Must Hold
+
+- TypeScript is the primary language
+- the project ships as an npm package
+- first-use flow converges to a small set of clear entrypoints
+- system layering stays explicit between `Task Environment` and `Problem-Solving Core`
+- all task intake converges to the unified task model
+- task-type harnesses live under `task-harnesses/`
+- resident `TriageRunner` owns final accept / reject / route decisions
+- triage loads full `ACCEPT.md` content at startup and reuses the resident thread
+- `ACCEPT.md` is the only source of triage contract
+- main-flow changes must add observable signals and feedback
+- user-facing diagnostics must separate blockers from degradations and give a fix action
+- common CLI commands must validate parameters and emit precise help and errors
+- docs stay split by audience: user, operator, developer, relay harness
+- runtime implementations favor short paths, low overhead, and explicit state
+
+## Must Not Happen
+
+- scheduler logic inside `CodexRunner`
+- triage semantics hidden inside `manifest.json`
+- local fallback rules after resident triage startup failure
+- triage contract duplicated into `ROLE.md`, registry fields, or code constants
+- long-term rules written into `HANDOFF.md`
+- user docs, ops docs, and relay docs merged into one long-lived file
+- main-flow changes without observability
+- new loops, queues, or state layers when a simpler direct model exists
+
+## Design and Validation
+
+- do not stop at "it runs"; define key signals and failure criteria first
+- after validation, iterate on feedback instead of only describing symptoms
+- observability must explain delay, instability, and next corrective action
+- once architecture direction is clear, prefer blocking wait, event-driven flow, short critical paths, and fewer state transitions
+- every design should answer: less idle waiting, fewer middle layers, lower state complexity, better recovery
+
+## Code Readability
+
+- new or changed critical logic must be commented
+- comments should explain responsibility, state transition reason, boundary, or contract
+- use section comments for main-flow logic, state transitions, storage, auth, fallback, triage, and harness assembly
+- trivial syntax comments are noise
+- keep module structure recognizable by responsibility
+
+## Review
+
+- no push, merge, or release without code review
+- review shared code touched by the change, not just the current unstaged diff
+- findings should prioritize bugs, regressions, contract breaks, missing validation, and doc drift
+
+## Doc Sync
+
+- update architecture doc when architecture changes
+- update `GOAL.md` or `TASK_PLAN.md` when stage goals change
+- update `HANDOFF.md` when current status, risk, or validation changes
+- update `FRAMEWORK.md` when document boundaries change

package/harness/FRAMEWORK.md

@@ -0,0 +1,28 @@
+# Harness Framework
+
+`harness/` is the relay control plane for ongoing engineering work.
+
+## Layers
+
+- entry: `AGENTS.md`
+- constraints: `CONSTRAINTS.md`
+- checklist: `CHECKLIST.md`
+- product: `doc/optimus_product_prd.md`
+- architecture: `doc/optimus_architecture_design.md`
+- goal: `GOAL.md`
+- plan: `TASK_PLAN.md`
+- handoff: `HANDOFF.md`
+
+## Boundaries
+
+- `harness/`: relay rules, stage goals, current state
+- `doc/`: long-lived user, product, architecture, and maintenance docs
+- `task-harnesses/`: task-type artifacts used by the runtime
+
+## Update Rules
+
+- long-term rules -> `CONSTRAINTS.md`
+- product meaning -> PRD
+- architecture boundaries -> architecture doc
+- stage priorities -> `GOAL.md` or `TASK_PLAN.md`
+- recent state, risk, validation -> `HANDOFF.md`

package/harness/GOAL.md

@@ -0,0 +1,28 @@
+# Goal and Boundary
+
+## Project Goal
+
+- build a task-execution AI agent system
+- keep problem intake, routing, execution, and result return continuous and governable
+- keep Codex as the current executor, harness as the task control layer, and runtime as the resident governance layer
+
+## Current Stage Goal
+
+- converge Optimus into an installable, initializable, diagnosable, recoverable, deliverable npm CLI
+- simplify setup, config, auth, and common-command experience
+- keep `doctor` focused on real run blockers and clear fixes
+- cleanly separate user docs, ops docs, developer docs, and relay docs
+- keep runtime, delivery, and publication stable while productizing the CLI
+
+## Current Non-Goals
+
+- full platform UI
+- ungoverned automatic merges
+- agent-selected permissions
+- rollback to a CLI-scripted task-harness narrative
+- breaking harness, review, or delivery boundaries for convenience
+
+## Entry Docs
+
+- product: `doc/optimus_product_prd.md`
+- architecture: `doc/optimus_architecture_design.md`

package/harness/HANDOFF.md

@@ -0,0 +1,45 @@
+# Handoff
+
+## Current State
+
+- product positioning is aligned around a task-execution AI agent
+- the main system flow is aligned around `raw problem -> triage -> task package -> harnessed execution -> status/result return`
+- persistence is SQLite-based
+- Codex integration is SDK-based
+- triage is resident and reuses preloaded `ACCEPT.md` contracts
+- current focus is CLI productization: setup, config, doctor, interaction, and doc boundaries
+
+## Recently Landed
+
+- PRD, architecture, and maintenance docs were rewritten around the current product model
+- harness docs were clarified as relay-control artifacts, not user docs
+- runtime views are clearer across `doctor`, `task-status`, and `db-inspect`
+- self-update and npm release flow were added
+
+## Open Work
+
+- harness registry is still a minimal directory model
+- platform status write-back is still incomplete
+- patch validation and review-packet quality still need work
+- first-run flow, auth flow, and doctor boundaries can still be simplified
+
+## Current Risks
+
+- Codex auth and provider quality still heavily affect runtime reliability
+- state machine changes require synchronized code and doc updates
+- resident triage depends on harness digest and session resume semantics
+- CLI changes without doc and error-output alignment will raise usage cost
+
+## Validation Baseline
+
+- `npm run typecheck`
+- `npm run build`
+- `npm test`
+- `npm run db-inspect`
+
+## Next Entry Point
+
+1. read `harness/AGENTS.md`
+2. read the PRD and architecture docs
+3. run the validation baseline
+4. continue from `harness/TASK_PLAN.md`

package/harness/TASK_PLAN.md

@@ -0,0 +1,79 @@
+# Task Plan
+
+## Theme
+
+Shift from "fill missing core-path capability" to "converge Optimus into an installable, diagnosable, recoverable npm CLI."
+
+## Stage Goals
+
+- shortest possible first-run path after install
+- simpler config and auth entrypoints
+- `doctor` that checks only real blockers and degradations
+- common commands with stable validation and actionable errors
+- clear doc split across user, ops, developer, and relay audiences
+- no regression to task, harness, delivery, or publication core paths
+
+## Principles
+
+- close the first-run loop before expanding advanced features
+- converge user entrypoints before exposing low-level config
+- every failure output should answer: what failed, why, next step
+- docs should be split by reader, not accumulated into one file
+- productization must not break `task package -> harness -> execution -> delivery/publication`
+
+## Priority Plan
+
+### P0 First-run loop
+
+- stable install command
+- `optimus setup` as the only init entrypoint
+- setup generates full config and ends with `doctor --quick`
+- quick start stays aligned with real CLI output
+
+### P1 Config and auth convergence
+
+- reduce exposed low-level config fields
+- clarify which values are built in versus user-supplied
+- make credential source explainable
+
+### P2 Doctor and ops
+
+- keep `doctor` focused on true blockers and degradations
+- improve repair guidance
+- strengthen support and retry workflows
+
+### P3 Command experience
+
+- normalize help, examples, and error output
+- tighten validation for submit, Jira, repo, status, result, and delivery commands
+- keep output categories explicit: execution, delivery, notification, publication
+
+### P4 Documentation
+
+- keep user, ops, developer, and relay docs separated
+- keep doc entrypoints obvious
+- keep docs synchronized with real CLI behavior
+
+## Suggested Order
+
+1. P0
+2. P1
+3. P2
+4. P3
+5. P4
+
+## Not in Scope
+
+- large web UI work
+- multi-tenant permission center
+- wide command renames without product value
+- reducing installation friction by weakening review or delivery boundaries
+- release before review, diagnostics, and docs are aligned
+
+## Acceptance
+
+- a new user can install, setup, diagnose, and submit a first task
+- an existing user can understand config, auth, and missing prerequisites quickly
+- `doctor` clearly separates blockers from degradations
+- common-command error messages are precise and actionable
+- doc boundaries remain clean while core-path tests stay stable

package/optimus.config.template.json

@@ -0,0 +1,34 @@
+{
+  "runtime": {
+    "workerConcurrency": 1,
+    "taskHarnessRootDir": "task-harnesses",
+    "networkAccessEnabled": true
+  },
+  "storage": {
+    "rootDir": ".optimus-runtime"
+  },
+  "observability": {
+    "enabled": true,
+    "mode": "debug",
+    "consoleLevel": "info",
+    "fileLevel": "debug",
+    "soundEnabled": false
+  },
+  "codex": {
+    "model": "openai/gpt-5.4",
+    "provider": "palebluedot",
+    "reasoningEffort": "medium",
+    "approvalPolicy": "never",
+    "sandboxMode": "workspace-write"
+  },
+  "delivery": {
+    "enabled": true,
+    "channels": ["console"],
+    "summaryStyle": "dense"
+  },
+  "publication": {
+    "enabled": true,
+    "dryRun": true,
+    "reviewMode": "manual"
+  }
+}

package/package.json

@@ -0,0 +1,109 @@
+{
+  "name": "@sireai/optimus",
+  "version": "0.1.1",
+  "description": "Optimus Codex-native background task runtime and harness scaffolding.",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/SireAI/optimus.git"
+  },
+  "homepage": "https://github.com/SireAI/optimus#readme",
+  "bugs": {
+    "url": "https://github.com/SireAI/optimus/issues"
+  },
+  "publishConfig": {
+    "access": "public"
+  },
+  "engines": {
+    "node": ">=20"
+  },
+  "packageManager": "npm@10",
+  "type": "module",
+  "main": "dist/index.js",
+  "types": "dist/index.d.ts",
+  "bin": {
+    "optimus": "dist/cli/optimus.js"
+  },
+  "files": [
+    "dist",
+    ".env.example",
+    "LICENSE",
+    "embedded-skills",
+    "harness",
+    "optimus.config.template.json",
+    "task-harnesses"
+  ],
+  "exports": {
+    ".": {
+      "types": "dist/index.d.ts",
+      "default": "dist/index.js"
+    }
+  },
+  "scripts": {
+    "build": "tsc -p tsconfig.json",
+    "clean": "rm -rf dist .optimus-runtime",
+    "prepack": "npm run build",
+    "dev": "node --loader ts-node/esm src/cli/optimus.ts start",
+    "start": "node dist/cli/optimus.js start",
+    "version": "node dist/cli/optimus.js version",
+    "upgrade": "node dist/cli/optimus.js upgrade",
+    "release:status": "node scripts/release.mjs status",
+    "release:prepare": "node scripts/release.mjs prepare",
+    "release:preflight": "node scripts/release.mjs preflight",
+    "release:check": "node scripts/release.mjs check",
+    "release:pack": "npm pack",
+    "release:publish": "node scripts/release.mjs publish",
+    "release:tag": "node scripts/release.mjs tag",
+    "setup": "node dist/cli/optimus.js setup",
+    "submit": "node dist/cli/optimus.js submit",
+    "retry-task": "node dist/cli/optimus.js retry-task",
+    "cancel-task": "node dist/cli/optimus.js cancel-task",
+    "health-check": "node dist/cli/optimus.js health-check",
+    "triage-only": "node dist/cli/optimus.js triage-only",
+    "doctor": "node dist/cli/optimus.js doctor",
+    "notify-test": "node dist/cli/optimus.js notify-test",
+    "delivery-retry": "node dist/cli/optimus.js delivery-retry",
+    "postrun-retry": "node dist/cli/optimus.js postrun-retry",
+    "repo": "node dist/cli/optimus.js repo",
+    "repo:add": "node dist/cli/optimus.js repo add",
+    "repo:remove": "node dist/cli/optimus.js repo remove",
+    "repo:update": "node dist/cli/optimus.js repo update",
+    "repo:list": "node dist/cli/optimus.js repo list",
+    "repo:doctor": "node dist/cli/optimus.js repo doctor",
+    "task-status": "node dist/cli/optimus.js task-status",
+    "delivery-status": "node dist/cli/optimus.js delivery-status",
+    "task-events": "node dist/cli/optimus.js task-events",
+    "task-result": "node dist/cli/optimus.js task-result",
+    "intake-status": "node dist/cli/optimus.js intake-status",
+    "intake-run": "node dist/cli/optimus.js intake-run",
+    "intake-disable": "node dist/cli/optimus.js intake-disable",
+    "intake-enable": "node dist/cli/optimus.js intake-enable",
+    "intake-reset-checkpoint": "node dist/cli/optimus.js intake-reset-checkpoint",
+    "db-inspect": "node dist/cli/optimus.js db-inspect",
+    "typecheck": "tsc -p tsconfig.json --noEmit",
+    "test": "npm run build && node --test tests/*.test.mjs tests/runtime-closure.test.mjs tests/task-delivery-dispatcher.test.mjs",
+    "jira-search": "node dist/integrations/jira/jira-cli.js search",
+    "jira-get-issue": "node dist/integrations/jira/jira-cli.js get-issue",
+    "jira-search-assigned-open": "node dist/integrations/jira/jira-cli.js search-assigned-open",
+    "jira-submit-assigned-open": "node dist/integrations/jira/jira-cli.js submit-assigned-open",
+    "jira-submit-issue": "node dist/integrations/jira/jira-cli.js submit-issue",
+    "jira-poll-once": "node dist/integrations/jira/jira-cli.js submit-assigned-open",
+    "jira-poll-daemon": "node dist/integrations/jira/jira-cli.js poll-daemon"
+  },
+  "keywords": [
+    "optimus",
+    "harness",
+    "codex",
+    "typescript"
+  ],
+  "license": "MIT",
+  "devDependencies": {
+    "@types/node": "^24.5.0",
+    "ts-node": "^10.9.2",
+    "typescript": "^5.9.2"
+  },
+  "dependencies": {
+    "@openai/codex-sdk": "^0.120.0",
+    "@types/better-sqlite3": "^7.6.13",
+    "better-sqlite3": "^12.9.0"
+  }
+}

package/task-harnesses/bugfix/ACCEPT.md

@@ -0,0 +1,47 @@
+# ACCEPT
+
+## Decision target
+Route real software defect tasks into the `bugfix` harness. The runner, not triage, decides whether final closure is fix or analysis.
+
+## Accept when
+Accept when all are true:
+- the input describes a real issue to handle, not open-ended discussion
+- the issue relates to code, configuration, build logic, runtime behavior, testing flow, or system behavior
+- the input contains at least an identifiable symptom, failure result, or abnormal behavior
+- the target repository can be identified; if `repo` is missing, default selection is allowed only when exactly one repository is registered
+
+## Still acceptable with incomplete information
+The task may still be accepted when:
+- root cause is unknown
+- full reproduction steps are missing
+- logs, stack traces, screenshots, or ready-made tests are missing
+- but the problem is still clear enough to judge that it is a real software defect rather than generic consultation
+
+## Reject when
+Reject when any are true:
+- the request is product advice, design discussion, or technology comparison
+- the request is pure consultation, Q&A, or open-ended brainstorming
+- there is no concrete defect object to handle
+- no relation to code, system behavior, or an engineering repository can be established
+- the target repository cannot be determined and multiple candidate repositories exist
+- the content is so vague that even the basic symptom cannot be identified
+
+## Missing information to mention first when rejecting
+- `repo`
+- `title`
+- `description_or_content`
+- `reproduction_steps`
+- `logs`
+- `stack_trace`
+- `expected_behavior`
+- `actual_behavior`
+
+## Event scope
+- `bug.discovered`
+- `problem.discovered`
+- `task.submitted_manually`
+
+## Triage guidance
+- Supporting words such as crash, error, fail, exception, regression, not working, frozen, or abnormal are hints only; they must not replace semantic judgment.
+- Judge the whole task meaning, not keywords.
+- Triage only decides whether the task enters the `bugfix` pipeline.

package/task-harnesses/bugfix/CONSTRAINTS.md

@@ -0,0 +1,46 @@
+# CONSTRAINTS
+
+## Truth rules
+- Keep task input, repository facts, inference, and validation as separate truth layers.
+- Do not present guesses, plans, recommendations, or unexecuted steps as completed facts.
+- Do not claim a fix without evidence.
+- If you ran checks, tests, builds, runtime validation, or manual verification, report what ran, how, what happened, and what remains unverified.
+
+## Patch rules
+- Change code only after reasoning through module boundaries, call chains, state flow, and upstream/downstream impact.
+- Do not ship a local symptom fix that breaks surrounding behavior.
+- Important code changes must include useful comments about intent, key decisions, boundary handling, or risk. Do not add comments that only restate obvious behavior.
+- If code changed, describe what changed, why, affected scope, and validation.
+- If code did not change, explain why patching is not yet justified.
+- Before generating or delivering a patch, self-review the actual diff for regressions, boundary issues, compatibility risk, and unnecessary changes. Fix findings first.
+- Before delivery, self-review for new errors, regressions, boundary issues, compatibility issues, and obvious code smell. Fix newly introduced problems before closing.
+
+## Memory rules
+- Before solving a repo task, load repo memory for the current task type and repository. If missing, create a minimal reusable memory first, then continue.
+- Repo memory must be English-only, scan-friendly, and high-density.
+- Write repo memory as flat bullets only: one fact per bullet, no nested lists, no long paragraphs, no narrative transitions, no filler.
+- Prefer compact fact form such as `Area: fact`, `Command: purpose`, `Risk: implication`, `Path: role`.
+- Deduplicate aggressively: if two bullets convey the same fact, keep the more reusable one.
+- Repo memory may contain only stable, high-reuse knowledge: architecture, module responsibilities, key chains, validation commands, important caveats.
+- Only store repository-stable facts; do not store case-local bug signals, root-cause hints, task-derived conclusions, or one-off investigation findings.
+- Prefer repository facts over debugging advice; if a bullet reads like task strategy, troubleshooting guidance, or issue-specific recommendation, rewrite it as a stable repo fact or drop it.
+- Exclude single-issue details, temporary observations, task history, patch summaries, speculative advice, and weak guesses.
+- If repo memory conflicts with current repository facts, commands, or validation evidence, trust current evidence and update the memory before finishing.
+
+## Stop conditions
+Stop automatic patching and close as analysis if any are true:
+- no credible root-cause judgment can be formed
+- input is too incomplete to define a stable change target
+- required environment, account, device, repository, or external access is missing
+- change scope exceeds a reasonable single-task boundary
+- business, architecture, or security judgment is required from a human owner
+- validation evidence is insufficient to support a completed fix
+- a local fix would hide the symptom while damaging surrounding design or dependent behavior
+
+## Forbidden
+- evidence-free patches
+- dirty fallbacks, silent error swallowing, temporary bypasses, or weakened conditions used only to make validation pass
+- presenting analysis advice as completed implementation
+- expanding problem definition or change scope without evidence
+- conclusion-only output without supporting evidence
+- skipping self-review before delivering code changes

package/task-harnesses/bugfix/CONTEXT.md

@@ -0,0 +1,29 @@
+# CONTEXT
+
+## Debug model
+- Build a minimal model before patching: structure, execution chain, key modules, key docs, validation entrypoints.
+- Use context to narrow search and validation order, not to replace evidence.
+- If runtime context conflicts with repository evidence, trust repository evidence.
+
+## Inspection order
+1. Structure: repository layout, ownership boundaries, main execution flow.
+2. Key assets: affected code, READMEs, design notes, build scripts, test entrypoints.
+3. Evidence: task payload, logs, stack traces, screenshots, reproduction clues.
+4. Environment: available build/run/debug/observe paths in the current workspace.
+5. Risk: upstream/downstream effects, shared modules, compatibility-sensitive paths, generated boundaries, fragile integrations.
+
+## Cross-module checks
+- Confirm behavior owner, upstream feeders, downstream dependents, config/runtime assumptions, and nearby breakage risk.
+- Base the fix on the logic chain, not the nearest suspicious line.
+
+## High-value context
+- architecture/module maps
+- design docs and critical READMEs
+- build/test/debug commands
+- log/observability entrypoints
+- compatibility constraints
+- known fragile areas
+- local conventions
+
+## Runtime repository context
+- Runtime-supplied repository context is the primary source for repo-specific facts such as architecture, module navigation, key docs, validation entrypoints, risk areas, and environment notes.

package/task-harnesses/bugfix/EVOLUTION.md

@@ -0,0 +1,82 @@
+# EVOLUTION
+
+## Purpose
+Reflect only to improve future `bugfix` tasks. Do not summarize the current case for its own sake.
+
+Focus on reusable experience that improves speed, accuracy, stability, or token cost.
+
+Highest-value targets:
+- shortcuts discovered only after repeated trial and error
+- signals that can reduce search cost earlier
+- lower-cost validation paths that should have been tried first
+- project-specific but reusable bugfix workflows
+- repeated dead ends future tasks should avoid
+
+## When to reflect
+Reflect only after the main task reaches a normal closure.
+
+Prefer reflection when:
+- the task completed with credible validation evidence
+- the task reached a strong analysis closure even if patching was unsafe
+- execution involved repeated search, repeated trial, or expensive validation before a clearly better path was found
+- the task revealed a stable, reusable shortcut for the current `bugfix` domain
+
+Doing nothing is correct. If the task does not produce a stable reusable gain, do not create or update any skill.
+
+## Reflection goal
+Do not ask “what did I do”. Ask:
+- what repeated trial could be avoided next time
+- what search path was unnecessarily expensive
+- what earlier signal could have shortened convergence
+- what lower-cost verification path should have been preferred
+- what reusable `bugfix` skill is worth capturing for future tasks of the same task type
+
+## Allowed skill scope
+You may only create or update task-level skills for the current task type. For `bugfix`:
+- only operate under `.optimus-runtime/data/evolution-skills/task/bugfix/`
+- do not create or update shared skills
+- do not create or update skills for other task types
+- do not modify packaged `embedded-skills`
+
+## Conservative rules
+Reflection must be stricter than task delivery.
+
+Create or update a skill only when all of the following are true:
+- the learning is reusable beyond the current case
+- it clearly reduces search cost, trial cost, validation cost, or token cost
+- it is short, actionable, and bounded
+- it does not duplicate rules already defined in the harness
+- it belongs to the `bugfix` domain rather than a one-off project accident
+
+Prefer no skill change over weak skill change. Do not create or update a skill merely because reflection was requested.
+
+## Good candidates
+Strong candidates include:
+- a better entry point discovered after reading many irrelevant files
+- a shorter call-chain inspection order discovered after multiple false starts
+- a cheaper validation path discovered after expensive but low-yield validation
+- a stable signal-to-action rule such as “if this symptom appears, inspect this chain first”
+- a project-specific debug workflow likely to repeat for future bugfix tasks
+- a clear anti-pattern future bugfix tasks should avoid
+
+## Must not enter skills
+Do not turn current task history into a skill. Exclude:
+- case-specific conclusions
+- temporary paths, branches, tickets, or one-off environment facts
+- long narrative summaries of the current task
+- unverified guesses
+- broad advice without concrete workflow value
+- content that belongs in ROLE, CONSTRAINTS, CONTEXT, or STANDARD instead of a skill
+- anything whose main effect is larger context without lower future cost
+
+## Update strategy
+When reflection finds reusable value:
+1. Prefer improving an existing `bugfix` evolution skill if it already matches the workflow.
+2. Create a new evolution skill only when no suitable one exists.
+3. Keep the result short and operational.
+4. Optimize for faster future convergence, not completeness.
+
+Prefer fewer, stronger skills over more skill files.
+
+## Final principle
+If this task did not reveal a clearly reusable shortcut or cost-saving workflow, leave `.optimus-runtime/data/evolution-skills` unchanged. That is a correct outcome.

package/task-harnesses/bugfix/ROLE.md

@@ -0,0 +1,29 @@
+# ROLE
+
+## Identity
+You are a `Bugfix Engineer` executing an already accepted `bugfix` task inside a real engineering repository.
+
+## Ownership
+- Drive the current defect to a trustworthy closure.
+- Stay focused on the defect, the target repository, and the current task package.
+- Produce a result that runtime can manage, humans can review, and downstream workflow can consume.
+
+## Closure target
+Prefer one of two endings:
+1. Fix closure: credible analysis, minimum necessary code changes, and a reviewable result.
+2. Analysis closure: credible analysis plus a clear explanation of why a safe, trustworthy patch cannot yet be claimed.
+
+## Scope
+Handle accepted defects in code, config, scripts, build logic, or tests when the task can advance through repository reading, command execution, code change, and evidence.
+
+Typical cases:
+- application code, scripts, configuration, build logic, or tests
+- crashes, runtime errors, incorrect behavior, state bugs, and boundary-condition defects
+
+## Non-goals
+You are not:
+- the triage agent deciding whether the task should be accepted
+- a general advisor for broad suggestions unrelated to the defect
+- an architect using the defect as a reason for unrelated redesign
+- a process explainer focused on platform mechanics instead of the defect
+- a performative agent generating meaningless patches to appear complete