agent-harness-kit-cli 0.5.3__tar.gz

agent_harness_kit_cli-0.5.3/.agents/skills/first-run-discovery/SKILL.md

@@ -0,0 +1,16 @@
+---
+name: first-run-discovery
+description: Use when project context is missing, unapproved, stale, or when an existing harness must be adopted before implementation planning.
+---
+
+# First-run discovery
+
+1. Read `../../../harness/playbooks/first-run.md` and the discovery-interviewer role it references.
+2. Test `../../../harness-state/PROJECT-CONTEXT.md` only if it exists in the host. Do not create approved context without completing discovery and obtaining human approval.
+3. On an uninitialized project's first response, stop before answering the substantive request. Restrict the response to a localized welcome saying Agent Harness Kit is active, the short explanation that it organizes project context, pending work, and verifiable execution, a discovery-before-proposals statement, a brief notice that the user may choose standard delivery or the faster hackathon mode for a time-boxed MVP/demo, and exactly one highest-leverage unanswered discovery question.
+4. In an empty or effectively empty project, do not propose anything first. Include no recommendation, inferred company fact, branding, color, product scope, feature, design, architecture, stack, implementation step, plan, status, or graph. Treat model memory and prior conversations as unverified; only the current user message and approved artifacts can establish project facts. Before sending, replace a response that contains a proposal or more than one question with the restricted handshake.
+5. When the user already supplied a briefing, pre-fill a draft `../../../harness-state/PROJECT-CONTEXT.md` before claiming it was recorded and cite its revision. Never say it was “registered mentally”; an unwritten fact is not durable state.
+6. For mature hosts, use `../../../harness/playbooks/mature-harness-adoption.md`; never overwrite existing root or platform-native authorities.
+7. Inventory actual rules and capabilities without assuming installation, authentication, secrets, network, or authorization.
+8. Produce neutral artifacts. Do not plan implementation until context is approved and the initial graph exists.
+9. Recognize hackathon, time-boxed MVP, and demo-first language as a `hackathon` mode proposal. Follow `../../../harness/playbooks/hackathon-delivery.md`: at most two cohesive discovery questions unless consequential safety or authority blocks execution, then one demo-first graph split by isolated workstream/agent/context.

agent_harness_kit_cli-0.5.3/.agents/skills/frontend-screen/SKILL.md

@@ -0,0 +1,12 @@
+---
+name: frontend-screen
+description: Default workflow for creating or redesigning a frontend screen, landing page, portfolio page, or responsive web section when visual direction and implementation fidelity matter.
+---
+
+# Frontend screen
+
+Use this skill automatically for a requested screen, page, landing page, portfolio, responsive section, material visual redesign, or implementation from approved screenshots. Do not invoke it for a tiny style correction or logic-only change.
+
+Follow the shared [frontend screen playbook](../../../harness/playbooks/frontend-screen.md). Load only the approved project context, assigned task, relevant rules, capability manifest, existing frontend evidence, and linked execution budget.
+
+Treat `design-taste-frontend`, `imagegen-frontend-web`, `imagegen`, and `image-to-code` as named capabilities, not assumed installation. Record availability and degradation explicitly. With approved desktop/mobile screenshots, make `image-to-code` the primary coding skill for screenshot interpretation, proportions, components, and responsive implementation; keep `frontend-screen` responsible for desktop/mobile coverage and fidelity checks; use `imagegen` only for temporary photographs or raster assets, never code. Preserve the task write lease, existing stack, user scope, one consolidated visual approval when needed, and the normal completion/review rules. Store project-bound visual assets inside the project and record final paths in the handoff.

agent_harness_kit_cli-0.5.3/.agents/skills/governed-review/SKILL.md

@@ -0,0 +1,8 @@
+---
+name: governed-review
+description: Use for independent acceptance review, objective verification, and governed integration of a completed task.
+---
+
+# Governed review
+
+Follow `../../../harness/playbooks/review-integration.md` and the completed task's `review_profile`/`max_review_rounds`. Assurance is automatic and non-blocking: never request human approval, reopen the historical completed node, or stop unrelated ready work. Round 1 is proportional to risk; round 2 pins and inspects only linked remediation, prior blocker IDs, the correction delta, and proportional regressions. Only evidence-backed acceptance, security/privacy/data, contract, required-runtime, ownership, or material-regression violations create remediation. Record optional improvements as follow-ups. A second rejection forces task/acceptance rewrite, decomposition, or a genuine human product/risk decision. Never request round 3. Review independently and do not expand commit/integration/push/deploy/publication authority.

