hammerkit 1.6.0 → 1.7.0

package/.specify/extensions.yml

@@ -1,149 +0,0 @@
-installed:
-- git
-settings:
-  auto_execute_hooks: true
-hooks:
-  before_constitution:
-  - extension: git
-    command: speckit.git.initialize
-    enabled: true
-    optional: false
-    prompt: Execute speckit.git.initialize?
-    description: Initialize Git repository before constitution setup
-    condition: null
-  before_specify:
-  - extension: git
-    command: speckit.git.feature
-    enabled: true
-    optional: false
-    prompt: Execute speckit.git.feature?
-    description: Create feature branch before specification
-    condition: null
-  before_clarify:
-  - extension: git
-    command: speckit.git.commit
-    enabled: true
-    optional: true
-    prompt: Commit outstanding changes before clarification?
-    description: Auto-commit before spec clarification
-    condition: null
-  before_plan:
-  - extension: git
-    command: speckit.git.commit
-    enabled: true
-    optional: true
-    prompt: Commit outstanding changes before planning?
-    description: Auto-commit before implementation planning
-    condition: null
-  before_tasks:
-  - extension: git
-    command: speckit.git.commit
-    enabled: true
-    optional: true
-    prompt: Commit outstanding changes before task generation?
-    description: Auto-commit before task generation
-    condition: null
-  before_implement:
-  - extension: git
-    command: speckit.git.commit
-    enabled: true
-    optional: true
-    prompt: Commit outstanding changes before implementation?
-    description: Auto-commit before implementation
-    condition: null
-  before_checklist:
-  - extension: git
-    command: speckit.git.commit
-    enabled: true
-    optional: true
-    prompt: Commit outstanding changes before checklist?
-    description: Auto-commit before checklist generation
-    condition: null
-  before_analyze:
-  - extension: git
-    command: speckit.git.commit
-    enabled: true
-    optional: true
-    prompt: Commit outstanding changes before analysis?
-    description: Auto-commit before analysis
-    condition: null
-  before_taskstoissues:
-  - extension: git
-    command: speckit.git.commit
-    enabled: true
-    optional: true
-    prompt: Commit outstanding changes before issue sync?
-    description: Auto-commit before tasks-to-issues conversion
-    condition: null
-  after_constitution:
-  - extension: git
-    command: speckit.git.commit
-    enabled: true
-    optional: true
-    prompt: Commit constitution changes?
-    description: Auto-commit after constitution update
-    condition: null
-  after_specify:
-  - extension: git
-    command: speckit.git.commit
-    enabled: true
-    optional: true
-    prompt: Commit specification changes?
-    description: Auto-commit after specification
-    condition: null
-  after_clarify:
-  - extension: git
-    command: speckit.git.commit
-    enabled: true
-    optional: true
-    prompt: Commit clarification changes?
-    description: Auto-commit after spec clarification
-    condition: null
-  after_plan:
-  - extension: git
-    command: speckit.git.commit
-    enabled: true
-    optional: true
-    prompt: Commit plan changes?
-    description: Auto-commit after implementation planning
-    condition: null
-  after_tasks:
-  - extension: git
-    command: speckit.git.commit
-    enabled: true
-    optional: true
-    prompt: Commit task changes?
-    description: Auto-commit after task generation
-    condition: null
-  after_implement:
-  - extension: git
-    command: speckit.git.commit
-    enabled: true
-    optional: true
-    prompt: Commit implementation changes?
-    description: Auto-commit after implementation
-    condition: null
-  after_checklist:
-  - extension: git
-    command: speckit.git.commit
-    enabled: true
-    optional: true
-    prompt: Commit checklist changes?
-    description: Auto-commit after checklist generation
-    condition: null
-  after_analyze:
-  - extension: git
-    command: speckit.git.commit
-    enabled: true
-    optional: true
-    prompt: Commit analysis results?
-    description: Auto-commit after analysis
-    condition: null
-  after_taskstoissues:
-  - extension: git
-    command: speckit.git.commit
-    enabled: true
-    optional: true
-    prompt: Commit after syncing issues?
-    description: Auto-commit after tasks-to-issues conversion
-    condition: null

