@harness-forge/cli 0.1.0

package/examples/knowledge-bases/README.md

@@ -0,0 +1,12 @@
+# Seeded Knowledge Examples
+
+The seeded language packs ship their scenario examples in place under
+`knowledge-bases/seeded/<language>/examples/`.
+
+## Example families
+
+- TypeScript: API, React library, Next.js app, monorepo contracts
+- Java: Spring Boot, event consumer, multi-module backend, domain library
+- .NET: ASP.NET Core, worker, shared domain, CLI automation
+- Lua: Neovim, OpenResty, LÖVE, embedded automation
+- PowerShell: script module, CI automation, remoting, bootstrap tooling

package/examples/production-readiness-demo/README.md

@@ -0,0 +1,16 @@
+# Production Readiness Demo
+
+This example is a tiny repo used to sanity-check Harness Forge production
+flows.
+
+## Suggested flow
+
+```bash
+hforge init --root . --json
+hforge bootstrap --root . --yes
+hforge review --root . --json
+hforge export --root . --json
+```
+
+Use it when you want a clean workspace to verify init, install, review, and
+export behavior without touching a larger application repo.

package/hooks/README.md

@@ -0,0 +1,3 @@
+# Shared hook surfaces
+
+Harness Forge ships target-neutral hook helpers under `hooks/shared/`.

package/hooks/shared/PostChangeSummary.ps1

@@ -0,0 +1 @@
+Write-Output "[hforge] post-change summary"

package/hooks/shared/PreChangeQualityGate.ps1

@@ -0,0 +1 @@
+Write-Output "[hforge] pre-change quality gate"

package/hooks/shared/post-change-summary.sh

@@ -0,0 +1,3 @@
+#!/usr/bin/env bash
+set -euo pipefail
+echo "[hforge] post-change summary"

package/hooks/shared/pre-change-quality-gate.sh

@@ -0,0 +1,3 @@
+#!/usr/bin/env bash
+set -euo pipefail
+echo "[hforge] pre-change quality gate"

package/install.ps1

@@ -0,0 +1,28 @@
+Set-StrictMode -Version Latest
+$ErrorActionPreference = "Stop"
+
+$scriptPath = $MyInvocation.MyCommand.Path
+while ((Get-Item $scriptPath).LinkType) {
+  $resolved = (Get-Item $scriptPath).Target
+  if (-not [System.IO.Path]::IsPathRooted($resolved)) {
+    $resolved = Join-Path (Split-Path -Parent $scriptPath) $resolved
+  }
+  $scriptPath = $resolved
+}
+
+$scriptDir = Split-Path -Parent $scriptPath
+$nodeExe = if ($env:NODE_BIN) { $env:NODE_BIN } else { "node" }
+$cliPath = Join-Path $scriptDir "dist/cli/index.js"
+
+if (-not (Get-Command $nodeExe -ErrorAction SilentlyContinue)) {
+  Write-Error "Harness Forge requires Node.js 22+ to run."
+  exit 1
+}
+
+if (-not (Test-Path $cliPath)) {
+  Write-Error "Harness Forge CLI is not built yet. Run npm run build or install the published package."
+  exit 1
+}
+
+& $nodeExe $cliPath @args
+exit $LASTEXITCODE

package/install.sh