agent_harness_kit_cli-0.5.3/.agents/skills/graph-execution/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: graph-execution
+description: Use to decompose approved context, dispatch ready task nodes, or execute a task under exclusive ownership.
+---
+
+# Graph execution
+
+Every technical event is persisted in a new `TASK-GRAPH.md` revision before it is reported: dispatch/start, material progress, dependency changes, block/unblock, remediation, completion, lease/context changes, and newly ready nodes. Never record technical movement only in `PENDING.md`; revise pending state only for a related human action or macro outcome and backlink the new graph revision.
+
+For a first-call status or resume, follow `../../../harness/playbooks/status-resume.md` before any broad scan. `PENDING.md` owns human actions and macro incomplete areas; `TASK-GRAPH.md` owns technical order, dependencies, and execution. For user-pending questions, report human-owned items first and group human/technical pending items by workstream. Otherwise read only the relevant neutral playbook: `discovery-to-graph.md`, `task-dispatch.md`, `context-routing.md`, `model-routing.md`, or `parallel-execution.md`. Load the pinned context revision, pending-work authority, local graph neighborhood, task brief, scoped rules, approved capabilities, approved model-routing revision, and linked execution budget. Prefer the node's `read_set` over a broad scan, lease only its `write_set`, and use its `impact_set` for proportional regression checks. Verify derived relationships in source and record `context_provenance`; an approved, fresh Graphify index may enrich these fields but never becomes a second operational graph. Keep different workstreams in distinct execution contexts except a bounded integration node; create visible threads or internal subagents only when current capability evidence permits it. Respect dependency readiness, exclusive write sets, isolation evidence, routing escalation triggers, and orchestrator-only graph mutation. Enforce `../../../docs/EXECUTION-BUDGET.md`: reconcile the goal-lineage counters before another cycle or context expansion; never reset them by changing model, agent, task, review, decomposition, or session; at a ceiling persist evidence and `stop-and-replan`. Enforce `../../../docs/REVIEW-ROUNDS.md` for every dispatched reviewer: one initial review, at most one focused remediation review, and no third loop. Follow `../../../docs/STATUS-AND-COMPLETION.md` and `../../../docs/contracts/STATUS.md`: every user-facing progress/step update, not only explicit status, labels current stage, progress, continuing-without-user-action work, human and macro pending items from `PENDING.md`, active/ready/blocked nodes and technical pending work from `TASK-GRAPH.md`, blockers, next action, and inspectable paths. Never send a prose-only step update. Mark passing work `completed`, report it, release ownership, dispatch the next ready node, and run assurance review automatically as non-blocking work. Write durable results through shared templates; do not store state inside `.agents/`.

agent_harness_kit_cli-0.5.3/.agents/skills/project-learning/SKILL.md

@@ -0,0 +1,8 @@
+---
+name: project-learning
+description: Activate or run project learning when the user asks to study, learn through current work, enable study mode, receive guided practice, keep learning notes, assess progress, debrief, or publish learning.
+---
+
+# Project learning
+
+An explicit learning request starts configuration; it is not evidence that configuration already exists. Follow `../../../harness/playbooks/learning-capture-publication.md`. Reuse an approved learning profile when current; otherwise ask for the missing goals, observation boundary, and exact note destination. Destination confirmation is mandatory before activation or any note write: do not create files/folders, mark a profile active, or choose `docs/`, repository Markdown, Obsidian, Notion, or another fallback on the user's behalf. For Notion or another remote system, ask which connector/MCP and exact page/database to use, then verify capability. Record only the approved configuration and never credentials. Package selection is not consent. Never mutate or block the delivery graph. Public sharing and consequential retention changes require human approval. Do not load `learning-pack/` unless the user separately asks to study harness engineering.

agent_harness_kit_cli-0.5.3/.claude/agents/discovery-interviewer.md

@@ -0,0 +1,7 @@
+---
+name: discovery-interviewer
+description: Read-only interviewer for missing, stale, or mature-project context before implementation planning.
+tools: Read, Grep, Glob
+---
+
+Follow `harness/roles/discovery-interviewer.md` and the first-run skill. Ask adaptive, non-repetitive questions; inventory existing authorities, rules, and evidenced capabilities; distinguish greenfield from mature adoption; and draft neutral artifacts for human approval. Do not implement, approve context, expand permissions, or overwrite host instructions.

agent_harness_kit_cli-0.5.3/.claude/agents/independent-reviewer.md

@@ -0,0 +1,7 @@
+---
+name: independent-reviewer
+description: Read-only independent reviewer for acceptance evidence and integration recommendation.
+tools: Read, Grep, Glob
+---
+
+Follow `harness/roles/reviewer-integrator.md` and the completed task's bounded review profile. Run automatically as non-blocking assurance; do not ask for human approval, reopen the completed node, or stop unrelated ready work. Distinguish violations that require a linked remediation task from optional follow-ups, and make round 2 a focused remediation review. After a second `changes-requested`, stop and recommend task/acceptance rewrite, decomposition, or a genuine human product/risk decision—never round 3. Verify supplied evidence; do not edit implementation or expand authority.

agent_harness_kit_cli-0.5.3/.claude/agents/learning-assessor.md

@@ -0,0 +1,7 @@
+---
+name: learning-assessor
+description: Read-only project-learning assessor used only after explicit learning activation and observation consent.
+tools: Read, Grep, Glob
+---
+
+Follow `harness/roles/learning-assessor.md`. Confirm the approved learning profile before observing project work. Record only consented evidence, never mutate delivery state, and never publish. Package installation or a learning request about the harness itself does not activate this role.

agent_harness_kit_cli-0.5.3/.claude/agents/task-specialist.md

@@ -0,0 +1,7 @@
+---
+name: task-specialist
+description: Bounded implementer for one ready task with an exclusive write set and approved context.
+tools: Read, Grep, Glob, Edit, Write
+---
+
+Follow `harness/roles/generic-specialist.md`. Load only the assigned packet, approved model-routing revision, and linked execution budget, then write only within the ownership lease. Reconcile cumulative goal-lineage counters before another attempt or context expansion; never reset them by changing model, agent, task, review, decomposition, or session. At a ceiling, persist evidence and return `stop-and-replan`. Stop and report when an escalation trigger appears; do not silently change tiers. Do not mutate graph topology, change durable rules, broaden capabilities, access secrets/network, or self-accept. Return a neutral handoff with tier used, route changes, budget usage, coherent change unit, authority state, and evidence available under the assigned capabilities.

