hammerkit 1.6.0-alpha.3 → 1.7.0

package/.specify/templates/spec-template.md

@@ -1,131 +0,0 @@
-# Feature Specification: [FEATURE NAME]
-
-**Feature Branch**: `[###-feature-name]`
-
-**Created**: [DATE]
-
-**Status**: Draft
-
-**Input**: User description: "$ARGUMENTS"
-
-## User Scenarios & Testing *(mandatory)*
-
-<!--
-  IMPORTANT: User stories should be PRIORITIZED as user journeys ordered by importance.
-  Each user story/journey must be INDEPENDENTLY TESTABLE - meaning if you implement just ONE of them,
-  you should still have a viable MVP (Minimum Viable Product) that delivers value.
-
-  Assign priorities (P1, P2, P3, etc.) to each story, where P1 is the most critical.
-  Think of each story as a standalone slice of functionality that can be:
-  - Developed independently
-  - Tested independently
-  - Deployed independently
-  - Demonstrated to users independently
--->
-
-### User Story 1 - [Brief Title] (Priority: P1)
-
-[Describe this user journey in plain language]
-
-**Why this priority**: [Explain the value and why it has this priority level]
-
-**Independent Test**: [Describe how this can be tested independently - e.g., "Can be fully tested by [specific action] and delivers [specific value]"]
-
-**Acceptance Scenarios**:
-
-1. **Given** [initial state], **When** [action], **Then** [expected outcome]
-2. **Given** [initial state], **When** [action], **Then** [expected outcome]
-
----
-
-### User Story 2 - [Brief Title] (Priority: P2)
-
-[Describe this user journey in plain language]
-
-**Why this priority**: [Explain the value and why it has this priority level]
-
-**Independent Test**: [Describe how this can be tested independently]
-
-**Acceptance Scenarios**:
-
-1. **Given** [initial state], **When** [action], **Then** [expected outcome]
-
----
-
-### User Story 3 - [Brief Title] (Priority: P3)
-
-[Describe this user journey in plain language]
-
-**Why this priority**: [Explain the value and why it has this priority level]
-
-**Independent Test**: [Describe how this can be tested independently]
-
-**Acceptance Scenarios**:
-
-1. **Given** [initial state], **When** [action], **Then** [expected outcome]
-
----
-
-[Add more user stories as needed, each with an assigned priority]
-
-### Edge Cases
-
-<!--
-  ACTION REQUIRED: The content in this section represents placeholders.
-  Fill them out with the right edge cases.
--->
-
-- What happens when [boundary condition]?
-- How does system handle [error scenario]?
-
-## Requirements *(mandatory)*
-
-<!--
-  ACTION REQUIRED: The content in this section represents placeholders.
-  Fill them out with the right functional requirements.
--->
-
-### Functional Requirements
-
-- **FR-001**: System MUST [specific capability, e.g., "allow users to create accounts"]
-- **FR-002**: System MUST [specific capability, e.g., "validate email addresses"]
-- **FR-003**: Users MUST be able to [key interaction, e.g., "reset their password"]
-- **FR-004**: System MUST [data requirement, e.g., "persist user preferences"]
-- **FR-005**: System MUST [behavior, e.g., "log all security events"]
-
-*Example of marking unclear requirements:*
-
-- **FR-006**: System MUST authenticate users via [NEEDS CLARIFICATION: auth method not specified - email/password, SSO, OAuth?]
-- **FR-007**: System MUST retain user data for [NEEDS CLARIFICATION: retention period not specified]
-
-### Key Entities *(include if feature involves data)*
-
-- **[Entity 1]**: [What it represents, key attributes without implementation]
-- **[Entity 2]**: [What it represents, relationships to other entities]
-
-## Success Criteria *(mandatory)*
-
-<!--
-  ACTION REQUIRED: Define measurable success criteria.
-  These must be technology-agnostic and measurable.
--->
-
-### Measurable Outcomes
-
-- **SC-001**: [Measurable metric, e.g., "Users can complete account creation in under 2 minutes"]
-- **SC-002**: [Measurable metric, e.g., "System handles 1000 concurrent users without degradation"]
-- **SC-003**: [User satisfaction metric, e.g., "90% of users successfully complete primary task on first attempt"]
-- **SC-004**: [Business metric, e.g., "Reduce support tickets related to [X] by 50%"]
-
-## Assumptions
-
-<!--
-  ACTION REQUIRED: The content in this section represents placeholders.
-  Fill them out with the right assumptions based on reasonable defaults
-  chosen when the feature description did not specify certain details.
--->
-
-- [Assumption about target users, e.g., "Users have stable internet connectivity"]
-- [Assumption about scope boundaries, e.g., "Mobile support is out of scope for v1"]
-- [Assumption about data/environment, e.g., "Existing authentication system will be reused"]
-- [Dependency on existing system/service, e.g., "Requires access to the existing user profile API"]

