feat: inherent capabilities

docs/settings.md

@@ -498,7 +498,7 @@ Individual built-in tools are toggled by their own keys, e.g. `bash.enabled`, `l
 
 ### Runtime
 
-The `run`, `check`, `build`, `insights`, and `profile` tools execute on a managed runtime binary, as do the six JVM tools (`jvm_run`, `jvm_disassemble`, `jvm_format`, `jvm_jar`, `jvm_deps`, `jvm_javadoc`), which compile and run Java/Kotlin on the embedded JVM, and the two long-running flows `runtime_debug` (a CDP/DAP debug endpoint) and `serve` (static files over HTTP), which are supervised as `hub` jobs rather than by the runtime layer. `project_advice` rides the same gate but is read-only: it asks the runtime for its build/run/test/install guidance for the current project and executes nothing. All fourteen are gated on `runtime.enabled`; when it is off, none of them register.
+The `run`, `check`, `insights`, and `profile` tools execute on a managed runtime binary, as do four JVM specialists (`jvm_disassemble`, `jvm_format`, `jvm_jar`, and `jvm_deps`). Java and Kotlin execution is part of `run`. The `serve` long-running flow is supervised as a `hub` job rather than by the runtime layer. All nine tools are gated on `runtime.enabled`; when it is off, none register.
 
 ```yaml
 runtime:
@@ -513,7 +513,7 @@ runtime:
 
 | Key | Type | Default | Notes |
 |---|---|---|---|
-| `runtime.enabled` | boolean | `true` | Enable the innate `run`/`check`/`build`/`insights`/`profile`, `runtime_debug`/`serve`, and `jvm_*` tools executed on the managed runtime. Off disables the tools; `aura runtime status` still runs, reporting the disabled state with a nonzero exit. |
+| `runtime.enabled` | boolean | `true` | Enable the innate `run`/`check`/`insights`/`profile`, `serve`, and four specialized `jvm_*` tools executed on the managed runtime. Off disables the tools; `aura runtime status` still runs, reporting the disabled state with a nonzero exit. |
 | `runtime.adapter` | `process` \| `embedded` \| `auto` | `process` | Select the runtime process, require the embedded runtime library, or choose the library automatically when it is available and compatible. Explicit `embedded` mode never falls back to the process adapter when the library is missing or incompatible. |
 | `runtime.autoDownload` | boolean | `true` | Fetch the pinned runtime into the config dir on first use when no binary is found. Ignored when `runtime.path` is set. |
 | `runtime.path` | string | `""` | Explicit runtime binary path; overrides discovery and disables auto-download. Also settable per-run with `--runtime <path>`, which reports `source: flag` in `aura runtime status`. |
@@ -524,36 +524,23 @@ The process adapter remains the default. `AURA_RUNTIME_ADAPTER=process|embedded|
 
 Embedded library resolution checks a nonblank `runtime.embeddedPath`, then a nonblank `AURA_RUNTIME_EMBEDDED_LIB`, then the pinned managed runtime version's `lib` directory, and finally the `lib` directory adjacent to an already-resolved real runtime binary. Candidates must be regular files. Resolution never scans `PATH` for shared libraries.
 
-#### Bundled runtime skills
+#### Inherent runtime guidance
 
-Five skills ship with the agent and are discovered in every session:
-`skill://runtime` (the `run`/`check`/`build` surface and when to prefer it over
-`bash` or `eval`), `skill://insights`, `skill://profiling`, `skill://jvm`, and
-`skill://stateful-debugger` (the `runtime_debug`/`serve` flows and their
-`hub`-owned lifecycle). They carry the strategy the per-tool descriptions cannot
-— when `cputracing` beats `cpusampling`, why a one-shot instrumented run emits no
-`close` event, how the JVM main class is derived.
+Runtime selection is part of Aura's system policy whenever runtime tools are
+registered. The agent chooses direct execution (`run`), validation (`check`),
+instrumentation (`insights`), profiling (`profile`), serving, and the four JVM
+specialists from the available tool inventory. Project builds use the project's
+declared build command rather than a separate runtime tool. Tool prompts remain
+the argument and failure-shape reference.
 