package/.specify/feature.json

@@ -1,3 +0,0 @@
-{
-  "feature_directory": "specs"
-}

package/.specify/init-options.json

@@ -1,10 +0,0 @@
-{
-  "ai": "claude",
-  "ai_skills": true,
-  "branch_numbering": "sequential",
-  "context_file": "CLAUDE.md",
-  "here": false,
-  "integration": "claude",
-  "script": "sh",
-  "speckit_version": "0.8.18"
-}

package/.specify/integration.json

@@ -1,15 +0,0 @@
-{
-  "version": "0.8.18",
-  "integration_state_schema": 1,
-  "installed_integrations": [
-    "claude"
-  ],
-  "integration_settings": {
-    "claude": {
-      "script": "sh",
-      "invoke_separator": "-"
-    }
-  },
-  "integration": "claude",
-  "default_integration": "claude"
-}

package/.specify/integrations/claude.manifest.json

@@ -1,16 +0,0 @@
-{
-  "integration": "claude",
-  "version": "0.8.18",
-  "installed_at": "2026-05-30T06:27:46.809754+00:00",
-  "files": {
-    ".claude/skills/speckit-analyze/SKILL.md": "2eef0fbff6cad15c9d4714d8986192387811c971a82a1135ab0404f3db0c5e90",
-    ".claude/skills/speckit-checklist/SKILL.md": "26419fc118dcd9c4e1e977460696a04b7757b8fb0a2d1ff9c64732669deb7977",
-    ".claude/skills/speckit-clarify/SKILL.md": "35795a017d6d2ed3ace35a333b22e450788e539e24ed5c756d815aa34cd5b6f5",
-    ".claude/skills/speckit-constitution/SKILL.md": "c1a044aba243ca6aff627fb5e4404feb6f1108d4f7dd174631bee3ae477d6c15",
-    ".claude/skills/speckit-implement/SKILL.md": "042a0415ce60a5b66adf039da431d9a98cb4897ff330635e0bab0becbbaf3cd2",
-    ".claude/skills/speckit-plan/SKILL.md": "bad923f08ffd0e61e37da038626bff374386541fb4c69858a5473d6dc302ee17",
-    ".claude/skills/speckit-specify/SKILL.md": "4cb1cb21f598288859e84cbf29052c1c41f213a2ca42b79b3a6d6293dde99d02",
-    ".claude/skills/speckit-tasks/SKILL.md": "ca048fadbe29d761c05b497605789656d112a3a9db5f774efcf84503e77a684e",
-    ".claude/skills/speckit-taskstoissues/SKILL.md": "99bf5ffd90dcb57b63007c7f659a5160a18ce6feb82889895808e2d277abe83b"
-  }
-}

package/.specify/integrations/speckit.manifest.json

@@ -1,17 +0,0 @@
-{
-  "integration": "speckit",
-  "version": "0.8.18",
-  "installed_at": "2026-05-30T06:27:46.820090+00:00",
-  "files": {
-    ".specify/scripts/bash/common.sh": "0ac0b422fecf41a172a21dc163be1558a87e8a8b885cb48eb9307c99427c4102",
-    ".specify/scripts/bash/setup-plan.sh": "b23cca3d769a217ab812a6059adb549622471f6893af234cf98ca2019ac4e1a1",
-    ".specify/scripts/bash/setup-tasks.sh": "7aeee15192a5ab3ba9ff3c3ae450d9994043bf0493c1eabc840da72a9742fc87",
-    ".specify/scripts/bash/check-prerequisites.sh": "f4541a00257f035aa55a9fede6d964e51e6851c3dc2f81d0a6f367db18944765",
-    ".specify/scripts/bash/create-new-feature.sh": "bcf4964ca0c6c78717bb42d9e66b8c7e5ee82779cd96afc5aa7b08b75abe5790",
-    ".specify/templates/constitution-template.md": "ce7549540fa45543cca797a150201d868e64495fdff39dc38246fb17bd4024b3",
-    ".specify/templates/checklist-template.md": "c37695297e5d3153d64f82c21223509940b13932046c7961c42d1d669516130c",
-    ".specify/templates/tasks-template.md": "fc29a233f6f5a27ca31f1aa46b596af6500c627441c6e62b2bc4a1d721525842",
-    ".specify/templates/spec-template.md": "3945437fc35cd30a5b2bf7beea680337c3516826d3efa5a6b92c4a7eca1ba28e",
-    ".specify/templates/plan-template.md": "cc7f7979cf8d8836ec26492785affd80791d3422a2b745062ec695be8c985ef7"
-  }
-}