package/.specify/templates/tasks-template.md

@@ -1,252 +0,0 @@
----
-
-description: "Task list template for feature implementation"
----
-
-# Tasks: [FEATURE NAME]
-
-**Input**: Design documents from `/specs/[###-feature-name]/`
-
-**Prerequisites**: plan.md (required), spec.md (required for user stories), research.md, data-model.md, contracts/
-
-**Tests**: The examples below include test tasks. Tests are OPTIONAL - only include them if explicitly requested in the feature specification.
-
-**Organization**: Tasks are grouped by user story to enable independent implementation and testing of each story.
-
-## Format: `[ID] [P?] [Story] Description`
-
-- **[P]**: Can run in parallel (different files, no dependencies)
-- **[Story]**: Which user story this task belongs to (e.g., US1, US2, US3)
-- Include exact file paths in descriptions
-
-## Path Conventions
-
-- **Single project**: `src/`, `tests/` at repository root
-- **Web app**: `backend/src/`, `frontend/src/`
-- **Mobile**: `api/src/`, `ios/src/` or `android/src/`
-- Paths shown below assume single project - adjust based on plan.md structure
-
-<!--
-  ============================================================================
-  IMPORTANT: The tasks below are SAMPLE TASKS for illustration purposes only.
-
-  The /speckit-tasks command MUST replace these with actual tasks based on:
-  - User stories from spec.md (with their priorities P1, P2, P3...)
-  - Feature requirements from plan.md
-  - Entities from data-model.md
-  - Endpoints from contracts/
-
-  Tasks MUST be organized by user story so each story can be:
-  - Implemented independently
-  - Tested independently
-  - Delivered as an MVP increment
-
-  DO NOT keep these sample tasks in the generated tasks.md file.
-  ============================================================================
--->
-
-## Phase 1: Setup (Shared Infrastructure)
-
-**Purpose**: Project initialization and basic structure
-
-- [ ] T001 Create project structure per implementation plan
-- [ ] T002 Initialize [language] project with [framework] dependencies
-- [ ] T003 [P] Configure linting and formatting tools
-
----
-
-## Phase 2: Foundational (Blocking Prerequisites)
-
-**Purpose**: Core infrastructure that MUST be complete before ANY user story can be implemented
-
-**⚠️ CRITICAL**: No user story work can begin until this phase is complete
-
-Examples of foundational tasks (adjust based on your project):
-
-- [ ] T004 Setup database schema and migrations framework
-- [ ] T005 [P] Implement authentication/authorization framework
-- [ ] T006 [P] Setup API routing and middleware structure
-- [ ] T007 Create base models/entities that all stories depend on
-- [ ] T008 Configure error handling and logging infrastructure
-- [ ] T009 Setup environment configuration management
-
-**Checkpoint**: Foundation ready - user story implementation can now begin in parallel
-
----
-
-## Phase 3: User Story 1 - [Title] (Priority: P1) 🎯 MVP
-
-**Goal**: [Brief description of what this story delivers]
-
-**Independent Test**: [How to verify this story works on its own]
-
-### Tests for User Story 1 (OPTIONAL - only if tests requested) ⚠️
-
-> **NOTE: Write these tests FIRST, ensure they FAIL before implementation**
-
-- [ ] T010 [P] [US1] Contract test for [endpoint] in tests/contract/test_[name].py
-- [ ] T011 [P] [US1] Integration test for [user journey] in tests/integration/test_[name].py
-
-### Implementation for User Story 1
-
-- [ ] T012 [P] [US1] Create [Entity1] model in src/models/[entity1].py
-- [ ] T013 [P] [US1] Create [Entity2] model in src/models/[entity2].py
-- [ ] T014 [US1] Implement [Service] in src/services/[service].py (depends on T012, T013)
-- [ ] T015 [US1] Implement [endpoint/feature] in src/[location]/[file].py
-- [ ] T016 [US1] Add validation and error handling
-- [ ] T017 [US1] Add logging for user story 1 operations
-
-**Checkpoint**: At this point, User Story 1 should be fully functional and testable independently
-
----
-
-## Phase 4: User Story 2 - [Title] (Priority: P2)
-
-**Goal**: [Brief description of what this story delivers]
-
-**Independent Test**: [How to verify this story works on its own]
-
-### Tests for User Story 2 (OPTIONAL - only if tests requested) ⚠️
-
-- [ ] T018 [P] [US2] Contract test for [endpoint] in tests/contract/test_[name].py
-- [ ] T019 [P] [US2] Integration test for [user journey] in tests/integration/test_[name].py
-
-### Implementation for User Story 2
-
-- [ ] T020 [P] [US2] Create [Entity] model in src/models/[entity].py
-- [ ] T021 [US2] Implement [Service] in src/services/[service].py
-- [ ] T022 [US2] Implement [endpoint/feature] in src/[location]/[file].py
-- [ ] T023 [US2] Integrate with User Story 1 components (if needed)
-
-**Checkpoint**: At this point, User Stories 1 AND 2 should both work independently
-
----
-
-## Phase 5: User Story 3 - [Title] (Priority: P3)
-
-**Goal**: [Brief description of what this story delivers]
-
-**Independent Test**: [How to verify this story works on its own]
-
-### Tests for User Story 3 (OPTIONAL - only if tests requested) ⚠️
-
-- [ ] T024 [P] [US3] Contract test for [endpoint] in tests/contract/test_[name].py
-- [ ] T025 [P] [US3] Integration test for [user journey] in tests/integration/test_[name].py
-
-### Implementation for User Story 3
-
-- [ ] T026 [P] [US3] Create [Entity] model in src/models/[entity].py
-- [ ] T027 [US3] Implement [Service] in src/services/[service].py
-- [ ] T028 [US3] Implement [endpoint/feature] in src/[location]/[file].py
-
-**Checkpoint**: All user stories should now be independently functional
-
----
-
-[Add more user story phases as needed, following the same pattern]
-
----
-
-## Phase N: Polish & Cross-Cutting Concerns
-
-**Purpose**: Improvements that affect multiple user stories
-
-- [ ] TXXX [P] Documentation updates in docs/
-- [ ] TXXX Code cleanup and refactoring
-- [ ] TXXX Performance optimization across all stories
-- [ ] TXXX [P] Additional unit tests (if requested) in tests/unit/
-- [ ] TXXX Security hardening
-- [ ] TXXX Run quickstart.md validation
-
----
-
-## Dependencies & Execution Order
-
-### Phase Dependencies
-
-- **Setup (Phase 1)**: No dependencies - can start immediately
-- **Foundational (Phase 2)**: Depends on Setup completion - BLOCKS all user stories
-- **User Stories (Phase 3+)**: All depend on Foundational phase completion
-  - User stories can then proceed in parallel (if staffed)
-  - Or sequentially in priority order (P1 → P2 → P3)
-- **Polish (Final Phase)**: Depends on all desired user stories being complete
-
-### User Story Dependencies
-
-- **User Story 1 (P1)**: Can start after Foundational (Phase 2) - No dependencies on other stories
-- **User Story 2 (P2)**: Can start after Foundational (Phase 2) - May integrate with US1 but should be independently testable
-- **User Story 3 (P3)**: Can start after Foundational (Phase 2) - May integrate with US1/US2 but should be independently testable
-
-### Within Each User Story
-
-- Tests (if included) MUST be written and FAIL before implementation
-- Models before services
-- Services before endpoints
-- Core implementation before integration
-- Story complete before moving to next priority
-
-### Parallel Opportunities
-
-- All Setup tasks marked [P] can run in parallel
-- All Foundational tasks marked [P] can run in parallel (within Phase 2)
-- Once Foundational phase completes, all user stories can start in parallel (if team capacity allows)
-- All tests for a user story marked [P] can run in parallel
-- Models within a story marked [P] can run in parallel
-- Different user stories can be worked on in parallel by different team members
-
----
-
-## Parallel Example: User Story 1
-
-```bash
-# Launch all tests for User Story 1 together (if tests requested):
-Task: "Contract test for [endpoint] in tests/contract/test_[name].py"
-Task: "Integration test for [user journey] in tests/integration/test_[name].py"
-
-# Launch all models for User Story 1 together:
-Task: "Create [Entity1] model in src/models/[entity1].py"
-Task: "Create [Entity2] model in src/models/[entity2].py"
-```
-
----
-
-## Implementation Strategy
-
-### MVP First (User Story 1 Only)
-
-1. Complete Phase 1: Setup
-2. Complete Phase 2: Foundational (CRITICAL - blocks all stories)
-3. Complete Phase 3: User Story 1
-4. **STOP and VALIDATE**: Test User Story 1 independently
-5. Deploy/demo if ready
-
-### Incremental Delivery
-
-1. Complete Setup + Foundational → Foundation ready
-2. Add User Story 1 → Test independently → Deploy/Demo (MVP!)
-3. Add User Story 2 → Test independently → Deploy/Demo
-4. Add User Story 3 → Test independently → Deploy/Demo
-5. Each story adds value without breaking previous stories
-
-### Parallel Team Strategy
-
-With multiple developers:
-
-1. Team completes Setup + Foundational together
-2. Once Foundational is done:
-   - Developer A: User Story 1
-   - Developer B: User Story 2
-   - Developer C: User Story 3
-3. Stories complete and integrate independently
-
----
-
-## Notes
-
-- [P] tasks = different files, no dependencies
-- [Story] label maps task to specific user story for traceability
-- Each user story should be independently completable and testable
-- Verify tests fail before implementing
-- Commit after each task or logical group
-- Stop at any checkpoint to validate story independently
-- Avoid: vague tasks, same file conflicts, cross-story dependencies that break independence