-| Key | Type | Default | Notes |
-|---|---|---|---|
-| `skills.enableBundled` | boolean | `true` | Discover the bundled runtime skills. Also retired automatically when `runtime.enabled` is off, since they document tools that are then unregistered. |
-
-They are materialized into `<config dir>/agent/builtin-skills/<name>/SKILL.md`
-(the skill machinery reads a skill's body back from its path) and rewritten from
-the embedded copy whenever a file drifts, so edit them there and the change is
-reverted on the next launch. Turning either toggle off removes that tree again.
-
-Only what the agent itself wrote is ever deleted: the directory carries a
-`.bundled.json` manifest naming the skills it materialized, and a skill you place
-in there yourself is left alone (it is discovered like any other). To override a
-bundled skill, author one of the same name in any normal skills directory — the
-bundled provider sits at the lowest skill priority, so yours wins. To drop one,
-list its name in `skills.ignoredSkills`.
+These capabilities are implicit: they are not materialized as skills, do not
+appear in skill lists or `/skill:*` commands, and require no skill-load round
+trip. `runtime.enabled` remains the single capability gate.
 
 
 `aura doctor` reports the resolved runtime alongside the rest of the install (identity and Bun version, native addon, registered tools, plugin health, terminal capabilities, memory backend); `aura doctor --json` emits the same report structurally, and `aura --check` collapses it to one line for clean-env CI probes. None of the three touch a model, the network, or provisioning — the runtime probe is read-only and never downloads a binary, whatever `runtime.autoDownload` says. All three exit nonzero only on a hard failure: a Bun older than the minimum, or a runtime that is enabled but unavailable. Optional misses (runtime disabled, no memory backend, missing plugin directory) are warnings and still exit 0.
 
-See [run](./tools/run.md), [check](./tools/check.md), [build](./tools/build.md), [insights](./tools/insights.md), and [profile](./tools/profile.md) for per-tool behavior, and [jvm_run](./tools/jvm_run.md), [jvm_disassemble](./tools/jvm_disassemble.md), [jvm_format](./tools/jvm_format.md), [jvm_jar](./tools/jvm_jar.md), [jvm_deps](./tools/jvm_deps.md), [jvm_javadoc](./tools/jvm_javadoc.md) for the JVM suite, and [runtime_debug](./tools/runtime_debug.md) and [serve](./tools/serve.md) for the two supervised long-running flows (their handle is a `hub` job name, so `hub logs`/`hub stop` apply — there is no separate stop tool), and [project_advice](./tools/project_advice.md) for the read-only project-guidance tool. `jvm_jar` (create) and `jvm_javadoc` are the only runtime tools that write into your project: both require `output` to resolve *inside* the session cwd, both refuse an existing output unless `overwrite: true` is passed, and `jvm_javadoc`'s replace path additionally only accepts a previous docs output (empty, or carrying `index.html` plus one of javadoc's own scaffolding files). Containment is enforced after resolving symlinks, so a symlinked directory cannot redirect either write outside the cwd.
+See [run](./tools/run.md), [check](./tools/check.md), [insights](./tools/insights.md), and [profile](./tools/profile.md) for core behavior; [jvm_disassemble](./tools/jvm_disassemble.md), [jvm_format](./tools/jvm_format.md), [jvm_jar](./tools/jvm_jar.md), and [jvm_deps](./tools/jvm_deps.md) for JVM specialists; and [serve](./tools/serve.md) for the supervised long-running flow. Its handle is a `hub` job name, so `hub logs` and `hub stop` apply; there is no separate stop tool. `jvm_jar` creation and `jvm_deps` with `output` are the only runtime flows that write into the project. Both require `output` to resolve inside the session cwd and refuse an existing output unless `overwrite: true` is passed. Containment is enforced after resolving symlinks, so a symlinked directory cannot redirect either write outside the cwd.
 
 ### Native computer use
 

docs/superpowers/plans/2026-08-01-inherent-harness-capabilities.md