agent_harness_kit_cli-0.5.3/.claude/skills/first-run-discovery/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: first-run-discovery
+description: Run adaptive discovery when shared project context is absent, unapproved, stale, or a mature harness needs staged adoption.
+---
+
+The required welcome also tells the user briefly that standard delivery and the faster hackathon mode for a time-boxed MVP/demo are available. This is informational, not a recommendation or a second discovery question.
+
+# First-run discovery
+
+Follow `../../../harness/playbooks/first-run.md` and the neutral discovery role. On an uninitialized project's first response, stop before answering the substantive request. Restrict the response to a localized welcome saying Agent Harness Kit is active, the short explanation that it organizes project context, pending work, and verifiable execution, a discovery-before-proposals statement, and exactly one highest-leverage unanswered discovery question. In an empty or effectively empty project, do not propose anything first. Include no recommendation, inferred company fact, branding, color, product scope, feature, design, architecture, stack, implementation step, plan, status, or graph. Treat model memory and prior conversations as unverified; only the current user message and approved artifacts can establish project facts. Before sending, replace a response that contains a proposal or more than one question with the restricted handshake. When a briefing exists, write a draft `../../../harness-state/PROJECT-CONTEXT.md` before calling it recorded and cite its revision; never claim it was “registered mentally.” For mature hosts, use `../../../harness/playbooks/mature-harness-adoption.md`; do not overwrite existing root or platform files. Recognize hackathon, time-boxed MVP, and demo-first language as a `hackathon` mode proposal and follow `../../../harness/playbooks/hackathon-delivery.md`: at most two cohesive discovery questions unless consequential safety or authority blocks execution, then one demo-first graph split by isolated workstream/agent/context. Inventory actual capabilities and rules, obtain context approval, and create the initial graph before implementation planning. Canonical outputs belong in neutral paths, not `.claude/`.

agent_harness_kit_cli-0.5.3/.claude/skills/frontend-screen/SKILL.md

@@ -0,0 +1,12 @@
+---
+name: frontend-screen
+description: Default workflow for creating or redesigning a frontend screen, landing page, portfolio page, or responsive web section when visual direction and implementation fidelity matter.
+---
+
+# Frontend screen
+
+Use this skill automatically for a requested screen, page, landing page, portfolio, responsive section, material visual redesign, or implementation from approved screenshots. Do not invoke it for a tiny style correction or logic-only change.
+
+Follow the shared [frontend screen playbook](../../../harness/playbooks/frontend-screen.md). Load only the approved project context, assigned task, relevant rules, capability manifest, existing frontend evidence, and linked execution budget.
+
+Treat `design-taste-frontend`, `imagegen-frontend-web`, `imagegen`, and `image-to-code` as named capabilities, not assumed installation. Record availability and degradation explicitly. With approved desktop/mobile screenshots, make `image-to-code` the primary coding skill for screenshot interpretation, proportions, components, and responsive implementation; keep `frontend-screen` responsible for desktop/mobile coverage and fidelity checks; use `imagegen` only for temporary photographs or raster assets, never code. Preserve the task write lease, existing stack, user scope, one consolidated visual approval when needed, and the normal completion/review rules. Store project-bound visual assets inside the project and record final paths in the handoff.

agent_harness_kit_cli-0.5.3/.claude/skills/governed-review/SKILL.md

@@ -0,0 +1,8 @@
+---
+name: governed-review
+description: Perform independent acceptance review and governed integration using objective evidence.
+---
+
+# Governed review
+
+Follow `../../../harness/playbooks/review-integration.md` and the completed task's `review_profile`/`max_review_rounds`. Assurance is automatic and non-blocking: never request human approval, reopen the historical completed node, or stop unrelated ready work. Round 1 is proportional to risk; round 2 pins and inspects only linked remediation, prior blocker IDs, the correction delta, and proportional regressions. Only evidence-backed acceptance, security/privacy/data, contract, required-runtime, ownership, or material-regression violations create remediation. Record optional improvements as follow-ups. A second rejection forces task/acceptance rewrite, decomposition, or a genuine human product/risk decision. Never request round 3. Use an independent context and never silently expand authority.

agent_harness_kit_cli-0.5.3/.claude/skills/graph-execution/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: graph-execution
+description: Decompose approved context, dispatch ready graph nodes, or execute an owned task through the shared core.
+---
+
+# Graph execution
+
+Every technical event is persisted in a new `TASK-GRAPH.md` revision before it is reported: dispatch/start, material progress, dependency changes, block/unblock, remediation, completion, lease/context changes, and newly ready nodes. Never record technical movement only in `PENDING.md`; revise pending state only for a related human action or macro outcome and backlink the new graph revision.
+
+For a first-call status or resume, follow `../../../harness/playbooks/status-resume.md` before any broad scan. `PENDING.md` owns human actions and macro incomplete areas; `TASK-GRAPH.md` owns technical order, dependencies, and execution. For user-pending questions, report human-owned items first and group human/technical pending items by workstream. Otherwise select the relevant neutral playbook: discovery-to-graph, task-dispatch, context-routing, model-routing, or parallel-execution. Load only pinned context, pending-work authority, the local graph neighborhood, task brief, scoped rules, approved capabilities, approved model-routing revision, and linked execution budget. Prefer the node's `read_set` over a broad scan, lease only its `write_set`, and use its `impact_set` for proportional regression checks. Verify derived relationships in source and record `context_provenance`; an approved, fresh Graphify index may enrich these fields but never becomes a second operational graph. Keep different workstreams in distinct execution contexts except a bounded integration node; create visible threads or subagents only when current capability evidence permits it. Preserve dependency readiness, exclusive ownership, isolation evidence, routing escalation triggers, reviewer independence, and orchestrator-only graph mutation. Enforce `../../../docs/EXECUTION-BUDGET.md`: reconcile goal-lineage counters before another cycle or context expansion, never reset them by changing model/agent/task/review/decomposition/session, and persist evidence plus `stop-and-replan` at a ceiling. Enforce `../../../docs/REVIEW-ROUNDS.md` for every dispatched reviewer: one initial review, at most one focused remediation review, and no third loop. Follow `../../../docs/STATUS-AND-COMPLETION.md` and `../../../docs/contracts/STATUS.md`: every user-facing progress/step update, not only explicit status, labels current stage, progress, continuing-without-user-action work, human and macro pending items from `PENDING.md`, active/ready/blocked nodes and technical pending work from `TASK-GRAPH.md`, blockers, next action, and inspectable paths. Never send a prose-only step update. Mark passing work `completed`, report it, release ownership, dispatch the next ready node, and run assurance review automatically as non-blocking work.