package/.specify/workflows/speckit/workflow.yml

@@ -1,77 +0,0 @@
-schema_version: "1.0"
-workflow:
-  id: "speckit"
-  name: "Full SDD Cycle"
-  version: "1.0.0"
-  author: "GitHub"
-  description: "Runs specify → plan → tasks → implement with review gates"
-
-requires:
-  # 0.8.5 is the first release with engine-side resolution of the
-  # ``integration: "auto"`` default. Older versions would treat "auto"
-  # as a literal integration key and fail at dispatch.
-  speckit_version: ">=0.8.5"
-  integrations:
-    # The four commands below (specify, plan, tasks, implement) are core
-    # spec-kit commands provided by every integration. The list here is an
-    # advisory, non-exhaustive compatibility hint following the documented
-    # ``any: [...]`` schema -- it is NOT a closed set. The workflow runs
-    # against any integration the project was initialized with, including
-    # ones not listed below, as long as that integration provides the four
-    # core commands referenced in ``steps``.
-    any:
-      - "claude"
-      - "copilot"
-      - "gemini"
-      - "opencode"
-
-inputs:
-  spec:
-    type: string
-    required: true
-    prompt: "Describe what you want to build"
-  integration:
-    type: string
-    default: "auto"
-    prompt: "Integration to use (e.g. claude, copilot, gemini; 'auto' uses the project's initialized integration)"
-  scope:
-    type: string
-    default: "full"
-    enum: ["full", "backend-only", "frontend-only"]
-
-steps:
-  - id: specify
-    command: speckit.specify
-    integration: "{{ inputs.integration }}"
-    input:
-      args: "{{ inputs.spec }}"
-
-  - id: review-spec
-    type: gate
-    message: "Review the generated spec before planning."
-    options: [approve, reject]
-    on_reject: abort
-
-  - id: plan
-    command: speckit.plan
-    integration: "{{ inputs.integration }}"
-    input:
-      args: "{{ inputs.spec }}"
-
-  - id: review-plan
-    type: gate
-    message: "Review the plan before generating tasks."
-    options: [approve, reject]
-    on_reject: abort
-
-  - id: tasks
-    command: speckit.tasks
-    integration: "{{ inputs.integration }}"
-    input:
-      args: "{{ inputs.spec }}"
-
-  - id: implement
-    command: speckit.implement
-    integration: "{{ inputs.integration }}"
-    input:
-      args: "{{ inputs.spec }}"