package/.specify/memory/constitution.md

@@ -1,162 +0,0 @@
-<!--
-SYNC IMPACT REPORT
-Version change: (uninitialized template) → 1.0.0
-Rationale: Initial ratification. Constitution materialized from the canonical
-VALUES.md; no prior versioned principles existed.
-
-Modified principles: none (all newly defined)
-Added principles:
-  - I. Local-First
-  - II. Platform-Agnostic
-  - III. One Config, Many Tools
-  - IV. Caching Reduces Waste
-  - V. Stable Contracts (NON-NEGOTIABLE)
-  - VI. Simplicity & Composability
-  - VII. Pragmatic Typing
-  - VIII. Tests Carry Their Weight (NON-NEGOTIABLE)
-Added sections:
-  - Decision Heuristics
-  - Development Workflow & Quality Gates
-  - Governance
-Removed sections: none
-
-Templates reviewed for alignment:
-  - .specify/templates/plan-template.md ............ ✅ Constitution Check gate is
-      generic ("Gates determined based on constitution file"); Complexity Tracking
-      already supports Principle VI / "Add nothing speculative". No edit required.
-  - .specify/templates/spec-template.md ............ ✅ No principle conflict. No edit.
-  - .specify/templates/tasks-template.md ........... ✅ Tests-optional wording does
-      not contradict Principle VIII (which governs the product, not generated
-      task lists). No edit required.
-  - .specify/templates/checklist-template.md ....... ✅ No principle conflict. No edit.
-
-Follow-up TODOs: none. RATIFICATION_DATE set to 2026-05-30 (initial adoption).
--->
-
-# Hammerkit Constitution
-
-## Core Principles
-
-### I. Local-First
-
-Every hammerkit build MUST run on a developer's laptop, not only in CI. A feature that
-functions exclusively inside a CI environment is incomplete. Local execution is the
-primary target; CI is one consumer among many.
-
-**Rationale**: A build tool that only runs on CI is broken.
-
-### II. Platform-Agnostic
-
-Hammerkit MUST NOT couple its core to any single CI/CD provider (GitHub Actions, GitLab
-CI, or otherwise). The same build MUST run anywhere a container runs. Provider-specific
-behavior is prohibited in core and, where genuinely needed, MUST sit behind a clear
-boundary.
-
-**Rationale**: Portability across environments is a core promise, not a configuration
-option.
-
-### III. One Config, Many Tools
-
-A single hammerkit build file MUST be able to replace many tool-specific configs. Changes
-SHOULD reduce config sprawl, not add to it; any new configuration surface MUST justify its
-existence against this goal.
-
-**Rationale**: Reducing config sprawl is a feature, not a side effect.
-
-### IV. Caching Reduces Waste
-
-Caching MUST be evaluated for compute and cost savings, not only wall-clock speed.
-Distributed and smart caching is a first-class concern. Cache-key correctness is
-non-negotiable: a false cache hit (serving stale output as fresh) is a defect, never an
-acceptable trade for speed.
-
-**Rationale**: Smart caching saves compute — that matters for cost and footprint, not only
-build time.
-
-### V. Stable Contracts (NON-NEGOTIABLE)
-
-The CLI surface and the build-file schema are public contracts. Backward-incompatible
-changes to either MUST be deliberate and versioned — never an incidental side effect of a
-refactor. A breaking change requires a MAJOR version bump and migration notes.
-
-**Rationale**: Users depend on these contracts; silent breakage erodes trust in the tool.
-
-### VI. Simplicity & Composability
-
-Prefer small, composable pieces over clever abstractions. If two features can be one, make
-them one. Abstractions, features, and config knobs MUST NOT land without a concrete present
-need (YAGNI).
-
-**Rationale**: Composable simplicity keeps the system maintainable and keeps the surface
-area honest.
-
-### VII. Pragmatic Typing
-
-TypeScript strict mode MUST stay enabled. `any` is permitted where it pulls its weight;
-type purity is a means, not the goal. Type-level cleverness MUST NOT be bought at the cost
-of readability or delivery velocity.
-
-**Rationale**: Types exist to serve correctness and developer experience, not the reverse.
-
-### VIII. Tests Carry Their Weight (NON-NEGOTIABLE)
-
-Quality and coverage are non-negotiable. New behavior ships with tests that would fail
-without it. Slow integration tests are accepted because they buy real confidence. Tests
-MUST NOT be skipped, muted, excluded, `xfail`-ed, or weakened to make a check pass; close
-gaps, do not exclude them.
-
-**Rationale**: Real confidence beats a green checkmark earned by lowering the bar.
-
-## Decision Heuristics
-
-When a judgment call is not settled by a principle above, apply these heuristics (verbatim
-from `VALUES.md`):
-
-- **Fix root causes, not symptoms** — A red check is fixed by repairing what's broken, not
-  by removing, muting, or weakening the check (no skipped tests, no relaxed lint/prettier
-  config to dodge an error).
-- **Real integrations over mocks** — Where feasible, exercise real Docker / real registries
-  / real Kubernetes. Mocks are a last resort, not a default.
-- **Add nothing speculative** — Features, abstractions, and config knobs land when a
-  concrete need exists, not for hypothetical futures.
-
-## Development Workflow & Quality Gates
-
-Every change MUST pass the same gates CI enforces before it merges. Locally these are:
-
-- **Formatting** — `prettier --check 'src/**'` (strict: no semicolons, single quotes, 120
-  columns, 2-space indent, `es5` trailing commas). `npm run format` to fix.
-- **Linting** — `eslint . --ext .ts`. `no-console` is an error; output MUST route through
-  the `Environment` (`stdout`/`stderr`/`console`/`status`), never `console.*` in `src/`.
-- **Typecheck / build** — `tsc -b tsconfig.json` (this also typechecks spec files).
-- **Unit suite** — `CI=true npm test`. The `CI=true` flag matches CI; container/k8s suites
-  gate themselves on their env flags and no-op when unset.
-- **Integration suite** — `jest --config jest.integration.config.ts` exercises real
-  Docker / registries / Kubernetes per Principle VIII and the Decision Heuristics.
-
-Coverage MUST NOT regress. Code review MUST verify compliance with these principles, and
-any added complexity MUST be justified (see the plan template's Complexity Tracking).
-
-## Governance
-
-This constitution supersedes ad-hoc practice. When guidance conflicts, the constitution
-wins; deviations require explicit justification in the pull request.
-
-**Amendments** MUST be proposed via pull request, recorded in the Sync Impact Report at the
-top of this file, and version-bumped per the policy below. Material principle changes SHOULD
-note migration impact for dependent templates and docs.
-
-**Versioning policy** (for this constitution):
-
-- **MAJOR** — Backward-incompatible governance or principle removal/redefinition.
-- **MINOR** — A new principle or section, or materially expanded guidance.
-- **PATCH** — Clarifications, wording, and non-semantic refinements.
-
-**Compliance**: PRs and reviews MUST verify alignment with these principles. Unjustified
-violations block merge.
-
-**Runtime guidance**: `VALUES.md` is the canonical statement of intent and the source of
-these principles. Day-to-day agent operating rules live in `AGENTS.md`; durable corrections
-live in `.agents/FEEDBACK.md`. Read those for operational detail; this document governs.
-
-**Version**: 1.0.0 | **Ratified**: 2026-05-30 | **Last Amended**: 2026-05-30

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

@@ -1,40 +0,0 @@
-# [CHECKLIST TYPE] Checklist: [FEATURE NAME]
-
-**Purpose**: [Brief description of what this checklist covers]
-**Created**: [DATE]
-**Feature**: [Link to spec.md or relevant documentation]
-
-**Note**: This checklist is generated by the `/speckit-checklist` command based on feature context and requirements.
-
-<!-- 
-  ============================================================================
-  IMPORTANT: The checklist items below are SAMPLE ITEMS for illustration only.
-  
-  The /speckit-checklist command MUST replace these with actual items based on:
-  - User's specific checklist request
-  - Feature requirements from spec.md
-  - Technical context from plan.md
-  - Implementation details from tasks.md
-  
-  DO NOT keep these sample items in the generated checklist file.
-  ============================================================================
--->
-
-## [Category 1]
-
-- [ ] CHK001 First checklist item with clear action
-- [ ] CHK002 Second checklist item
-- [ ] CHK003 Third checklist item
-
-## [Category 2]
-
-- [ ] CHK004 Another category item
-- [ ] CHK005 Item with specific criteria
-- [ ] CHK006 Final item in this category
-
-## Notes
-
-- Check items off as completed: `[x]`
-- Add comments or findings inline
-- Link to relevant resources or documentation
-- Items are numbered sequentially for easy reference

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

@@ -1,50 +0,0 @@
-# [PROJECT_NAME] Constitution
-<!-- Example: Spec Constitution, TaskFlow Constitution, etc. -->
-
-## Core Principles
-
-### [PRINCIPLE_1_NAME]
-<!-- Example: I. Library-First -->
-[PRINCIPLE_1_DESCRIPTION]
-<!-- Example: Every feature starts as a standalone library; Libraries must be self-contained, independently testable, documented; Clear purpose required - no organizational-only libraries -->
-
-### [PRINCIPLE_2_NAME]
-<!-- Example: II. CLI Interface -->
-[PRINCIPLE_2_DESCRIPTION]
-<!-- Example: Every library exposes functionality via CLI; Text in/out protocol: stdin/args → stdout, errors → stderr; Support JSON + human-readable formats -->
-
-### [PRINCIPLE_3_NAME]
-<!-- Example: III. Test-First (NON-NEGOTIABLE) -->
-[PRINCIPLE_3_DESCRIPTION]
-<!-- Example: TDD mandatory: Tests written → User approved → Tests fail → Then implement; Red-Green-Refactor cycle strictly enforced -->
-
-### [PRINCIPLE_4_NAME]
-<!-- Example: IV. Integration Testing -->
-[PRINCIPLE_4_DESCRIPTION]
-<!-- Example: Focus areas requiring integration tests: New library contract tests, Contract changes, Inter-service communication, Shared schemas -->
-
-### [PRINCIPLE_5_NAME]
-<!-- Example: V. Observability, VI. Versioning & Breaking Changes, VII. Simplicity -->
-[PRINCIPLE_5_DESCRIPTION]
-<!-- Example: Text I/O ensures debuggability; Structured logging required; Or: MAJOR.MINOR.BUILD format; Or: Start simple, YAGNI principles -->
-
-## [SECTION_2_NAME]
-<!-- Example: Additional Constraints, Security Requirements, Performance Standards, etc. -->
-
-[SECTION_2_CONTENT]
-<!-- Example: Technology stack requirements, compliance standards, deployment policies, etc. -->
-
-## [SECTION_3_NAME]
-<!-- Example: Development Workflow, Review Process, Quality Gates, etc. -->
-
-[SECTION_3_CONTENT]
-<!-- Example: Code review requirements, testing gates, deployment approval process, etc. -->
-
-## Governance
-<!-- Example: Constitution supersedes all other practices; Amendments require documentation, approval, migration plan -->
-
-[GOVERNANCE_RULES]
-<!-- Example: All PRs/reviews must verify compliance; Complexity must be justified; Use [GUIDANCE_FILE] for runtime development guidance -->
-
-**Version**: [CONSTITUTION_VERSION] | **Ratified**: [RATIFICATION_DATE] | **Last Amended**: [LAST_AMENDED_DATE]
-<!-- Example: Version: 2.1.1 | Ratified: 2025-06-13 | Last Amended: 2025-07-16 -->

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

@@ -1,113 +0,0 @@
-# Implementation Plan: [FEATURE]
-
-**Branch**: `[###-feature-name]` | **Date**: [DATE] | **Spec**: [link]
-
-**Input**: Feature specification from `/specs/[###-feature-name]/spec.md`
-
-**Note**: This template is filled in by the `/speckit-plan` command. See `.specify/templates/plan-template.md` for the execution workflow.
-
-## Summary
-
-[Extract from feature spec: primary requirement + technical approach from research]
-
-## Technical Context
-
-<!--
-  ACTION REQUIRED: Replace the content in this section with the technical details
-  for the project. The structure here is presented in advisory capacity to guide
-  the iteration process.
--->
-
-**Language/Version**: [e.g., Python 3.11, Swift 5.9, Rust 1.75 or NEEDS CLARIFICATION]
-
-**Primary Dependencies**: [e.g., FastAPI, UIKit, LLVM or NEEDS CLARIFICATION]
-
-**Storage**: [if applicable, e.g., PostgreSQL, CoreData, files or N/A]
-
-**Testing**: [e.g., pytest, XCTest, cargo test or NEEDS CLARIFICATION]
-
-**Target Platform**: [e.g., Linux server, iOS 15+, WASM or NEEDS CLARIFICATION]
-
-**Project Type**: [e.g., library/cli/web-service/mobile-app/compiler/desktop-app or NEEDS CLARIFICATION]
-
-**Performance Goals**: [domain-specific, e.g., 1000 req/s, 10k lines/sec, 60 fps or NEEDS CLARIFICATION]
-
-**Constraints**: [domain-specific, e.g., <200ms p95, <100MB memory, offline-capable or NEEDS CLARIFICATION]
-
-**Scale/Scope**: [domain-specific, e.g., 10k users, 1M LOC, 50 screens or NEEDS CLARIFICATION]
-
-## Constitution Check
-
-*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*
-
-[Gates determined based on constitution file]
-
-## Project Structure
-
-### Documentation (this feature)
-
-```text
-specs/[###-feature]/
-├── plan.md              # This file (/speckit-plan command output)
-├── research.md          # Phase 0 output (/speckit-plan command)
-├── data-model.md        # Phase 1 output (/speckit-plan command)
-├── quickstart.md        # Phase 1 output (/speckit-plan command)
-├── contracts/           # Phase 1 output (/speckit-plan command)
-└── tasks.md             # Phase 2 output (/speckit-tasks command - NOT created by /speckit-plan)
-```
-
-### Source Code (repository root)
-<!--
-  ACTION REQUIRED: Replace the placeholder tree below with the concrete layout
-  for this feature. Delete unused options and expand the chosen structure with
-  real paths (e.g., apps/admin, packages/something). The delivered plan must
-  not include Option labels.
--->
-
-```text
-# [REMOVE IF UNUSED] Option 1: Single project (DEFAULT)
-src/
-├── models/
-├── services/
-├── cli/
-└── lib/
-
-tests/
-├── contract/
-├── integration/
-└── unit/
-
-# [REMOVE IF UNUSED] Option 2: Web application (when "frontend" + "backend" detected)
-backend/
-├── src/
-│   ├── models/
-│   ├── services/
-│   └── api/
-└── tests/
-
-frontend/
-├── src/
-│   ├── components/
-│   ├── pages/
-│   └── services/
-└── tests/
-
-# [REMOVE IF UNUSED] Option 3: Mobile + API (when "iOS/Android" detected)
-api/
-└── [same as backend above]
-
-ios/ or android/
-└── [platform-specific structure: feature modules, UI flows, platform tests]
-```
-
-**Structure Decision**: [Document the selected structure and reference the real
-directories captured above]
-
-## Complexity Tracking
-
-> **Fill ONLY if Constitution Check has violations that must be justified**
-
-| Violation | Why Needed | Simpler Alternative Rejected Because |
-|-----------|------------|-------------------------------------|
-| [e.g., 4th project] | [current need] | [why 3 projects insufficient] |
-| [e.g., Repository pattern] | [specific problem] | [why direct DB access insufficient] |