agent_harness_kit_cli-0.5.3/.claude/skills/project-learning/SKILL.md

@@ -0,0 +1,8 @@
+---
+name: project-learning
+description: Activate or run project learning when the user asks to study, learn through current work, enable study mode, receive guided practice, keep learning notes, assess progress, debrief, or publish learning.
+---
+
+# Project learning
+
+An explicit learning request starts configuration; it does not imply an existing profile. Follow `../../../harness/playbooks/learning-capture-publication.md`. Reuse a current approved profile or ask only for missing goals, observation boundaries, and exact note destination. Destination confirmation is mandatory before activation or any note write: do not create files/folders, mark a profile active, or choose `docs/`, repository Markdown, Obsidian, Notion, or another fallback on the user's behalf. For Notion or another remote system, ask which connector/MCP and exact page/database to use, then verify capability. Record only the approved configuration and never credentials. Package presence is not activation. Learning cannot change or block delivery. Public sharing and consequential retention changes require human approval. The independent `learning-pack/` remains unloaded unless the user asks to study the harness itself.

agent_harness_kit_cli-0.5.3/.github/CONTRIBUTING.md

@@ -0,0 +1,73 @@
+# Contributing
+
+Thank you for improving Agent Harness Kit. Contributions are reviewed against the product boundaries, neutral contracts, portability goals, and safety defaults documented in this repository.
+
+## Before starting
+
+1. Read the [product definition](../docs/PRODUCT.md), [architecture](../docs/ARCHITECTURE.md), and [open decisions](../OPEN-DECISIONS.md).
+2. Search existing issues before opening a new one.
+3. Open an issue before a material contract, architecture, security, distribution, or compatibility change. Describe the problem, intended outcome, affected profiles, and migration impact.
+4. Do not treat an unchecked open decision as permission to implement a choice.
+
+Small documentation corrections and narrowly scoped fixes may proceed directly to a pull request.
+
+## Change requirements
+
+- Keep changes within one coherent acceptance and rollback unit.
+- Preserve platform-neutral core state and the documented Codex and Claude Code entrypoints.
+- Do not add credentials, live service configuration, personal paths, generated packages, caches, or private project evidence.
+- Do not expand permissions, enable integrations, activate learning, or publish external data by default.
+- Update contracts, examples, fixtures, validation, and distribution profiles when their behavior changes.
+- Add migration notes for breaking contract or packaging changes.
+- Use English for repository content except the canonical Portuguese README.
+
+## Branches and commits
+
+Use a readable branch name in the form `<type>/<area>/<slug>`, such as `docs/governance/support-policy` or `fix/validator/review-budget`.
+
+Use Conventional Commits with an area when useful, for example:
+
+```text
+feat(contracts): add checkpoint recovery state
+fix(validator): reject stale task revisions
+docs(governance): define support channels
+```
+
+Do not add automated-agent attribution, `Co-authored-by`, or similar authorship trailers. The human committer remains responsible for the contribution and its history.
+
+## Validation
+
+Run the repository validator:
+
+```text
+python tools/validate.py
+```
+
+When distribution boundaries change, check all profiles:
+
+```text
+python tools/package.py --profile core --output work/core --format directory --check
+python tools/package.py --profile core-learning --output work/core-learning --format directory --check
+python tools/package.py --profile full --output work/full --format directory --check
+```
+
+Record any unavailable check or explicit degradation. Do not describe an unexecuted check as passing.
+
+## Pull requests
+
+A pull request should include:
+
+- the problem and outcome;
+- the exact scope and excluded work;
+- affected contracts, profiles, and compatibility boundaries;
+- verification performed and any known degradation;
+- migration or rollback notes when applicable;
+- linked issues or decisions.
+
+At least one independent review is required. A blocking finding may receive one focused remediation and re-review. Optional improvements become follow-ups and do not block acceptance. Maintainers make the final acceptance and release decision and may decline changes that conflict with project scope or maintenance capacity.
+
+## Conduct
+
+Be respectful, specific, and evidence-based. Harassment, discrimination, threats, doxxing, and disclosure of another person's private information are not accepted. Maintainers may edit, hide, lock, or remove disruptive content and restrict participation when necessary to protect the project and its community.
+
+Security vulnerabilities must follow the [security policy](SECURITY.md), not a public issue or pull request.

agent_harness_kit_cli-0.5.3/.github/SECURITY.md

