agentic-engineering-harness 0.4.16

package/docs/V0.4.15.md

@@ -0,0 +1,365 @@
+# v0.4.15 — Issue-driven execution
+
+v0.4.15 makes an **existing GitHub issue** a first-class input to the Harness while preserving the existing trust hierarchy: the remote issue is fetched and frozen, then a sealed QuickContract or SDD/TaskContract becomes normative for the active run.
+
+## Goal
+
+A user or Paseo-hosted lead can say:
+
+> Implement issue #142.
+
+The operational equivalent is:
+
+```bash
+aeh issue implement 142
+```
+
+or:
+
+```bash
+aeh run --issue 142
+```
+
+The user does not need to manually create an SDD, duplicate the issue, create a branch, create a worktree, select implementers, manage the review/remediation loop, or perform accepted delivery writes when deterministic finalization is enabled.
+
+## Lifecycle
+
+```text
+GitHub issue
+   |
+   v
+fetch + validate issue identity/state
+   |
+   v
+freeze title/body + SHA-256 snapshot
+   |
+   v
+intake evidence
+(paths, labels/domains, risk, acceptance, flags)
+   |
+   v
+read-only planner normalization when non-trivial
+   |
+   v
+deterministic QUICK/SPEC decision
+   |
+   +--> QuickContract
+   |
+   `--> complete SDD + TaskContract + Gherkin
+             |
+             v
+       validate + seal
+             |
+             v
+bind EXISTING issue to delivery state
+             |
+             v
+reuse/create issue-linked branch
+             |
+             v
+optional Paseo worktree
+             |
+             v
+normal aeh run lifecycle
+             |
+             v
+deterministic validation -> reviews -> convergence -> lead acceptance
+             |
+             v
+optional deterministic commit -> push -> draft PR -> Closes #issue
+```
+
+## CLI
+
+### Inspect
+
+```bash
+aeh issue inspect 142
+```
+
+Fetches the issue and shows preliminary QUICK/SPEC evidence without creating a TaskContract.
+
+### Import/freeze
+
+```bash
+aeh issue import 142
+```
+
+Creates `GH-142` as a sealed task without executing implementation.
+
+For explicit issue revision acceptance:
+
+```bash
+aeh issue import 142 --refresh
+```
+
+If an active Paseo delivery workspace already exists, refresh is blocked unless explicitly forced:
+
+```bash
+aeh issue import 142 --refresh --force
+```
+
+### Complete execution
+
+```bash
+aeh issue implement 142
+```
+
+Equivalent entrypoint:
+
+```bash
+aeh run --issue 142
+```
+
+Optional profile:
+
+```bash
+aeh issue implement 142 --profile maximum-quality
+```
+
+The final CLI summary includes delivery status and the PR URL when finalization creates/reuses a PR.
+
+## Repository resolution
+
+The issue repository is resolved from:
+
+1. `delivery.github.repository` when configured;
+2. otherwise the repository's `origin` remote.
+
+The issue endpoint rejects GitHub pull requests returned from `/issues/<number>`; issue-driven execution is intentionally issue-specific.
+
+Public issues may be fetched without authentication. Private repositories require a usable token. Token resolution follows the delivery configuration and environment:
+
+```text
+configured tokenEnv
+GH_TOKEN
+GITHUB_TOKEN
+GITHUB_PAT
+```
+
+Tokens are never serialized into the issue snapshot, TaskContract or delivery state.
+
+## Frozen issue source
+
+The Harness stores:
+
+```text
+.harness/issues/GH-142.json
+```
+
+with repository, issue number/URL, title/body, state, labels, timestamps and SHA-256 of normalized title/body.
+
+The TaskContract records the same source identity and fingerprint.
+
+Only **title and body** are treated as normative remote content for the hash. Labels can influence initial routing/triage but changing a label does not silently rewrite requirements. Comments are not incorporated into the active normative contract unless a later intake version explicitly adds that policy.
+
+## Planner normalization
+
+Non-trivial issues or issues without directly extractable acceptance statements can be sent to the configured read-only planner:
+
+```yaml
+workflow:
+  issueIntake:
+    plannerAgent: planner
+```
+
+The planner may inspect repository code/tests/architecture to derive implementation detail and existing invariants. It returns a machine-validated intake structure containing problem/outcome, explicit or repository-derived requirements, acceptance scenarios, scope/domains, risk, constraints, proposed design, implementation tasks/non-goals and unresolved decisions.
+
+The planner cannot directly write normative artifacts. The Harness validates its structured output and writes the QuickContract/SDD itself.
+
+If the planner runtime fails or returns invalid output, deterministic extraction provides a fallback rather than making the intake dependent on one LLM session.
+
+## Product-decision boundary
+
+The planner/intake distinguishes:
+
+```text
+ready
+requires_product_decision
+spec_contradiction
+```
+
+Repository-derived implementation details are allowed when supported by existing evidence. Product/business choices that cannot be determined from the issue/repository are not invented.
+
+Those become `REQUIRES_PRODUCT_DECISION`. Contradictory authoritative intent becomes `SPEC_CONTRADICTION`. Both follow the Harness human-on-exception policy.
+
+## QUICK vs SPEC
+
+The issue is passed through the same deterministic triage rules used by normal requests.
+
+A QUICK result still requires:
+
+- explicit **concrete** bounded file scope;
+- low risk;
+- no security/auth/architecture/schema/migration/public API/new-dependency escalation signals;
+- observable acceptance statements.
+
+Wildcard scope such as `**`, `src/**`, `src/*.ts` or brace expansion is not accepted as a bounded QUICK scope even if it is represented by one pattern.
+
+Anything outside that boundary becomes a full issue-derived SDD.
+
+Issue-derived SDD requirement IDs are stable:
+
+```text
+GH-142-R1
+GH-142-R2
+...
+```
+
+The generated proposal/spec/design/tasks/Gherkin/TaskContract must pass ordinary traceability validation before sealing.
+
+## Existing issue reuse
+
+Issue-driven intake seeds the delivery record with the existing issue identity. Therefore downstream handoff **does not create another issue**.
+
+```text
+GitHub #142
+    |
+    v
+GH-142 delivery record
+    |
+    v
+handoff sees issueNumber=142
+    |
+    v
+skip issue creation
+```
+
+Reusing an already-frozen TaskContract also re-seeds the delivery identity, so deleting ephemeral delivery state cannot cause the next issue implementation to create a duplicate issue.
+
+## Branch reuse
+
+The configured branch pattern remains:
+
+```yaml
+delivery:
+  github:
+    branchPattern: feature/gh-{issue}-{slug}
+```
+
+For an existing issue the Harness first checks the exact remote ref. If it already exists, it reuses that branch. Otherwise it creates it from the captured originating/base branch.
+
+No force push, amend or rebase is used as part of intake recovery/finalization.
+
+## Paseo worktree
+
+When Paseo delivery is enabled, issue-driven handoff reuses the v0.4.14 worktree mechanism:
+
+```text
+issue -> existing/new branch -> Paseo checkout-branch worktree
+```
+
+The sealed task context, including the issue snapshot, is materialized into the worktree. Implementation, deterministic validation, review, remediation and Graphify execute against that workspace while control state remains in the original checkout.
+
+## ISSUE_DRIFT
+
+Before each issue-derived run, the Harness re-fetches the issue title/body and recalculates the fingerprint.
+
+If the fingerprint differs from the frozen TaskContract:
+
+```text
+ISSUE_DRIFT
+```
+
+The active run is not silently reinterpreted. The user/lead explicitly accepts revised issue intent with `--refresh` when appropriate; an active implementation workspace makes refresh guarded and requires explicit `--force`.
+
+## Accepted GitHub finalization
+
+Git writes remain outside agent permissions. When enabled:
+
+```yaml
+delivery:
+  github:
+    enabled: true
+    finalizeOnAcceptance: true
+    pullRequestDraft: true
+```
+
+finalization runs only **after** the resulting report is PASS, including configured review/quality/lead gates.
+
+The deterministic control plane:
+
+1. verifies that execution is on the exact issue-linked branch;
+2. stages the accepted work with `git add -A`;
+3. creates one normal commit (`GH-142: <issue title>`), using repository Git identity when configured and a Harness fallback identity otherwise;
+4. checks that the branch is actually ahead of the originating/base branch;
+5. pushes `HEAD` to the exact issue branch without force;
+6. searches for an existing open PR for that head/base pair;
+7. reuses it when present, otherwise creates a draft PR by default;
+8. writes `Closes #142` in the PR body.
+
+The worker agents still have `gitWrite: deny`; enabling this feature does not grant them commit/push authority.
+
+A push/token/remote permission problem becomes `BLOCKED_EXTERNAL` and marks human intervention required rather than returning a false successful delivery. A local branch/control-plane inconsistency is `SYSTEM_FAILURE` and is not mislabeled as a product decision.
+
+If the branch contains no commits beyond the base, finalization returns `NO_CHANGES` instead of manufacturing an empty PR.
+
+## Configuration
+
+Default initialized projects include:
+
+```yaml
+workflow:
+  issueIntake:
+    enabled: true
+    snapshotDir: .harness/issues
+    verifyDriftOnRun: true
+    requireOpen: true
+    plannerAgent: planner
+    autoHandoff: true
+
+delivery:
+  github:
+    enabled: false
+    tokenEnv: GH_TOKEN
+    branchPattern: feature/gh-{issue}-{slug}
+    finalizeOnAcceptance: true
+    pullRequestDraft: true
+  paseo:
+    enabled: false
+    createWorkspace: true
+    autoUseWorkspace: true
+```
+
+`autoHandoff` invokes the configured delivery flow automatically when GitHub/Paseo delivery is enabled. It does not turn remote delivery on by itself: the `delivery.*.enabled` flags remain explicit project choices.
+
+For automatic issue branch + worktree + PR delivery, enable both GitHub and Paseo delivery. GitHub finalization intentionally refuses to commit a different current branch, protecting the control checkout from accidental delivery writes.
+
+## Trust hierarchy
+
+For issue-driven work:
+
+```text
+GitHub issue at intake time
+        |
+        v
+frozen issue snapshot
+        |
+        v
+sealed QuickContract / SDD + TaskContract
+        |
+        v
+implementation and validation
+```
+
+During the active run:
+
+```text
+sealed TaskContract/SDD > mutable remote issue > agent memory/summaries
+```
+
+The remote issue remains provenance and collaboration input; the frozen/sealed contract prevents mutable requirements during execution.
+
+## Natural-language/Paseo behavior
+
+The `engineering-workflow` skill recognizes existing-issue implementation intent. A lead started from Paseo mobile should translate:
+
+> Implement issue #142.
+
+into:
+
+```bash
+aeh issue implement 142
+```
+
+The same command owns intake, freeze, optional handoff/worktree, autonomous implementation/review and configured accepted-delivery finalization. The lead should not ask the user to manually perform intermediate Harness commands unless a genuine human-on-exception state is reached.

package/docs/V0.4.16.md

@@ -0,0 +1,229 @@
+# v0.4.16 — Toolchain & Bootstrap
+
+v0.4.16 makes the Harness distributable as a normal npm development tool while provisioning its external engineering toolchain explicitly and reproducibly.
+
+## Distribution boundary
+
+The Harness itself is an npm package and CLI. It is not an application runtime dependency and it does not use npm `postinstall` to mutate the host.
+
+Recommended project installation:
+
+```bash
+npm install --save-dev agentic-engineering-harness
+npm exec aeh -- init --setup
+```
+
+For a repository that already declares the Harness but has no local `node_modules`, use a pinned temporary bootstrap invocation and let `aeh setup` install the project dependencies afterwards:
+
+```bash
+npm exec --yes --package=agentic-engineering-harness@0.4.16 -- aeh setup
+```
+
+## Explicit provisioning
+
+`aeh setup` is the host/toolchain mutation boundary. It:
+
+1. loads `.harness/toolchain.yaml`;
+2. inspects active Harness runtimes, orchestration, validators and project stack;
+3. computes the minimum required tool closure;
+4. reuses `.harness/toolchain.lock.json` when it exists;
+5. provisions missing managed tools through mise;
+6. optionally provisions heavy validators as immutable OCI images;
+7. installs detected project dependencies from lockfiles;
+8. writes machine-local `.harness/toolchain.state.json`;
+9. makes the provisioned bin paths visible to all subsequent Harness subprocesses;
+10. leaves verification to `aeh doctor`.
+
+There is no requirement to run `mise activate` in the user's interactive shell.
+
+## Source, lock and machine state
+
+```text
+.harness/toolchain.yaml
+        |
+        | desired tool constraints/capabilities
+        v
+AEH resolver
+        |
+        +--> .config/mise/conf.d/aeh.toml
+        |       generated mise layer
+        |
+        +--> .harness/toolchain.lock.json
+        |       exact logical versions + OCI digests
+        |
+        `--> .harness/toolchain.state.json
+                machine-local bin paths; gitignored
+```
+
+`toolchain.yaml` is authoritative source configuration. `toolchain.lock.json` should normally be committed after the first successful setup. `toolchain.state.json` must not be committed because it contains machine-local paths.
+
+When a lock exists, setup uses its exact resolved versions unless `--update-lock` is requested.
+
+## Automatic capability resolution
+
+Default auto mode selects tools only when they are needed.
+
+Examples:
+
+```text
+runtime:codex              -> codex
+runtime:opencode           -> opencode
+orchestration:paseo        -> paseo
+code-intelligence:graphify -> uv + graphify
+validation:opa             -> opa
+security-tool:opengrep     -> opengrep
+validator:trivy            -> trivy
+project:bun                -> bun
+project:dotnet             -> dotnet
+```
+
+The resolver also recognizes Node/package-manager files, Python/uv, .NET project files/global.json, Go modules and Cargo projects as capability evidence. The default pack currently provisions the common Harness/Pawra requirements; project overlays can add additional language tools without changing AEH core.
+
+## Project-pinned versions
+
+Before creating a new lock, AEH respects existing project version authority where supported:
+
+- `.node-version` / `.nvmrc` override the default Node version;
+- `global.json` pins the .NET SDK;
+- `packageManager: bun@...` pins Bun;
+- projects may directly override any default tool definition in `.harness/toolchain.yaml`.
+
+A first setup may resolve `latest` declarations; after it succeeds the AEH lock becomes the reproducible resolved environment. `aeh setup --update-lock` is the explicit upgrade operation.
+
+## Mise backend
+
+Mise is the default provisioning adapter because it can install tools from multiple ecosystems without making those tools npm dependencies of AEH. Where the mise registry provides an Aqua mapping, the default pack prefers Aqua over raw GitHub release autodetection.
+
+The default pack uses:
+
+```text
+node                       core mise backend
+bun                        core mise backend
+dotnet                     core mise backend
+npm:@openai/codex          Codex
+npm:@getpaseo/cli          Paseo
+aqua:anomalyco/opencode    OpenCode
+aqua:open-policy-agent/opa
+aqua:opengrep/opengrep
+aqua:aquasecurity/trivy
+uv
+pipx:graphifyy             Graphify CLI
+```
+
+AEH first tries an existing `mise` executable. If it is absent, explicit setup bootstraps the configured minimum mise release through a pinned npm invocation equivalent to:
+
+```bash
+npm exec --yes --package=mise@2026.7.0 -- mise --version
+```
+
+This is an explicit setup action rather than an npm installation side effect. The version is taken from `manager.minimumVersion`, not hard-coded in setup logic.
+
+## OCI validator strategy
+
+The toolchain supports:
+
+```yaml
+strategy:
+  validators: local
+  containerEngine: podman
+```
+
+or:
+
+```yaml
+strategy:
+  validators: prefer-container
+  containerEngine: podman
+```
+
+If `prefer-container` is selected and the configured engine is available, tools with a container alternative are pulled and locked by immutable RepoDigest. A wrapper is generated under `.harness/bin` so the rest of the Harness still invokes the normal tool command.
+
+Default OCI-capable tools currently include OPA and Trivy. If Podman is unavailable, the resolver falls back to the mise/local definition instead of making containers mandatory.
+
+## Project dependencies
+
+After tool provisioning, setup detects common project dependency locks:
+
+```text
+package-lock.json  -> npm ci
+pnpm-lock.yaml     -> corepack pnpm install --frozen-lockfile
+bun.lock/bun.lockb -> bun install --frozen-lockfile
+yarn.lock          -> corepack yarn install --immutable
+                      (Yarn 1 uses --frozen-lockfile)
+uv.lock            -> uv sync --frozen
+*.sln/*.slnx/*.csproj/global.json -> dotnet restore
+```
+
+Extra deterministic commands may be declared under `projectDependencies.commands`.
+
+Use `--skip-project-deps` when the repository or CI owns that phase separately.
+
+## Commands
+
+```bash
+# Show what auto mode requires
+aeh toolchain show
+
+# Compile only the generated mise layer
+aeh toolchain compile
+
+# Side-effect-free plan
+aeh setup --dry-run
+
+# Provision exactly what the project currently requires
+aeh setup
+
+# Deliberately refresh fuzzy/latest versions and rewrite the lock
+aeh setup --update-lock
+
+# Prefer OCI alternatives when available
+aeh setup --prefer-containers
+
+# Install a named capability profile
+aeh setup --profile agents
+aeh setup --profile validation
+aeh setup --profile full
+
+# Bootstrap a repo and immediately provision it
+aeh init --setup
+
+# Prove the actual environment satisfies the Harness configuration
+aeh doctor
+```
+
+## Runtime PATH
+
+After setup, mise bin directories and AEH-generated OCI wrappers are written to machine-local state. `runProcess` prepends those paths automatically, including when running from a Git worktree whose control checkout owns the state.
+
+This means Codex/OpenCode/Paseo/validators can be launched from Harness code without requiring users to modify `.bashrc`, `.zshrc` or IDE shell activation.
+
+## Packaging and publication
+
+`package.json` publishes the CLI entrypoint plus `dist`, templates, presets, policies, schemas, skills and docs. CI runs `npm run release:check`, which includes the complete typecheck/test/build sequence and `npm pack --dry-run`.
+
+A GitHub Release publishing workflow is included at `.github/workflows/publish.yml`. It is designed for npm Trusted Publishing through GitHub Actions OIDC rather than a long-lived write token. Because npm requires a package to exist before a trusted publisher can be attached, the **first registry publication is a one-time bootstrap operation**; after that, configure the npm package's trusted publisher to `JamesMorales04/agentic-engineering-harness` + `publish.yml`, then normal GitHub Releases can publish with short-lived OIDC credentials.
+
+See `docs/PUBLISHING.md` for the exact bootstrap and steady-state release sequence.
+
+## Trust and installation policy
+
+- npm installs AEH only;
+- no `postinstall` performs host mutations;
+- `aeh setup` is explicit and auditable;
+- system prerequisites such as Git are checked, not silently installed with sudo;
+- managed tool versions and OCI digests are locked;
+- machine-local paths are not versioned;
+- project dependency managers use their lock/frozen modes;
+- `aeh doctor` is verification, while `aeh setup` is reconciliation;
+- release CI validates the actual npm tarball before publishing.
+
+The intended lifecycle is:
+
+```text
+clone
+  -> bootstrap AEH npm package
+  -> aeh setup
+  -> aeh doctor
+  -> Paseo / engineering lead
+  -> implement issue #X
+```

package/docs/V0.4.md

@@ -0,0 +1,28 @@
+# v0.4 — Agent Topology and Governance
+
+## v0.4.1 — Registry and model aliases
+Agent identity is separated from model identity and runtime. `@brain` and `@workhorse` are aliases, not hard-coded policy in routing logic.
+
+## v0.4.2 — Profiles and JSONC compiler
+`.harness/agents.source.jsonc` is maintained source. `.harness/generated/agents.json` is generated runtime. Prompt paths are hashed and inlined; `aeh agents check` fails on active-profile drift.
+
+## v0.4.3 — Routing and output contracts
+Routing can match intent, domains, file scopes and risk. Planner, implementer, reviewer, validator, recovery and orchestrator outputs have Zod contracts. A normalized delegation task contains `id`, `summary`, `agent`, `scope`, `dependencies`, `acceptance` and `risk`.
+
+## v0.4.4 — Typed recovery
+Failures use the canonical taxonomy: `PATCH_CONTEXT_MISMATCH`, `TOOL_FAILURE`, `MISSING_CONTEXT`, `WRONG_AGENT`, `VALIDATION_FAILURE`, `REVIEW_FAILURE`, `AMBIGUOUS_OUTPUT`, `CONFLICTING_RESULTS`. Recovery actions are versioned data and bounded by the existing repair budget.
+
+## v0.4.5 — Drift gates
+The topology audit checks model/runtime references, prompt files, skills, routing references, output contracts, permission/capability coherence and source-to-generated-runtime drift.
+
+## v0.4.6 — Permissions, capabilities and native agents
+A logical agent resolves to runtime + model + optional runtime-native agent. OpenCode direct/Podman execution maps this to `opencode run --model ... --variant ... --agent ...`. Harness permissions are translated to OpenCode runtime permissions through `OPENCODE_CONFIG_CONTENT` for direct/Podman execution; OpenCode merges inline runtime config with project/global config. `gitWrite` produces explicit deny/ask/allow rules for mutating Git commands. Codex direct execution uses its bare model name. Paseo remains cross-provider transport; native-agent selection through Paseo is only allowed when that runtime explicitly declares `nativeAgentViaPaseo`, and runtime permission enforcement remains the responsibility of the configured Paseo provider.
+
+## v0.4.7 — Graphify-assisted parallelism
+Planner tasks are scheduled into waves. Dependencies and overlapping file scopes are hard conflicts. When a Graphify before-snapshot maps both scopes into the same structural community, the scheduler conservatively keeps them apart. Missing Graphify data falls back to dependency/scope scheduling.
+
+## v0.4.8 — Finding normalization
+Reviewer findings use one schema with severity, category, location, evidence, impact, recommended fix and suggested agent. Findings at the same/adjacent location with compatible categories are merged while preserving the highest severity and merge provenance.
+
+## Compatibility
+`orchestration.worker` remains as a legacy fallback when no agent topology is configured. New projects receive the topology template automatically.

package/docs/VALIDATION.md

@@ -0,0 +1,23 @@
+# Validation
+
+LLM output is an untrusted proposal. Acceptance is based on executable evidence.
+
+## Registry
+
+Project and TaskContract validators share a `ValidatorSpec` with `id`, `adapter`, optional `command`, `required`, timeout/working-directory and adapter-specific `options`.
+
+Supported v0.2.5 adapters: `gherkin`, `graphify`, `opengrep`, `trivy`, `playwright`, `openapi`, `pact`, `command`.
+
+A missing optional external tool returns WARN. A missing required tool returns FAIL. An installed tool that reports defects returns FAIL; `required` controls availability, not whether findings are ignored.
+
+## Requirement mapping
+
+Requirements may reference a validator by adapter or validator ID, e.g. `gherkin` or `api-compat`. `aeh sdd validate` rejects unresolved references.
+
+## OPA evidence
+
+OPA receives changed dependency-manifest and schema-affecting paths from the Git diff instead of placeholder values. Dependency-manifest changes are treated conservatively as dependency-change evidence.
+
+## OpenAPI
+
+The built-in adapter accepts JSON or YAML snapshots and rejects supported breaking changes: removed paths/operations/responses/schemas/properties, newly-required parameters/properties, and schema type changes. Full semantic `$ref` compatibility can be delegated to a dedicated project CLI through `adapter: command` when needed.

package/package.json

@@ -0,0 +1,18 @@
+{
+  "name": "agentic-engineering-harness",
+  "version": "0.4.16",
+  "description": "OSS-first engineering harness for deterministic, spec-driven and issue-driven multi-agent software delivery.",
+  "type": "module",
+  "bin": { "engineering-harness": "./dist/entry.js", "aeh": "./dist/entry.js" },
+  "files": ["dist", "templates", "presets", "policies", "schemas", "skills", "docs"],
+  "scripts": { "build": "tsc -p tsconfig.json", "dev": "tsx src/entry.ts", "test": "vitest run", "test:watch": "vitest", "typecheck": "tsc -p tsconfig.json --noEmit", "check": "npm run typecheck && npm test && npm run build", "release:check": "npm run check && npm pack --dry-run" },
+  "engines": { "node": ">=22" },
+  "dependencies": { "@opentelemetry/api": "^1.9.0", "commander": "^14.0.1", "minimatch": "^10.0.3", "yaml": "^2.8.1", "zod": "^4.0.17" },
+  "devDependencies": { "@types/node": "^24.2.1", "tsx": "^4.20.3", "typescript": "^5.9.2", "vitest": "^3.2.4" },
+  "repository": { "type": "git", "url": "git+https://github.com/JamesMorales04/agentic-engineering-harness.git" },
+  "homepage": "https://github.com/JamesMorales04/agentic-engineering-harness#readme",
+  "bugs": { "url": "https://github.com/JamesMorales04/agentic-engineering-harness/issues" },
+  "publishConfig": { "access": "public" },
+  "license": "Apache-2.0",
+  "keywords": ["ai-agents", "codex", "opencode", "paseo", "sdd", "github-issues", "issue-driven-development", "quick-contract", "gherkin", "agent-routing", "agent-presets", "mcp", "github-delivery", "worktrees", "multi-model", "quality-convergence", "toolchain", "mise", "bootstrap", "human-on-exception", "deterministic-validation", "engineering-harness", "slsa", "opentelemetry"]
+}

package/policies/core/dependency-policy.rego

@@ -0,0 +1,12 @@
+package harness.dependencies
+
+default allow_new_dependencies := false
+
+allow_new_dependencies if {
+  input.taskContract.constraints.newDependencies == true
+}
+
+deny contains "new dependency is not authorized by the TaskContract" if {
+  count(input.newDependencies) > 0
+  not allow_new_dependencies
+}

package/policies/core/schema-policy.rego

@@ -0,0 +1,12 @@
+package harness.schema
+
+default allow_schema_changes := false
+
+allow_schema_changes if {
+  input.taskContract.constraints.schemaChanges == true
+}
+
+deny contains "schema change is not authorized by the TaskContract" if {
+  input.schemaChanged == true
+  not allow_schema_changes
+}