@@ -0,0 +1,121 @@
+# Inherent Harness Capabilities Implementation Plan
+
+**Goal:** Make runtime execution and the universal engineering method inherent system behavior, remove their implicit skill/UI footprint, keep the common tool surface compact, and prove selection with a minimal benchmark.
+
+**Architecture:** Static Handlebars policy in the default system prompt is conditional on registered tools. Canonical Superpowers core skills are filtered only inside the canonical plugin provider. `run` and `check` stay essential; expensive analysis, profiling, debug, serving, and JVM operations stay discoverable. `RuntimeService.#call` provides one bounded telemetry boundary for the remaining runtime protocol.
+
+**Constraints:**
+
+- Work only in `.wt/inherent-capabilities`.
+- Preserve same-named user/project skills and all domain skills.
+- Never expose source, paths, arguments, output, or exception messages as telemetry dimensions.
+- Keep the process adapter default and preserve existing runtime lifecycle behavior.
+- Remove obsolete tools and protocol methods cleanly; no aliases or compatibility shims.
+- Do not commit unless explicitly requested.
+
+## Task 1: Promote inherent policy and remove skill surfaces
+
+**Change**
+
+- Add compact engineering-method and runtime-selection policy to `src/prompts/system/system-prompt.md`.
+- Remove the bundled runtime skill provider, setting, materialization, command, and provider-specific tests.
+- Filter only the canonical Superpowers workflow names inside `src/discovery/claude-plugins.ts`.
+- Preserve domain skills and same-named skills from every other provider.
+
+**Contract**
+
+- The prompt advertises only tools actually registered.
+- Runtime and core workflow skills do not appear in the skill catalog or slash-command UI.
+- No skill load is needed before an inherent runtime/tool action.
+
+## Task 2: Add runtime telemetry and status classification
+
+**Change**
+
+- Observe every remaining runtime protocol call once in `src/runtime/telemetry.ts`.
+- Publish bounded `runtime.call.completed` events and OTLP counter/histogram data.
+- Annotate the active tool span with method, action, language, outcome, duration, exit code, and killed state where available.
+- Mark non-zero or killed execution results as tool errors through the shared classifier in `src/runtime/format.ts`.
+
+**Contract**
+
+- Success, process failure, timeout, cancellation, and protocol failure produce distinct bounded outcomes.
+- Telemetry failures never alter runtime results.
+- Generic tool status and runtime-specific status agree.
+
+## Task 3: Compact the runtime tool surface
+
+**Change**
+
+- Keep `run` and `check` essential.
+- Keep `insights`, `profile`, `serve`, `jvm_disassemble`, `jvm_format`, `jvm_jar`, and `jvm_deps` discoverable.
+- Route standalone Java/Kotlin through `run`; retain only four specialized JVM artifact/analysis tools.
+- Remove `build`, `project_advice`, `runtime_debug` and its CDP/DAP launch mode, `jvm_javadoc`, and the `jvm_run` alias from tool registration, protocol, service, endpoint routing, telemetry, renderers, fixtures, docs, settings copy, and tests.
+- Keep project artifact production on declared external build commands.
+- Trim remaining tool prompts and schemas to decision-relevant guidance.
+
+**Contract**
+
+- Runtime-enabled default requests carry only the `run` and `check` schemas.
+- Discoverable tools remain invocable through `xd://` or explicit `--tools`.
+- The runtime service exposes no dead protocol methods.
+- Provider payload tests cap the essential pair and the full discoverable family.
+
+## Task 4: Tighten JVM dependency workflows
+
+**Change**
+
+- Let `jvm_deps` accept either an existing `.java`/`.kt`/`.class`/`.jar`/class directory path or inline language plus source.
+- Compile source in scratch space; analyze artifacts directly without redundant compilation.
+- Allow an optional guarded cwd-relative report output, requiring `overwrite: true` to replace a file.
+- Refuse directories and any real or symlinked destination outside the working directory.
+
+**Contract**
+
+- Source-path and inline-source calls report dependencies without modifying project files unless `output` is supplied.
+- Artifact mode invokes `jdeps` directly.
+- Output containment survives parent and leaf symlinks.
+
+## Task 5: Keep benchmarks minimal and task-specific
+
+**Change**
+
+- Keep the focused smoke to two tasks: `typescript-execution` and `jvm-dependencies`.
+- Give each task six baseline file/shell tools, `run`/`check`, and only its required specialist.
+- Retain the broader suite for regression coverage; the focused smoke remains the optimization loop.
+- Hash the exact prompt, tool prompt, registration, and skill-filter inputs used by the inherent treatment.
+
+**Smoke command**
+
+```bash
+bun run bench:inherent --prefix inherent-compact-smoke
+```
+
+**Smoke gates**
+
+- Both tasks pass.
+- Every trial uses a runtime tool.
+- `run` is selected before `bash`.
+- No promoted runtime/core workflow skill is loaded.
+- Telemetry preflight distinguishes success and intentional failure.
+
+**Comparison command**
+
+```bash
+AURA_LEGACY_BINARY=/absolute/path/to/legacy-aura bun run bench:inherent \
+  --attempts 3 --prefix inherent-compact-comparison
+```
+
+**Comparison gates**
+
+- All smoke gates pass.
+- Median paired tool calls do not increase.
+- Median paired input tokens do not increase.
+
+## Task 6: Verify and clean up
+
+1. Run focused prompt, registry, runtime, endpoint, renderer, JVM, benchmark, settings, doctor, and docs-coverage tests.
+2. Run `bun check` in `packages/coding-agent` and `packages/metaharness`.
+3. Run root `bun run check:ts`.
+4. Run the inherent smoke against the source-mounted coding agent.
+5. Update `docs/settings.md`, `docs/aura/FORK.md`, `packages/metaharness/README.md`, and the coding-agent Unreleased changelog.