forgehive 0.7.3 → 0.7.5

package/dist/cli.js

@@ -5915,10 +5915,10 @@ function groupByType(commits) {
   }
   return groups;
 }
-function formatChangelog(commits, version) {
+function formatChangelog(commits, version2) {
   const date = (/* @__PURE__ */ new Date()).toISOString().slice(0, 10);
   const lines = [];
-  lines.push(`## [${version}] \u2014 ${date}`);
+  lines.push(`## [${version2}] \u2014 ${date}`);
   lines.push("");
   if (commits.length === 0) {
     lines.push("No changes.");
@@ -6644,16 +6644,19 @@ function listExistingDocs(projectRoot2) {
 }
 
 // src/cli.ts
+import { createRequire } from "node:module";
+var require2 = createRequire(import.meta.url);
+var { version } = require2("../package.json");
 var [, , command, subcommand, ...rest] = process.argv;
 var projectRoot = process.cwd();
 var forgehiveDir = path32.join(projectRoot, ".forgehive");
 if (command === "--version" || command === "-v") {
-  console.log("0.7.3");
+  console.log(version);
   process.exit(0);
 }
 if (command === "--help" || command === "-h" || command === "help") {
   console.log(`
-forgehive v0.7.3 \u2014 Context-aware AI development environment
+forgehive v${version} \u2014 Context-aware AI development environment
 
 USAGE
   fh <command> [subcommand] [options]
@@ -7440,16 +7443,16 @@ Setze diese Umgebungsvariablen:`);
   const since = sinceArg ?? getLatestTag(projectRoot) ?? void 0;
   const rawLog = getGitLogSince(projectRoot, since);
   const commits = parseGitLog(rawLog);
-  let version = "unreleased";
+  let version2 = "unreleased";
   try {
     const pkgPath = path32.join(projectRoot, "package.json");
     if (fs31.existsSync(pkgPath)) {
       const pkg = JSON.parse(fs31.readFileSync(pkgPath, "utf8").replace(/^\s*\/\/.*$/gm, ""));
-      version = pkg.version ?? "unreleased";
+      version2 = pkg.version ?? "unreleased";
     }
   } catch {
   }
-  const md = formatChangelog(commits, version);
+  const md = formatChangelog(commits, version2);
   const outputPath = outputArg ?? path32.join(projectRoot, "CHANGELOG.md");
   let existing = "";
   if (fs31.existsSync(outputPath)) existing = fs31.readFileSync(outputPath, "utf8");
@@ -7662,8 +7665,8 @@ Setze diese Umgebungsvariablen:`);
       pkg = JSON.parse(fs31.readFileSync(path32.join(projectRoot, "package.json"), "utf8"));
     } catch {
     }
-    const version = pkg.version ?? "unreleased";
-    const md = formatChangelog(commits, version);
+    const version2 = pkg.version ?? "unreleased";
+    const md = formatChangelog(commits, version2);
     const outputPath = outputArg ?? path32.join(projectRoot, "CHANGELOG.md");
     let existing = "";
     if (fs31.existsSync(outputPath)) existing = fs31.readFileSync(outputPath, "utf8");

package/forgehive/commands/design-party.md

@@ -0,0 +1,69 @@
+You are running a Design Party using ForgeHive.
+
+## Design Party
+
+**Agents:** Suki (Experience Designer), Viktor (Systems Architect)
+
+**Mission:** UX design and technical architecture in parallel — align on what to build and how to build it before any code is written.
+
+## Protocol
+
+### Step 1: Launch the party
+
+Run:
+```bash
+fh party run --set design
+```
+
+This spins up isolated worktrees for Suki and Viktor. Both work from the same brief in parallel.
+
+### Step 2: Write the brief
+
+Before the party starts, write a one-paragraph brief:
+- What problem are we solving?
+- Who is the user?
+- What outcome do we want?
+
+This brief is the shared input for both agents.
+
+### Step 3: Parallel design work
+
+**Suki** (Experience Designer) — in her worktree:
+- Maps user journeys: what does the user want to accomplish?
+- Designs interaction flows: what steps does the user take?
+- Identifies friction points and moments of delight
+- Produces: a user journey map and a list of UX requirements
+- Empathy-first: designs with users, not for them
+
+**Viktor** (Systems Architect) — in his worktree:
+- Designs the system architecture for the feature
+- Defines module boundaries, data models, and API contracts
+- Identifies infrastructure requirements and integration points
+- Flags technical constraints that will affect the UX
+- Produces: an architecture diagram (text-based) and a list of technical constraints
+
+### Step 4: Check status
+
+After both agents complete:
+```bash
+fh party status
+```
+
+### Step 5: Alignment review
+
+Present both outputs side by side:
+
+1. **UX requirements** (Suki) — what the system must feel like
+2. **Technical constraints** (Viktor) — what the system can and cannot do
+3. **Conflicts** — where UX desires clash with technical reality
+4. **Resolution** — agree on trade-offs before any implementation begins
+
+Ask the user: **"Sind Suki und Viktor aligned? Soll ich mit der Implementierung beginnen?"**
+
+Do NOT proceed to implementation until alignment is confirmed.
+
+### Step 6: Cleanup
+
+```bash
+fh party cleanup
+```

package/forgehive/commands/full-party.md

@@ -0,0 +1,88 @@
+You are running a Full Party using ForgeHive.
+
+## Full Party
+
+**Agents:** Nora (Senior Research Analyst), Eli (Documentation Architect), Remy (Product Strategist), Suki (Experience Designer), Viktor (Systems Architect), Kai (Principal Engineer), Sam (Quality Architect)
+
+**Mission:** Comprehensive multi-discipline review of a major feature or release — all seven specialists working in parallel on their domain.
+
+> **Warning:** This party spins up 7 worktrees simultaneously. Reserve this for major milestones, release candidates, and significant architectural changes. For smaller reviews, use `/review-party` or `/design-party` instead.
+
+## Protocol
+
+### Step 1: Launch the party
+
+Run:
+```bash
+fh party run --set full
+```
+
+This spins up isolated worktrees for all 7 agents. Each works their specialization in parallel.
+
+### Step 2: Define the milestone
+
+Before the party starts, describe what is being reviewed — be specific:
+- Which release or feature?
+- What are the success criteria?
+- Are there known risk areas to highlight?
+
+### Step 3: Parallel work by specialization
+
+**Nora** (Senior Research Analyst) — structured evidence, surfaces hidden constraints:
+- Reviews assumptions and surfaces what we don't know
+- Checks for hidden constraints in requirements or architecture
+- Produces: a risk and assumptions report
+
+**Eli** (Documentation Architect) — turns systems into navigable knowledge:
+- Audits all documentation for accuracy and completeness
+- Flags missing docs for new features and changed APIs
+- Produces: a documentation gap report
+
+**Remy** (Product Strategist) — jobs-to-be-done, user value over technical elegance:
+- Reviews the feature against user jobs-to-be-done
+- Checks if technical decisions serve user value
+- Produces: a product alignment report
+
+**Suki** (Experience Designer) — empathy-first design:
+- Reviews UX and interaction flows
+- Flags friction points and accessibility concerns
+- Produces: a UX review with specific improvement suggestions
+
+**Viktor** (Systems Architect) — proven technology, developer experience as architecture:
+- Reviews architecture for scalability, maintainability, and DX
+- Flags over-engineering and missing abstractions
+- Produces: an architecture review
+
+**Kai** (Principal Engineer) — test-first, ship-ready, zero ambiguity:
+- Reviews code quality, correctness, and implementation discipline
+- Flags ambiguity, untested code, and production risks
+- Produces: a code review with blocking / non-blocking findings
+
+**Sam** (Quality Architect) — risk-based testing, full-stack automation:
+- Reviews test coverage and testing strategy
+- Identifies high-risk paths with insufficient coverage
+- Produces: a test coverage and risk report
+
+### Step 4: Check status
+
+After all agents complete:
+```bash
+fh party status
+```
+
+### Step 5: Synthesize into a unified report
+
+Collect all 7 reports and synthesize:
+
+1. **Blockers** — anything that must be resolved before release
+2. **Risks** — issues to monitor post-release
+3. **Improvements** — non-blocking suggestions by priority
+4. **Overall verdict**: ready to release / needs work
+
+Present the unified report and ask: **"Soll ich die Blocker direkt angehen?"**
+
+### Step 6: Cleanup
+
+```bash
+fh party cleanup
+```

package/forgehive/commands/party.md

@@ -0,0 +1,64 @@
+You are running a Build Party using ForgeHive.
+
+## Build Party
+
+**Agents:** Viktor (Systems Architect), Kai (Principal Engineer), Sam (Quality Architect)
+
+**Mission:** Architecture, implementation, and QA in parallel — design the system, write the code, and test it simultaneously.
+
+## Protocol
+
+### Step 1: Launch the party
+
+Run:
+```bash
+fh party run --set build
+```
+
+This spins up isolated git worktrees for Viktor, Kai, and Sam. Each agent works in their own worktree in parallel.
+
+### Step 2: Define the scope
+
+Before the party starts, state clearly what is being built — one paragraph is enough. Each agent will interpret this through their own lens.
+
+### Step 3: Parallel work
+
+**Viktor** (Systems Architect) — in his worktree:
+- Proposes the architecture: module boundaries, data flow, API shape
+- Documents key decisions and trade-offs
+- Flags any infrastructure or dependency requirements
+
+**Kai** (Principal Engineer) — in his worktree:
+- Implements the feature following Viktor's architecture proposal
+- Writes ship-ready code — no placeholders, no TODOs
+- Follows test-first discipline: failing test → implementation → passing test
+
+**Sam** (Quality Architect) — in his worktree:
+- Writes the test suite for the feature in parallel with Kai's implementation
+- Covers happy paths, edge cases, and error states
+- Identifies risk areas that need additional coverage
+
+### Step 4: Check status
+
+After each agent signals completion:
+```bash
+fh party status
+```
+
+Review what each agent produced before merging.
+
+### Step 5: Review and integrate
+
+1. Read Viktor's architecture notes
+2. Review Kai's implementation against Viktor's proposal — flag divergence
+3. Run Sam's tests against Kai's implementation — all must pass
+4. Resolve any conflicts between the three worktrees
+5. Merge the agreed result into main
+
+### Step 6: Cleanup
+
+```bash
+fh party cleanup
+```
+
+This tears down all worktrees and cleans up the party state.

package/forgehive/commands/review-party.md

@@ -0,0 +1,72 @@
+You are running a Review Party using ForgeHive.
+
+## Review Party
+
+**Agents:** Kai (Principal Engineer), Sam (Quality Architect), Eli (Documentation Architect)
+
+**Mission:** Code review, test coverage check, and docs audit in parallel — three disciplines reviewing the same changeset simultaneously.
+
+## Protocol
+
+### Step 1: Launch the party
+
+Run:
+```bash
+fh party run --set review
+```
+
+This spins up isolated git worktrees for Kai, Sam, and Eli. Each agent reviews the current diff in parallel.
+
+### Step 2: Set the scope
+
+Before the party starts, specify what is being reviewed — a branch name, a PR, or a commit range:
+
+```bash
+git diff main...HEAD --stat   # show what changed
+```
+
+Share this with the party so all three agents review the same surface area.
+
+### Step 3: Parallel review
+
+**Kai** (Principal Engineer) — in his worktree:
+- Reviews code quality and correctness
+- Flags bugs, logic errors, and anti-patterns
+- Checks for ambiguous naming, hidden coupling, and missing error handling
+- Labels findings: `[BUG]`, `[DESIGN]`, `[NIT]`, `[Q]`, `[+]`
+
+**Sam** (Quality Architect) — in his worktree:
+- Checks test coverage for the changed code
+- Identifies missing edge cases, error states, and boundary conditions
+- Flags paths that are high-risk but untested
+- Proposes specific tests for any gaps found
+
+**Eli** (Documentation Architect) — in his worktree:
+- Checks if README and docs reflect the changes
+- Flags missing or outdated inline documentation
+- Reviews any CHANGELOG entries for accuracy
+- Checks that public API changes are documented
+
+### Step 4: Check status
+
+After each agent completes their review:
+```bash
+fh party status
+```
+
+### Step 5: Synthesize findings
+
+Collect the three reports and merge them into a unified review:
+
+1. **Blocking issues** — anything from Kai or Sam that must be fixed before merge
+2. **Test gaps** — Sam's missing coverage items
+3. **Docs debt** — Eli's documentation updates needed
+4. **Overall verdict**: approve / request changes
+
+Present the synthesized report to the user and ask: **"Soll ich die Blocking Issues direkt fixen?"**
+
+### Step 6: Cleanup
+
+```bash
+fh party cleanup
+```

package/forgehive/commands/security-party.md

@@ -0,0 +1,78 @@
+You are running a Security Party using ForgeHive.
+
+## Security Party
+
+**Agents:** Vera (Security Analyst), Sam (Quality Architect)
+
+**Mission:** Security review and QA in parallel — audit for vulnerabilities while checking test coverage for security-critical paths.
+
+## Protocol
+
+### Step 1: Launch the party
+
+Run:
+```bash
+fh party run --set security
+```
+
+This spins up isolated worktrees for Vera and Sam. Both work in parallel on the current codebase or changeset.
+
+### Step 2: Set the scope
+
+Specify what is being reviewed:
+- A specific branch or PR: `git diff main...HEAD --stat`
+- A full security audit of the codebase
+- A pre-release security check
+
+### Step 3: Parallel security work
+
+**Vera** (Security Analyst) — in her worktree:
+
+Run the automated scan first:
+```bash
+fh security scan
+```
+
+Then perform a manual audit covering:
+- **OWASP Top 10** — injection, broken auth, XSS, IDOR, security misconfiguration, etc.
+- **Auth/Auth review** — authentication flows, authorization checks, session handling
+- **Secrets and credentials** — hardcoded tokens, API keys, or credentials in code
+- **Dependency vulnerabilities** — outdated packages with known CVEs
+- **Compliance flags** — GDPR, SOC2, or HIPAA relevant data handling
+
+Produces: a security findings report with severity ratings (CRITICAL, HIGH, MEDIUM, LOW)
+
+**Sam** (Quality Architect) — in his worktree:
+- Identifies security-critical code paths (auth, payments, data access, input handling)
+- Checks test coverage for each identified path
+- Flags paths that are high-risk but have no security-focused tests
+- Proposes specific security tests: auth bypass attempts, injection tests, boundary inputs
+
+Produces: a security test coverage report with specific test recommendations
+
+### Step 4: Check status
+
+After both agents complete:
+```bash
+fh party status
+```
+
+### Step 5: Merge into a security + quality report
+
+Combine both outputs:
+
+1. **CRITICAL findings** (Vera) — must fix before any deployment
+2. **HIGH findings** (Vera) — fix before production release
+3. **Untested security paths** (Sam) — add tests before release
+4. **MEDIUM/LOW findings** — schedule for next sprint
+5. **Overall verdict**: safe to deploy / needs remediation
+
+Ask: **"Soll ich die CRITICAL und HIGH Findings direkt fixen?"**
+
+Do NOT deploy if CRITICAL or HIGH findings are unresolved.
+
+### Step 6: Cleanup
+
+```bash
+fh party cleanup
+```

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "forgehive",
-  "version": "0.7.3",
+  "version": "0.7.5",
   "description": "Context-aware AI development environment — one binary, your stack.",
   "type": "module",
   "bin": {