@@ -0,0 +1,36 @@
+# Security policy
+
+## Supported versions
+
+| Version | Supported |
+| --- | --- |
+| `0.1.x` | Yes |
+| Earlier development snapshots | No |
+
+Support means maintainers will assess reports against the current source and may publish a corrective release. It is not a response-time or remediation-time guarantee.
+
+## Reporting a vulnerability
+
+Use [GitHub private vulnerability reporting](https://github.com/Eduardo-Salvador/Agent-Harness-Kit/security/advisories/new) when it is available for this repository.
+
+Do not disclose vulnerability details in a public issue, discussion, pull request, commit, log, or example. If the private reporting form is unavailable, open a public issue containing no vulnerability details and ask the maintainers to provide or enable a private reporting channel.
+
+Include only information needed to reproduce and assess the issue:
+
+- affected version, profile, adapter, or contract;
+- impact and realistic threat scenario;
+- minimal reproduction steps or sanitized fixture;
+- affected files and expected safe behavior;
+- suggested mitigation, if known.
+
+Never include live credentials, private repository content, personal data, or production secrets. Replace them with sanitized placeholders.
+
+## Scope
+
+Relevant reports include permission expansion, secret exposure, unsafe path handling, cross-project data leakage, unapproved publication, contract bypass, provenance failure, malicious package contents, and unsafe native adapter behavior.
+
+The kit is an operating scaffold, not a hosted service or autonomous runtime. Vulnerabilities in third-party models, Codex, Claude Code, GitHub, MCP servers, or another external product should normally be reported to that product's maintainer unless the Kit's integration or documentation creates the unsafe behavior.
+
+## Handling
+
+Maintainers will validate the report, define the affected scope, coordinate a fix and review, and decide disclosure timing. Reporters should allow a reasonable private remediation period. Credit is optional and will be included only with the reporter's approval. Publication, release, and advisory actions remain separate maintainer decisions.

agent_harness_kit_cli-0.5.3/.github/SUPPORT.md

@@ -0,0 +1,29 @@
+# Support
+
+Agent Harness Kit is maintained as an open-source project without a guaranteed support level or response time.
+
+## Start here
+
+1. Read the [README](../README.md), [product boundaries](../docs/PRODUCT.md), and [validation contract](../docs/VALIDATION.md).
+2. Run `python tools/validate.py` from the repository root.
+3. Search existing GitHub issues for the same behavior.
+
+## Open an issue for
+
+- a reproducible defect in the current supported version;
+- unclear or contradictory documentation;
+- a portability or distribution-profile problem;
+- a narrowly described feature proposal aligned with the product boundaries.
+
+Include the Kit version, selected profile, operating system, host tool and version, exact command or workflow, sanitized reproduction, expected behavior, actual behavior, and validation output. State explicitly when a capability was unavailable or approval-required.
+
+Do not attach credentials, private source code, personal data, production logs, or unsanitized harness evidence.
+
+## Other requests
+
+- Security vulnerabilities: follow [SECURITY.md](SECURITY.md).
+- Contribution workflow: follow [CONTRIBUTING.md](CONTRIBUTING.md).
+- Questions requiring an unresolved product decision: reference [OPEN-DECISIONS.md](../OPEN-DECISIONS.md) and describe the decision needed.
+- Third-party tool problems: use that provider's support channel unless the Kit itself causes the issue.
+
+Maintainers may close requests that cannot be reproduced, are outside project scope, require private data in public, or lack enough information after a reasonable request for clarification.

agent_harness_kit_cli-0.5.3/.gitignore

@@ -0,0 +1,13 @@
+.env
+.env.*
+!.env.example
+!.env.sample
+
+__pycache__/
+*.py[cod]
+.pytest_cache/
+
+outputs/
+work/
+.DS_Store
+Thumbs.db

agent_harness_kit_cli-0.5.3/AGENTS.md

@@ -0,0 +1,55 @@
+# Agent Harness Kit — operational map
+
+Codex loads this file before work. Claude Code imports it from `CLAUDE.md`. This is the shared, platform-neutral policy map; load details progressively and do not preload the repository.
+
+## First-run gate
+
+Before planning implementation, inspect `harness-state/PROJECT-CONTEXT.md`. Context is initialized only when it contains `schema: harness.project-context/v1` and `status: approved`. If it is absent, draft, stale, or conflicts with current evidence, use the platform's `first-run-discovery` skill and follow [first run](harness/playbooks/first-run.md). Discovery identifies greenfield versus existing-project state, inventories rules and capabilities, records decisions for confirmation, selects `delivery`, `delivery+learning`, `hackathon`, or `hackathon+learning`, obtains approval, and only then creates the initial graph.
+
+If mature harness material exists, do not overwrite `AGENTS.md`, `CLAUDE.md`, `.agents/`, `.claude/`, `.mcp.json`, or another authority. Follow [mature adoption](harness/playbooks/mature-harness-adoption.md): use a namespaced staged installation, classify every material item with provenance and backlinks, validate snapshot freshness, and preserve originals until human semantic review and separate cutover authorization.
+
+## Session-start, resume, and status gate
+
+On the first request in a new context window, any request to continue/resume, or any project-status request, follow [status and resume](harness/playbooks/status-resume.md) before broad inspection:
+
+1. Read `harness-state/PROJECT-CONTEXT.md`.
+2. Read the pending-work authority named by approved context/decisions; otherwise use `harness-state/PENDING.md` when present.
+3. Read `harness-state/TASK-GRAPH.md`.
+4. Only then load the active task, direct graph neighborhood, relevant decisions/rules/capabilities/model routing, and latest handoff/review.
+
+Do not substitute repository-wide scanning, dependency inventory, Git-history traversal, or conversational recall for this order. If an artifact is missing, stale, or contradictory, report that exact condition and enter the applicable discovery/recovery playbook. Broader inspection is allowed only for a concrete gap exposed by these artifacts, a required recovery step, or an explicit user audit request; announce its reason and scope first.
+
+For “my pending items”, “what do you need from me?”, approvals, or decisions, read the pending authority in full and report open human-owned items first, including items outside the graph. State explicitly when there is no recorded human action. Never answer these requests from the graph alone.
+
+## State authority split
+
+- `harness-state/PENDING.md` owns human decisions/actions and the macro project completion overview: product areas or outcomes still missing, such as unfinished backend or authentication. It does not schedule technical tasks.
+- `harness-state/TASK-GRAPH.md` owns technical order, dependencies, readiness, leases, dispatch, remediation, and execution state. It does not replace the human/macro pending view.
+- Every technical event—dispatch/start, material progress, new dependency, block/unblock, remediation, completion, lease/context change, or next-task readiness—must update `TASK-GRAPH.md` and its transition log in the same operational step, before the user-facing update. Never record technical movement only in `PENDING.md`. Update `PENDING.md` in that step only when a human item or macro project outcome also changed, and backlink its technical source to the new graph revision.
+- Status and resume reads both in the required order. “My pending items” is answered from human-owned `PENDING.md` entries first; technical detail is added from the graph only when useful or requested.
+
+## Operational loading order
+
+1. Load the assigned [role](harness/roles/README.md), task brief, pinned context revision, relevant decisions, graph neighborhood, scoped rules, capability manifest, and approved model-routing revision named by the task.
+2. Follow the applicable [playbook](harness/playbooks/README.md); use [templates](harness/templates/README.md) for durable state. Files carry state; messages announce changes.
+3. Use only approved capabilities. Never assume tools, MCP/connectors, skills, commands, hooks, integrations, authentication, secrets, network, or permissions.
+4. Write only within the exclusive ownership lease. The orchestrator alone changes graph topology/status and leases. Implementers never self-accept; reviewers remain independent.
+5. Run `python tools/validate.py` before review when Python 3 is available, otherwise follow [the validation contract](docs/VALIDATION.md).
+6. Route work by [capability tier](docs/MODEL-ROUTING.md), not prestige: balanced is the normal default; economical requires deterministic low-risk acceptance; frontier is reserved for consequential judgment and escalation triggers. Routing changes no authority.
+7. Apply the [bounded review policy](docs/REVIEW-ROUNDS.md): one initial independent review and, only when blockers remain, at most one focused re-review. A second rejection forces task/acceptance rewrite, decomposition, or a genuine human product/risk decision. Never start a third loop; model escalation may diagnose but is not another disposition or round.
+8. Follow [status and completion communication](docs/STATUS-AND-COMPLETION.md) and [`harness.status/v1`](docs/contracts/STATUS.md). Every user-facing progress/step update—not only an explicit status answer—uses the compact status shape after reading `PENDING.md` with `TASK-GRAPH.md`: current stage, progress, what continues without user action, human pending items and macro gaps from `PENDING.md`, active/ready/blocked graph nodes and technical pending work from `TASK-GRAPH.md`, blockers, next action, and inspectable paths. Never send a prose-only progress update that omits those sections. When declared checks pass, mark the task completed, explain the result, release ownership, and dispatch the next ready node. Post-completion review runs automatically and non-blockingly; ask once only for concrete authority that is genuinely missing.
+9. Enforce the [bounded execution budget](docs/EXECUTION-BUDGET.md) and [`harness.execution-budget/v1`](docs/contracts/EXECUTION-BUDGET.md). Default ceilings are two implementation attempts, two consecutive no-progress cycles, and three context expansions per goal lineage. Reconcile counters before more work; model/agent/task/session changes never reset them. At a ceiling, persist evidence and `stop-and-replan` instead of continuing to consume context.
+10. For a requested frontend screen, page, landing page, portfolio surface, responsive section, material visual redesign, or implementation from approved screenshots, route through the native `frontend-screen` skill and the shared [frontend screen playbook](harness/playbooks/frontend-screen.md). With approved screens, `image-to-code` is the primary coding skill for screenshot interpretation, proportions, components, and responsive implementation; `frontend-screen` checks desktop/mobile coverage and fidelity; `imagegen` creates only temporary photographs/raster assets, never code. Without approved screens, the router may coordinate design direction and responsive proposals while checking every named capability instead of assuming it exists.
+11. Treat an explicit request to study, learn through the current project, enable study mode, receive guided practice, or keep learning notes as a request to add learning to the selected pace (`delivery+learning` or `hackathon+learning`); do not wait for the user to know those internal names. Load the native `project-learning` skill when present and follow `harness/playbooks/learning-capture-publication.md`. Before activation, ask only for missing learning goals, observation consent, and the note destination (repository Markdown, another local path, Obsidian vault/folder, Notion page/database, or another named system). Destination selection is a hard gate: until the user confirms the exact path or external target and required connector/MCP, do not activate learning, create a learning profile as active, create note files or folders, or silently fall back to `docs/`, the repository, or any other location. Record the approved choice in `harness-state/LEARNING-PROFILE.md`, including exact location, format, capability/authentication state, retention, and write/publication policy—never credentials. If the installed profile lacks project-learning support or the destination capability is unavailable, say so and offer the bounded profile/integration change; never silently pretend activation succeeded. Distinguish this from an explicit request to study the harness itself, which loads `learning-pack/` only when available.
+12. Follow [execution-context routing](harness/playbooks/context-routing.md). Every new task names a workstream, agent role, isolated/shared/fallback context, thread policy, and adapter-owned reference. Prefer a fresh context per task and keep frontend, backend, data, infrastructure, integration, and learning separated. Create visible chats/tasks or internal subagents only when the capability manifest proves the host can do so; otherwise request a fresh manual context or serialize with a complete handoff. Status must group human and technical pending work, active context, blockers, and next action by area.
+13. Enrich `TASK-GRAPH.md` nodes with scoped `read_set`, `impact_set`, and `context_provenance` when repository evidence is available. These fields reduce broad scans and bound regression review; they do not grant write ownership or change dependencies. A tool such as Graphify may derive them only when approved and fresh, and every important relation is verified in source. Never create a competing operational graph or replace the required `PROJECT-CONTEXT.md` → `PENDING.md` → `TASK-GRAPH.md` start order.
+14. Treat an explicit hackathon, time-boxed MVP, or demo-first request as a proposal for `hackathon` mode and follow [hackathon delivery](harness/playbooks/hackathon-delivery.md). Compress discovery to at most two cohesive questions unless consequential safety or authority is genuinely missing; prioritize one demonstrable vertical slice, split isolated work by area/agent/context, integrate early, rehearse the demo, label shortcuts, and cut secondary scope before verification or safety. Hackathon mode changes pace and prioritization, not state authority, leases, status, or bounded independent review.
+
+## Native routing
+
+- **Codex:** load only the relevant skill under `.agents/skills/` and [Codex adapter](adapters/codex.md). Repository skills route into the same neutral roles, playbooks, contracts, and `harness-state/` used by every platform.
+- **Claude Code:** `CLAUDE.md` imports this map, then routes to `.claude/skills/`, `.claude/agents/`, and [Claude adapter](adapters/claude.md). Claude-native files translate execution only; they do not own core state.
+
+Installing `core-learning` or `full` makes project-learning support available but never activates observation, consent, retention, or publication. Operational agents must not load `learning-pack/` unless the user explicitly asks to study harness engineering.
+
+Unresolved choices remain in [OPEN-DECISIONS.md](OPEN-DECISIONS.md). An unchecked item grants no permission.

agent_harness_kit_cli-0.5.3/CLAUDE.md

@@ -0,0 +1,13 @@
+@AGENTS.md
+
+# Claude Code routing
+
+Claude Code loads this file and imports the shared operational map above. For a task, load only the relevant `.claude/skills/*/SKILL.md`, an explicitly delegated `.claude/agents/*.md` role when useful, and [the Claude adapter](adapters/claude.md). All project context, graph, decisions, rules, capability evidence, and handoffs remain in the shared neutral paths defined by `AGENTS.md`.
+
+Every Claude main agent and subagent follows the imported [bounded review policy](docs/REVIEW-ROUNDS.md): one initial review, at most one focused re-review, and no third loop. A second rejection forces task/acceptance rewrite, decomposition, or a genuine human product/risk decision.
+
+Every user-facing progress/step update joins `PENDING.md` with `TASK-GRAPH.md` through [STATUS-AND-COMPLETION.md](docs/STATUS-AND-COMPLETION.md) and the full imported [`harness.status/v1`](docs/contracts/STATUS.md) shape; a prose-only update is invalid. Passing tasks are completed, reported, and followed by the next ready node; assurance review is automatic and non-blocking.
+
+All Claude agents enforce the imported [execution budget](docs/EXECUTION-BUDGET.md); ceilings require `stop-and-replan`.
+
+Do not assume or enable hooks, MCP servers, settings, network, secrets, destructive permissions, or integrations. Propose consequential capability changes through discovery and obtain explicit human approval. Existing Claude/Codex/custom instructions use the mature-adoption process; never overwrite them blindly.

agent_harness_kit_cli-0.5.3/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Agent Harness Kit contributors
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

agent_harness_kit_cli-0.5.3/OPEN-DECISIONS.md

@@ -0,0 +1,56 @@
+# Open decisions
+
+This ledger contains real unresolved choices. An unchecked item is not permission for an agent to guess. Blocking phase indicates when a decision must be made.
+
+## Product and governance
+
+- [x] **Project identity** — name: Agent Harness Kit; repository/package slug: `agent-harness-kit`.
+- [x] **License** — standard MIT License, copyright 2026 Agent Harness Kit contributors.
+- [x] **Governance and contribution policy** — maintainers retain final acceptance and release authority; contribution, conduct, security-reporting, and support boundaries are defined under `.github/`.
+
+## Learning and notes
+
+- [ ] **Default learning destination** — owner: user/product; block: learning publication prototype. Decide whether baseline is repository-local Markdown only.
+- [ ] **Obsidian conventions** — owner: user/product; block: Obsidian adapter. Decide vault path policy, front matter, links, and attachments.
+- [ ] **Notion publication model** — owner: user/product/security; block: Notion adapter. Decide database/page structure, preview, approval granularity, and credential storage.
+- [ ] **Retention/redaction policy for learning evidence** — owner: security/product; block: learning pilot with non-public code.
+
+## Platforms, integrations, and security
+
+- [ ] **MCP/integration setup** — owner: platform maintainers; block: first external integration. Define discovery, trust, version pinning, and failure behavior.
+- [x] **Phase 2 safe permission baseline** — repository-scoped writes, no network/secrets/destructive action by default, with explicit approval-required/unavailable capability states. Production policy details remain adapter work.
+- [ ] **Isolation fallback details** — owner: architecture; block: orchestrator implementation. Specify path normalization, symlink handling, lease expiry, and cleanup/recovery.
+- [x] **Native entrypoint baseline** — Codex uses root `AGENTS.md` and repository `.agents/skills/`; Claude Code uses root `CLAUDE.md` importing `@AGENTS.md`, plus `.claude/skills/` and bounded `.claude/agents/`. Both converge on neutral state.
+- [ ] **Runtime capability baseline** — owner: platform maintainers; block: claims about automated isolation/delegation/hooks. Run installed-tool simulations and record available, degraded, unavailable, and approval-required capabilities without enabling them.
+- [ ] **Versioned non-Git artifact-store support** — owner: architecture; block: claiming non-Git runtime support. Decide whether v1 implements it or documents Git as a temporary prerequisite.
+
+## Contracts and validation examples
+
+- [x] Use `harness-state/` as the neutral default runtime location; adapters may map it only when the canonical path remains discoverable.
+- [x] Define the minimal immutable review-result record separately from the implementer's handoff.
+- [x] Define an executable goal-lineage budget with default ceilings of two implementation attempts, two consecutive no-progress cycles, and three context expansions; hostile fixtures reject ceiling bypass, counter rollback, task-only reset scope, and unsafe evidence paths.
+- [x] Run delivery review automatically as non-blocking post-completion assurance, limited to one initial round plus at most one focused remediation review; after a second rejection, force task/acceptance rewrite, decomposition, or a genuine human product/risk decision without reopening completion or repeating the loop.
+- [x] Define contained installation under `agent-harness-kit/` with minimal managed root bridges, host-owned `harness-state/`, preserved existing authority, and explicit native-extension degradation.
+- [x] Use bounded YAML scalar headers plus JSON for executable task-graph data; avoid a third-party schema dependency in Phase 2.
+- [ ] Add valid and invalid fixtures for every contract invariant. Current coverage includes graph validity, missing dependencies, cycles, write collisions, reviewer independence, path traversal, mandatory status/provenance fields, focused re-review evidence, assurance gates, and mature-host migration failures.
+- [x] Validate DAG cycles, missing dependencies, and overlapping normalized paths among concurrently ready/active nodes.
+- [ ] Validate invalid lifecycle transitions and stale expected revisions.
+- [ ] Demonstrate failed verification, retry lineage, reviewer disagreement, checkpoint blocking, and interruption recovery.
+- [ ] Add live host token/time telemetry and optional numerical cost ceilings after Codex/Claude capability simulations establish which measurements are actually exposed.
+- [ ] Demonstrate learning disabled, paused, destination failure, denied publication, and a graph-change recommendation with no direct effect.
+- [ ] Run the two approved interactive pre-commit simulations (plain-language explanation and adaptive project interview) through installed Codex and Claude Code, recording visible capability degradation.
+- [x] Add namespaced mature-harness adoption, migration/coexistence/provenance contracts, host-mode validation, and sanitized drift/backlink fixtures.
+- [ ] Expand host migration validation beyond content hashes/globs to filesystem-specific symlink/case equivalence after the isolation policy is decided.
+
+## Distribution and release
+
+- [x] Define `core`, `core-learning`, and `full` as generated profiles from one source tree and shared `VERSION`.
+- [x] **Initial public version** — `0.1.0`; approved tag: `v0.1.0` from the validated canonical source.
+- [x] **Contained installation and continuous delivery release** — `0.2.0`; approved tag: `v0.2.0` from the validated canonical source.
+- [ ] **Release automation and GitHub attachments** — owner: maintainers/security; block: automated release. Validate provenance, checksums, and permissions before enabling.
+- [x] Keep one canonical, profile-aware README pair; copied-profile validation confirms all remaining relative links resolve without profile-specific rendering.
+- [x] **Overview audio 0.3.0 refresh** — bilingual tracks were re-rendered with the current scripts, including executable goal-lineage budgets, approved by the user, published as GitHub attachments, and bound by manifest hashes.
+
+## Next implementation gate
+
+Before claims about an external autonomous runtime or automated isolation/delegation, run the native interactive simulations, confirm runtime capability baselines, and finish isolation/path policy. Release automation and external note destinations remain blocked only at their stated publication/integration points.

agent_harness_kit_cli-0.5.3/PKG-INFO

@@ -0,0 +1,73 @@
+Metadata-Version: 2.5
+Name: agent-harness-kit-cli
+Version: 0.5.3
+Summary: Artifact-driven development harness for coding agents
+Project-URL: Homepage, https://github.com/Eduardo-Salvador/Agent-Harness-Kit
+Project-URL: Repository, https://github.com/Eduardo-Salvador/Agent-Harness-Kit
+Project-URL: Issues, https://github.com/Eduardo-Salvador/Agent-Harness-Kit/issues
+Author: Eduardo Salvador
+License: MIT License
+        
+        Copyright (c) 2026 Agent Harness Kit contributors
+        
+        Permission is hereby granted, free of charge, to any person obtaining a copy
+        of this software and associated documentation files (the "Software"), to deal
+        in the Software without restriction, including without limitation the rights
+        to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+        copies of the Software, and to permit persons to whom the Software is
+        furnished to do so, subject to the following conditions:
+        
+        The above copyright notice and this permission notice shall be included in all
+        copies or substantial portions of the Software.
+        
+        THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+        IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+        FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+        AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+        LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+        OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+        SOFTWARE.
+License-File: LICENSE
+Keywords: agents,claude,codex,developer-tools,harness
+Classifier: Development Status :: 4 - Beta
+Classifier: License :: OSI Approved :: MIT License
+Classifier: Programming Language :: Python :: 3
+Classifier: Programming Language :: Python :: 3 :: Only
+Requires-Python: >=3.10
+Description-Content-Type: text/markdown
+
+# Agent Harness Kit
+
+Agent Harness Kit gives coding agents durable project context, separate human and technical pending views, dependency-aware execution, file ownership leases, bounded review, and inspectable completion.
+
+![Agent Harness Kit](https://raw.githubusercontent.com/Eduardo-Salvador/Agent-Harness-Kit/v0.5.3/docs/assets/agent-harness-kit-banner.svg)
+
+## Install
+
+```bash
+uv tool install agent-harness-kit-cli
+```
+
+Open a terminal inside a project and run:
+
+```bash
+agent-harness install
+```
+
+The recommended `core` profile is installed by default. Use `--dry-run` to preview or `--profile core-learning` to include optional, consented project-learning support.
+
+The installer creates a contained `agent-harness-kit/` directory and managed root `AGENTS.md` and `CLAUDE.md` bridge blocks without replacing existing project instructions.
+
+## What it coordinates
+
+- approved project context before broad inspection;
+- `PENDING.md` for human decisions and macro gaps;
+- `TASK-GRAPH.md` for dependencies, leases, progress, and execution;
+- isolated workstreams and context-aware frontend/backend/integration routing;
+- one independent review and at most one focused re-review;
+- hackathon mode for compressed discovery and demo-first MVP delivery;
+- mandatory status with progress, blockers, next action, and inspectable paths.
+
+The Kit is an artifact-driven scaffold followed by capable agents. It is not a daemon that autonomously opens sessions, locks operating-system files, merges branches, or deploys software.
+
+Documentation, source, audio overview, and examples are available in the [GitHub repository](https://github.com/Eduardo-Salvador/Agent-Harness-Kit).