@@ -0,0 +1,24 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+SCRIPT_PATH="$0"
+while [ -L "$SCRIPT_PATH" ]; do
+    link_dir="$(cd "$(dirname "$SCRIPT_PATH")" && pwd)"
+    SCRIPT_PATH="$(readlink "$SCRIPT_PATH")"
+    [[ "$SCRIPT_PATH" != /* ]] && SCRIPT_PATH="$link_dir/$SCRIPT_PATH"
+done
+SCRIPT_DIR="$(cd "$(dirname "$SCRIPT_PATH")" && pwd)"
+NODE_BIN="${NODE_BIN:-node}"
+CLI_PATH="$SCRIPT_DIR/dist/cli/index.js"
+
+if ! command -v "$NODE_BIN" >/dev/null 2>&1; then
+  echo "Harness Forge requires Node.js 22+ to run." >&2
+  exit 1
+fi
+
+if [ ! -f "$CLI_PATH" ]; then
+  echo "Harness Forge CLI is not built yet. Run npm run build or install the published package." >&2
+  exit 1
+fi
+
+exec "$NODE_BIN" "$CLI_PATH" "$@"

package/knowledge-bases/operations/observability-and-evals/README.md

@@ -0,0 +1,7 @@
+# Observability And Evals
+
+This operations knowledge base collects patterns for local-first event design,
+summary generation, benchmark expectations, and drift inspection.
+
+It exists so operators can reason about usefulness without relying on external
+services.

package/knowledge-bases/seeded/README.md

@@ -0,0 +1,33 @@
+# Seeded Knowledge Bases
+
+Harness Forge ships the attached starter language knowledge archives as first-class product content.
+
+## Included packs
+
+- `typescript/`
+- `java/`
+- `dotnet/`
+- `lua/`
+- `powershell/`
+
+## What each pack contains
+
+- `README.md` and `knowledge-base.json` metadata
+- `docs/` for overview, review checklist, examples guide, and framework notes
+- `examples/` with scenario-driven starter references
+- `rules/common/` with shared baseline guidance
+- `rules/<language>/` with language-specific style, patterns, testing, security, and hook guidance
+- `legacy-seed/` where the original archive carried forward earlier seed content
+
+## How Harness Forge uses them
+
+- The package publishes the packs directly under `knowledge-bases/seeded/`
+- language bundle manifests reference these paths so installs can copy them into supported targets
+- catalog docs summarize the packs and link back to the canonical seeded files
+- release validation checks every non-directory file from the source archive is still shipped or explicitly mapped
+
+## Maintainer notes
+
+- Treat files in this directory as canonical imported seed content unless a manifest explicitly marks a transformed destination
+- prefer authoring new summaries and cross-pack docs outside this folder
+- update `manifests/catalog/seeded-knowledge-files.json` whenever seeded coverage changes

package/knowledge-bases/seeded/dotnet/README.md

@@ -0,0 +1,18 @@
+# .NET Knowledge Base
+
+    .NET knowledge base for backend services, APIs, workers, libraries, CLI tools, and testable application architecture.
+Use this pack to extend fresh-project language rules, examples, hook suggestions, and agent guidance.
+
+    ## What is included
+
+    - `rules/common/` baseline rules copied from the current package
+    - `rules/dotnet/` starter language pack for the fresh project
+    - `docs/` notes for tooling, frameworks, examples, and review checklists
+    - `examples/` scenario seeds for expanding future project examples
+
+    ## Recommended use
+
+    1. Use the `rules/` files as the starter pack for the fresh project.
+    2. Pull examples into the public docs and scenario examples.
+    3. Extend the review checklist as agent or command quality gates.
+    4. Split framework-heavy content into separate docs if the pack grows too large.

package/knowledge-bases/seeded/dotnet/docs/examples-guide.md

@@ -0,0 +1,15 @@
+# Example Expansion Guide
+
+Use the starter examples in `examples/` as seeds for:
+
+- scenario docs in `examples/`
+- language-specific rule examples
+- adapter-specific setup examples
+- smoke-test projects for installer validation
+
+## Keep examples useful
+
+- Prefer one clear scenario per example.
+- Include project shape, tooling, test strategy, and hook suggestions.
+- Show where the language pack modifies common defaults.
+- Keep generated or copied example files clearly marked.

package/knowledge-bases/seeded/dotnet/docs/frameworks.md

@@ -0,0 +1,11 @@
+# Framework Notes
+
+This starter pack keeps the core language rules runtime-agnostic.
+
+## Focus areas
+
+ASP.NET Core, Minimal APIs, Worker Services, EF Core, test projects, solution layout.
+
+## Recommendation
+
+Keep core language rules small and stable. Move framework-heavy examples and operational guidance into separate docs or optional packs when the project grows.

package/knowledge-bases/seeded/dotnet/docs/overview.md

@@ -0,0 +1,33 @@
+# .NET Overview
+
+    ## Best fit
+
+    .NET knowledge base for backend services, APIs, workers, libraries, CLI tools, and testable application architecture.
+Use this pack to extend fresh-project language rules, examples, hook suggestions, and agent guidance.
+
+    ## Recommended tooling
+
+    - dotnet SDK
+- dotnet format
+- dotnet test
+- xUnit
+- FluentAssertions
+- Testcontainers
+- ASP.NET Core
+- EF Core
+
+## Framework and ecosystem areas
+
+    - ASP.NET Core
+- Minimal APIs
+- Worker Services
+- MediatR-style application layering
+- EF Core
+
+## Common pitfalls
+
+    - sync over async
+- missing CancellationToken flow
+- overuse of static state
+- leaking secrets through appsettings
+- weak input validation

package/knowledge-bases/seeded/dotnet/docs/review-checklist.md

@@ -0,0 +1,27 @@
+# .NET Review Checklist
+
+Use this when reviewing rules, examples, generated output, or agent guidance for .NET.
+
+## Design
+
+- Are boundaries explicit?
+- Is mutable shared state minimized?
+- Are framework and runtime concerns separated from domain logic?
+
+## Testing
+
+- Are tests behavior-focused?
+- Are failure paths covered?
+- Are integration boundaries tested where silent breakage is likely?
+
+## Security
+
+- Are secrets kept out of source and logs?
+- Is untrusted input validated at the edge?
+- Are risky runtime features called out and constrained?
+
+## Documentation quality
+
+- Do examples compile or run conceptually without missing context?
+- Are framework-specific assumptions clearly labeled?
+- Does the content distinguish rules from examples from optional advice?

package/knowledge-bases/seeded/dotnet/examples/01-aspnet-core-crud-api.md

@@ -0,0 +1,13 @@
+# ASP.NET Core CRUD API
+
+## Scenario
+
+Starter scenario for expanding installer examples, language-pack docs, and review/test guidance.
+
+## Include in the real project
+
+- recommended pack/profile combination
+- expected commands/hooks
+- testing strategy
+- security concerns
+- adapter-specific notes if behavior differs by target

package/knowledge-bases/seeded/dotnet/examples/02-background-worker-with-queue-processing.md

@@ -0,0 +1,13 @@
+# Background worker with queue processing
+
+## Scenario
+
+Starter scenario for expanding installer examples, language-pack docs, and review/test guidance.
+
+## Include in the real project
+
+- recommended pack/profile combination
+- expected commands/hooks
+- testing strategy
+- security concerns
+- adapter-specific notes if behavior differs by target

package/knowledge-bases/seeded/dotnet/examples/03-shared-domain-library.md

@@ -0,0 +1,13 @@
+# Shared domain library
+
+## Scenario
+
+Starter scenario for expanding installer examples, language-pack docs, and review/test guidance.
+
+## Include in the real project
+
+- recommended pack/profile combination
+- expected commands/hooks
+- testing strategy
+- security concerns
+- adapter-specific notes if behavior differs by target

package/knowledge-bases/seeded/dotnet/examples/04-cli-automation-tool.md

@@ -0,0 +1,13 @@
+# CLI automation tool
+
+## Scenario
+
+Starter scenario for expanding installer examples, language-pack docs, and review/test guidance.
+
+## Include in the real project
+
+- recommended pack/profile combination
+- expected commands/hooks
+- testing strategy
+- security concerns
+- adapter-specific notes if behavior differs by target

package/knowledge-bases/seeded/dotnet/knowledge-base.json

@@ -0,0 +1,8 @@
+{
+  "id": "dotnet-knowledge-base",
+  "language": "dotnet",
+  "title": ".NET",
+  "intended_use": "starter knowledge base for language rules, examples, hooks, and review guidance",
+  "includes_common_rules": true,
+  "seeded_from_existing_package": true
+}

package/knowledge-bases/seeded/dotnet/legacy-seed/csharp/coding-style.md

@@ -0,0 +1,72 @@
+---
+paths:
+  - "**/*.cs"
+  - "**/*.csx"
+---
+# C# Coding Style
+
+> This file extends [common/coding-style.md](../common/coding-style.md) with C#-specific content.
+
+## Standards
+
+- Follow current .NET conventions and enable nullable reference types
+- Prefer explicit access modifiers on public and internal APIs
+- Keep files aligned with the primary type they define
+
+## Types and Models
+
+- Prefer `record` or `record struct` for immutable value-like models
+- Use `class` for entities or types with identity and lifecycle
+- Use `interface` for service boundaries and abstractions
+- Avoid `dynamic` in application code; prefer generics or explicit models
+
+```csharp
+public sealed record UserDto(Guid Id, string Email);
+
+public interface IUserRepository
+{
+    Task<UserDto?> FindByIdAsync(Guid id, CancellationToken cancellationToken);
+}
+```
+
+## Immutability
+
+- Prefer `init` setters, constructor parameters, and immutable collections for shared state
+- Do not mutate input models in-place when producing updated state
+
+```csharp
+public sealed record UserProfile(string Name, string Email);
+
+public static UserProfile Rename(UserProfile profile, string name) =>
+    profile with { Name = name };
+```
+
+## Async and Error Handling
+
+- Prefer `async`/`await` over blocking calls like `.Result` or `.Wait()`
+- Pass `CancellationToken` through public async APIs
+- Throw specific exceptions and log with structured properties
+
+```csharp
+public async Task<Order> LoadOrderAsync(
+    Guid orderId,
+    CancellationToken cancellationToken)
+{
+    try
+    {
+        return await repository.FindAsync(orderId, cancellationToken)
+            ?? throw new InvalidOperationException($"Order {orderId} was not found.");
+    }
+    catch (Exception ex)
+    {
+        logger.LogError(ex, "Failed to load order {OrderId}", orderId);
+        throw;
+    }
+}
+```
+
+## Formatting
+
+- Use `dotnet format` for formatting and analyzer fixes
+- Keep `using` directives organized and remove unused imports
+- Prefer expression-bodied members only when they stay readable

package/knowledge-bases/seeded/dotnet/legacy-seed/csharp/hooks.md

@@ -0,0 +1,25 @@
+---
+paths:
+  - "**/*.cs"
+  - "**/*.csx"
+  - "**/*.csproj"
+  - "**/*.sln"
+  - "**/Directory.Build.props"
+  - "**/Directory.Build.targets"
+---
+# C# Hooks
+
+> This file extends [common/hooks.md](../common/hooks.md) with C#-specific content.
+
+## PostToolUse Hooks
+
+Configure in `~/.claude/settings.json`:
+
+- **dotnet format**: Auto-format edited C# files and apply analyzer fixes
+- **dotnet build**: Verify the solution or project still compiles after edits
+- **dotnet test --no-build**: Re-run the nearest relevant test project after behavior changes
+
+## Stop Hooks
+
+- Run a final `dotnet build` before ending a session with broad C# changes
+- Warn on modified `appsettings*.json` files so secrets do not get committed

package/knowledge-bases/seeded/dotnet/legacy-seed/csharp/patterns.md

@@ -0,0 +1,50 @@
+---
+paths:
+  - "**/*.cs"
+  - "**/*.csx"
+---
+# C# Patterns
+
+> This file extends [common/patterns.md](../common/patterns.md) with C#-specific content.
+
+## API Response Pattern
+
+```csharp
+public sealed record ApiResponse<T>(
+    bool Success,
+    T? Data = default,
+    string? Error = null,
+    object? Meta = null);
+```
+
+## Repository Pattern
+
+```csharp
+public interface IRepository<T>
+{
+    Task<IReadOnlyList<T>> FindAllAsync(CancellationToken cancellationToken);
+    Task<T?> FindByIdAsync(Guid id, CancellationToken cancellationToken);
+    Task<T> CreateAsync(T entity, CancellationToken cancellationToken);
+    Task<T> UpdateAsync(T entity, CancellationToken cancellationToken);
+    Task DeleteAsync(Guid id, CancellationToken cancellationToken);
+}
+```
+
+## Options Pattern
+
+Use strongly typed options for config instead of reading raw strings throughout the codebase.
+
+```csharp
+public sealed class PaymentsOptions
+{
+    public const string SectionName = "Payments";
+    public required string BaseUrl { get; init; }
+    public required string ApiKeySecretName { get; init; }
+}
+```
+
+## Dependency Injection
+
+- Depend on interfaces at service boundaries
+- Keep constructors focused; if a service needs too many dependencies, split responsibilities
+- Register lifetimes intentionally: singleton for stateless/shared services, scoped for request data, transient for lightweight pure workers

package/knowledge-bases/seeded/dotnet/legacy-seed/csharp/security.md

@@ -0,0 +1,58 @@
+---
+paths:
+  - "**/*.cs"
+  - "**/*.csx"
+  - "**/*.csproj"
+  - "**/appsettings*.json"
+---
+# C# Security
+
+> This file extends [common/security.md](../common/security.md) with C#-specific content.
+
+## Secret Management
+
+- Never hardcode API keys, tokens, or connection strings in source code
+- Use environment variables, user secrets for local development, and a secret manager in production
+- Keep `appsettings.*.json` free of real credentials
+
+```csharp
+// BAD
+const string ApiKey = "sk-live-123";
+
+// GOOD
+var apiKey = builder.Configuration["OpenAI:ApiKey"]
+    ?? throw new InvalidOperationException("OpenAI:ApiKey is not configured.");
+```
+
+## SQL Injection Prevention
+
+- Always use parameterized queries with ADO.NET, Dapper, or EF Core
+- Never concatenate user input into SQL strings
+- Validate sort fields and filter operators before using dynamic query composition
+
+```csharp
+const string sql = "SELECT * FROM Orders WHERE CustomerId = @customerId";
+await connection.QueryAsync<Order>(sql, new { customerId });
+```
+
+## Input Validation
+
+- Validate DTOs at the application boundary
+- Use data annotations, FluentValidation, or explicit guard clauses
+- Reject invalid model state before running business logic
+
+## Authentication and Authorization
+
+- Prefer framework auth handlers instead of custom token parsing
+- Enforce authorization policies at endpoint or handler boundaries
+- Never log raw tokens, passwords, or PII
+
+## Error Handling
+
+- Return safe client-facing messages
+- Log detailed exceptions with structured context server-side
+- Do not expose stack traces, SQL text, or filesystem paths in API responses
+
+## References
+
+See skill: `security-review` for broader application security review checklists.

package/knowledge-bases/seeded/dotnet/legacy-seed/csharp/testing.md

@@ -0,0 +1,46 @@
+---
+paths:
+  - "**/*.cs"
+  - "**/*.csx"
+  - "**/*.csproj"
+---
+# C# Testing
+
+> This file extends [common/testing.md](../common/testing.md) with C#-specific content.
+
+## Test Framework
+
+- Prefer **xUnit** for unit and integration tests
+- Use **FluentAssertions** for readable assertions
+- Use **Moq** or **NSubstitute** for mocking dependencies
+- Use **Testcontainers** when integration tests need real infrastructure
+
+## Test Organization
+
+- Mirror `src/` structure under `tests/`
+- Separate unit, integration, and end-to-end coverage clearly
+- Name tests by behavior, not implementation details
+
+```csharp
+public sealed class OrderServiceTests
+{
+    [Fact]
+    public async Task FindByIdAsync_ReturnsOrder_WhenOrderExists()
+    {
+        // Arrange
+        // Act
+        // Assert
+    }
+}
+```
+
+## ASP.NET Core Integration Tests
+
+- Use `WebApplicationFactory<TEntryPoint>` for API integration coverage
+- Test auth, validation, and serialization through HTTP, not by bypassing middleware
+
+## Coverage
+
+- Target 80%+ line coverage
+- Focus coverage on domain logic, validation, auth, and failure paths
+- Run `dotnet test` in CI with coverage collection enabled where available

package/knowledge-bases/seeded/dotnet/rules/common/agents.md

@@ -0,0 +1,50 @@
+# Agent Orchestration
+
+## Available Agents
+
+Located in `~/.claude/agents/`:
+
+| Agent | Purpose | When to Use |
+|-------|---------|-------------|
+| planner | Implementation planning | Complex features, refactoring |
+| architect | System design | Architectural decisions |
+| tdd-guide | Test-driven development | New features, bug fixes |
+| code-reviewer | Code review | After writing code |
+| security-reviewer | Security analysis | Before commits |
+| build-error-resolver | Fix build errors | When build fails |
+| e2e-runner | E2E testing | Critical user flows |
+| refactor-cleaner | Dead code cleanup | Code maintenance |
+| doc-updater | Documentation | Updating docs |
+| rust-reviewer | Rust code review | Rust projects |
+
+## Immediate Agent Usage
+
+No user prompt needed:
+1. Complex feature requests - Use **planner** agent
+2. Code just written/modified - Use **code-reviewer** agent
+3. Bug fix or new feature - Use **tdd-guide** agent
+4. Architectural decision - Use **architect** agent
+
+## Parallel Task Execution
+
+ALWAYS use parallel Task execution for independent operations:
+
+```markdown
+# GOOD: Parallel execution
+Launch 3 agents in parallel:
+1. Agent 1: Security analysis of auth module
+2. Agent 2: Performance review of cache system
+3. Agent 3: Type checking of utilities
+
+# BAD: Sequential when unnecessary
+First agent 1, then agent 2, then agent 3
+```
+
+## Multi-Perspective Analysis
+
+For complex problems, use split role sub-agents:
+- Factual reviewer
+- Senior engineer
+- Security expert
+- Consistency reviewer
+- Redundancy checker