package/.specify/workflows/workflow-registry.json

@@ -1,13 +0,0 @@
-{
-  "schema_version": "1.0",
-  "workflows": {
-    "speckit": {
-      "name": "Full SDD Cycle",
-      "version": "1.0.0",
-      "description": "Runs specify \u2192 plan \u2192 tasks \u2192 implement with review gates",
-      "source": "bundled",
-      "installed_at": "2026-05-30T06:27:46.912039+00:00",
-      "updated_at": "2026-05-30T06:27:46.912046+00:00"
-    }
-  }
-}

package/AGENTS.md

@@ -1,94 +0,0 @@
-# AGENTS.md
-
-Guidance for AI coding agents (Claude Code, Cursor, Copilot, etc.) working in this repository.
-
-## What this is
-
-Hammerkit is a containerized build tool (CLI distributed as `dist/index.js`). It reads a `.hammerkit.yaml` build file, plans a graph of tasks and services, and executes them locally, in Docker, or on Kubernetes. Source/output files are explicitly declared per task, which is what enables hammerkit's incremental caching and "store/restore" workflow for CI.
-
-User-facing docs live at https://no0dles.gitbook.io/hammerkit/ (see [SUMMARY.md](SUMMARY.md) for the structure).
-
-## Working agreement
-
-Read [VALUES.md](./VALUES.md) first. That file covers what hammerkit optimizes for; this file covers agent-specific operating rules.
-
-How to work in this repo (see the `do-the-work` skill for detail):
-
-- **Do the work; don't avoid it.** When the task is to fix something — CI, a test,
-  the build, a check — fixing the root cause *is* the deliverable. Never resolve a
-  failure by skipping, disabling, excluding, `.skip`/`xfail`, weakening an
-  assertion, or stopping early (unless the user explicitly asks).
-- **Ask implementation questions, not permission to avoid work.** Design and
-  ambiguity questions are welcome; "can I skip/disable/leave this?" is not — that's
-  the work, do it. Escalate only when genuinely blocked (access, a product
-  decision, contradictory requirements), and propose the fix path.
-- **Don't make the user repeat himself.** Read [.agents/FEEDBACK.md](.agents/FEEDBACK.md)
-  before working and apply it; when corrected, append the correction there so it's
-  not re-litigated.
-
-## Commands
-
-- `npm run build` — `tsc -b tsconfig.json`, outputs to `dist/`
-- `npm test` — runs jest across `src/**/*.spec.ts`. Tests run with `maxConcurrency: 1` and a 45s timeout; expect a full run to be slow.
-- `npm run lint` / `npm run format` — eslint / prettier+eslint --fix.
-- Single test: `node_modules/.bin/jest src/path/to/file.spec.ts -t "test name"`. CI uses `jest --runInBand`.
-
-### Test environment flags
-
-Many integration tests in [src/testing/integration/](src/testing/integration/) gate themselves on env vars (see [requires-linux-containers.ts](src/testing/requires-linux-containers.ts), [requires-windows-containers.ts](src/testing/requires-windows-containers.ts), [requires-kubernetes.ts](src/testing/requires-kubernetes.ts)). In CI, when the flag is unset the test is replaced with a no-op:
-
-- `LINUX_CONTAINERS=true` — enable docker/linux-container tests (set on Linux + macOS in CI)
-- `WINDOWS_CONTAINERS=true` — enable windows-container tests
-- `CLUSTER_NAME=<ctx>` — enable kubernetes tests (CI uses minikube)
-- `VERBOSE=true` — verbose test output
-
-Locally these gates are bypassed (`isCI` is false), so tests will attempt to talk to Docker/k8s and fail if those aren't available. Use the env flags to opt-in selectively.
-
-## Architecture
-
-The CLI flows roughly: **parse → plan → schedule → execute**. Knowing this pipeline is the fastest way to orient in the codebase.
-
-### Entry points
-
-- [src/index.ts](src/index.ts) — bin entry, builds an `Environment` (cwd, file ctx, console, stdout/stderr, abortCtrl) and calls `runProgram`.
-- [src/run-program.ts](src/run-program.ts) → [src/program.ts](src/program.ts) — commander CLI definition. Subcommands: `ls`, `exec`, `up`, `down`, `clean`, `store`, `restore`, `validate`, `package`. Each subcommand builds a `Cli` via `createCli(fileName, environment, workScope)`.
-- [src/cli.ts](src/cli.ts) — the programmatic façade (`Cli` class) wrapping a `WorkTree` + `Environment`. Library consumers use `getCli()`; the CLI in `program.ts` is just a thin shell around this.
-
-### Parse: `schema/` and `parser/`
-
-- [src/schema/](src/schema/) — zod schemas for the build file (`build-file-*-schema.ts`) plus the parse pipeline: `schema-parser.ts` → `reference-parser.ts` → `work-scope-parser.ts`. `parse-error.ts` carries zod errors back to the CLI for pretty-printing.
-- [src/parser/](src/parser/) — `read-build-file.ts`, `read-env-file.ts`, `default-build-file.ts`, label parsing. JSON schema published at [build.schema.json](build.schema.json) is generated from these zod schemas (see `src/json-schema.ts`).
-
-### Plan: `planner/`
-
-Parsing produces a **WorkTree** ([src/planner/work-tree.ts](src/planner/work-tree.ts)) of `WorkItem`s — `WorkTask` and `WorkService` indexed by id. `work-cache-id.ts` computes the per-task cache hash from sources + command + needs + image; this is what makes incremental builds work. Validation lives in `validate.ts` and `work-item-validation.ts`.
-
-### Runtime selection
-
-Each task/service is bound to a runtime: `local`, `docker`, or `kubernetes` (see `work-runtime-*.ts` in `planner/`, plus [src/runtime/runtime.ts](src/runtime/runtime.ts)). The runtime decides where execution happens.
-
-### Schedule + execute: `executer/`
-
-- [src/executer/execute-work-tree.ts](src/executer/execute-work-tree.ts) is the top-level loop. It builds a `ProcessManager` (worker pool), walks the work tree, and dispatches items.
-- `scheduler/` holds the state machines (`task-state.ts`, `service-state.ts`, `dependency-state.ts`, `need-state.ts`) and cycle detection (`check-for-loop.ts`).
-- `execute-work-task.ts` / `execute-work-service.ts` are the per-item drivers. They call into `local-task.ts`, `docker-task.ts`, or `docker-service.ts` / `kubernetes-service.ts` depending on runtime.
-- `event-cache.ts` implements `clean`/`store`/`restore` — the cache directory hammerkit uses to ship build outputs between machines.
-- State propagation is observable via the `State<T>` wrapper ([state.ts](src/executer/state.ts)) and `state-listener.ts`. `watch-loop.ts` powers `--watch` mode.
-
-### Docker + Kubernetes layers
-
-- [src/docker/](src/docker/) — `dockerode`-based helpers: `using-container.ts` (lifecycle), `pull.ts`, `stream.ts`, `package.ts` (image build/push for `hammerkit package`).
-- [src/kubernetes/](src/kubernetes/) — `@kubernetes/client-node` helpers for deployments, services, ingress, PVCs, and store/restore of persistent data. Used for `kubernetes-service` items.
-
-### Testing infrastructure
-
-- [src/testing/example-test-suite.ts](src/testing/example-test-suite.ts) — most integration tests copy a fixture from [examples/](examples/) into `temp/<example>/`, build a synthetic `Environment` with in-memory streams, and exercise the CLI through `createCli(...)`. There is one example directory per spec file in `src/testing/integration/`.
-- [src/executer/environment-mock.ts](src/executer/environment-mock.ts) is used for unit tests that don't need a real fs.
-- `test-streams.ts` provides `emptyStream` / `memoryStream` for capturing console/status output in assertions.
-
-## Conventions
-
-- Prettier: no semicolons, single quotes, 120 cols, 2-space tabs, trailing commas `es5`.
-- ESLint: `no-console: error` — never write to `console.*` in `src/` (the `Environment` carries `stdout`/`stderr`/`console`/`status` writables; route output through those).
-- TS strict mode is on; `@typescript-eslint/no-explicit-any` is **off**, so `any` is permitted where useful.
-- Library consumers import from `src/index.ts` → `dist/index.js`; keep that surface stable.

package/Dockerfile

@@ -1,25 +0,0 @@
-FROM node:20-alpine as build
-
-ARG TARGETPLATFORM
-
-WORKDIR /app
-
-# install dependencies
-COPY package.json .
-COPY package-lock.json .
-RUN npm ci
-
-# build source code
-COPY tsconfig.json .
-COPY src src
-RUN node_modules/.bin/tsc -b
-RUN export ARCH=$(echo $TARGETPLATFORM | cut -c7-11)
-RUN node_modules/.bin/pkg . --targets "node18-alpine-$ARCH" --compress Brotli
-
-######################################
-FROM docker:24.0.7-cli-alpine3.19
-
-WORKDIR /app
-COPY --from=build /app/hammerkit /usr/local/bin/hammerkit
-
-ENTRYPOINT ["hammerkit"]

package/FOLLOWUPS.md

@@ -1,34 +0,0 @@
-# Runtime follow-ups
-
-Tracking what's done on `feature/runtime-followups` and what remains. The integration-test work is tracked separately in [INTEGRATION-TESTS.md](INTEGRATION-TESTS.md).
-
-## Done on this branch
-
-- [x] **Cross-cycle validation** — new `hasMixedCycle` walks deps and needs together; wired into both [validate.ts](src/planner/validate.ts) and [check-for-loop.ts](src/executer/scheduler/check-for-loop.ts). Tests in [validate.spec.ts](src/planner/validate.spec.ts).
-- [x] **Local task pidfile** — [work-runtime-local.ts](src/planner/work-runtime-local.ts) writes `.hammerkit/<id>.pid` for the duration of `execute()`. A live PID (`find-process`) blocks re-entry with an `error` state; a stale PID is silently swept. Tests in [work-runtime-local.spec.ts](src/planner/work-runtime-local.spec.ts).
-- [x] **Docker service crash detection** — [docker-service.ts](src/executer/docker-service.ts) now races `container.wait()` against `abort`. A container that exits before abort is reported as `{ type: 'end', reason: 'crash' }` instead of `terminated`.
-- [x] **Service env hints for local tasks** — [get-service-env-hints.ts](src/executer/get-service-env-hints.ts) emits `HAMMERKIT_<NAME>_HOST` / `_PORT` / `_PORT_<containerPort>` for each running need. Merged into the local task's command env in [local-task.ts](src/executer/local-task.ts). Tests in [get-service-env-hints.spec.ts](src/executer/get-service-env-hints.spec.ts).
-- [x] **K8s deployment healthcheck** — `service.data.healthcheck.cmd` is translated to an `exec` `readinessProbe`/`livenessProbe` in [ensure-kubernetes-deployment-exists.ts](src/kubernetes/ensure-kubernetes-deployment-exists.ts). No more silently-ignored healthchecks on k8s.
-- [x] **Kubernetes port-forward without `kubectl`** — [kubernetes-service.ts](src/executer/kubernetes-service.ts) now uses `@kubernetes/client-node`'s `PortForward` class with a local `net.createServer` listener per port. Selector → pod resolution lives in [resolve-pod-name.ts](src/kubernetes/resolve-pod-name.ts) and supports `service`, `deployment`, and `pod` selectors. A new optional `namespace` field on the `kubernetes-service` schema (defaults to `'default'`) makes per-job namespace isolation possible from a build file.
-
-## Done in 1.6.0 hardening (branch `hardening/1.6.0`)
-
-- [x] **Transitive dependency cache invalidation** — `checkCacheState` now folds each task's own state key together with the recursively-computed state keys of its dependencies ([src/executer/scheduler/enqueue-next.ts](src/executer/scheduler/enqueue-next.ts) `combineStateKeys`/`resolveEffectiveStateKey`). A change to an upstream source now invalidates downstream tasks even when their own sources are unchanged. Because `currentStateKey` reads back the stored key, the round-trip stays consistent (one expected cache miss on first run after upgrade). Tests in [enqueue-next.spec.ts](src/executer/scheduler/enqueue-next.spec.ts).
-- [x] **K8s stale upload/download pod cleanup** — `getPodForPersistence` force-deletes and waits for any leftover pod of the same name before scheduling a fresh one ([src/kubernetes/ensure-persistent-data.ts](src/kubernetes/ensure-persistent-data.ts) `removeStalePod`), so a pod leaked by a crashed run no longer gets patched in place and stuck. `statusCodeOf` is now shared from [apply.ts](src/kubernetes/apply.ts).
-
-## Open
-
-**Release triage (1.6.0):** none of the items below block the 1.6.0 release — they
-are tracked as post-1.6.0 cleanup. They are error-message, code-placement, and
-operational-efficiency improvements (no longer any known correctness gap that
-yields wrong build outputs).
-
-### Smaller TODOs (lower priority)
-
-- [src/planner/utils/append-work-dependencies.ts:39](src/planner/utils/append-work-dependencies.ts) — `// TODO check if thats correct` (skipping `isFile` generates when inheriting).
-- **K8s persistence dedupe + real matcher/stateKey** — [src/kubernetes/ensure-persistent-data.ts](src/kubernetes/ensure-persistent-data.ts) and [src/kubernetes/volumes.ts:89](src/kubernetes/volumes.ts) `:91`. Skipping re-upload when the persisted state already matches needs an in-cluster state marker per volume, and the `matcher: () => true` / `stateKey: ''` placeholders must be replaced with the work item's real source matcher/key. Deferred deliberately: it is a new in-cluster-state feature (not a localized fix) and the k8s persistence path is only exercisable on the self-hosted integration runner, so it was kept out of the release-hardening pass to keep 1.6.0 verifiable. Until then uploads include the full source path (over-upload, still correct).
-- [src/schema/reference-parser.ts:276](src/schema/reference-parser.ts) `:305` — generic "unable to find" errors should include resolution path.
-- [src/executer/event-cache.ts:15](src/executer/event-cache.ts) `:28` — clean/store logic ought to live in the local runtime, not the cache module.
-- [src/executer/state.ts:41](src/executer/state.ts) — emit a warn when removing a listener that isn't registered.
-- [src/planner/work-item-status.ts:33](src/planner/work-item-status.ts) `:50` `:58` — `LogContext` should replace with `WorkItem` reference; two `cleanup` markers.
-- [src/kubernetes/await-running-state.ts:66](src/kubernetes/await-running-state.ts) — `awaitDeployRunningState` has a confusing `(... && obj.status?.readyReplicas) ?? 0 > 0` operator-precedence expression. It happens to behave correctly (resolves only when `readyReplicas` is truthy) but reads as a bug; rewrite as `((obj.status?.readyReplicas ?? 0) > 0)`. Cosmetic — left untouched in 1.6.0 to avoid changing the k8s path that is only exercised on the integration runner.