loki-mode 10.11.2 → 11.0.1

package/docs/v11/C2-hosted-runner.md

@@ -0,0 +1,30 @@
+# C2: Hosted or remote runner
+
+## Problem
+Loki Mode runs only on the user's local machine. Enterprises need:
+- Isolated, ephemeral build environments (security, no credential leakage)
+- Horizontal scaling: queue runs for execution on a farm of workers
+- Audit trail of which machine ran which task
+
+## Current state
+- `autonomy/run.sh` executes locally only
+- No runner registration or dispatch mechanism
+- No queue table in database
+- mcp/server.py has no worker heartbeat or job assignment API
+
+## Proposed v1 scope
+- Worker registration API: `POST /workers/register` with hostname, CPU, disk, status
+- Job queue table with status (pending, claimed, running, done, failed)
+- Job assignment: simple round-robin to available workers
+- CLI flag `--runner-pool=prod` to dispatch instead of run locally
+- Worker heartbeat every 30s with status update
+- Audit field in job: which runner IP, user, invocation time
+
+## Open questions
+- Deploy runners on Kubernetes or VMs?
+- How to provision ephemeral runner images? (Docker, Nix, Terraform?)
+- Session affinity: can one user's job see another's?
+- Secret injection: per-runner vault, or shared secret store?
+
+## Why deferred from 11.0.0
+Infra dependency: requires managed runner service outside repo scope. Licensing cost unclear. No tier-A demand.

package/docs/v11/C3-reproducible-environments.md

@@ -0,0 +1,30 @@
+# C3: Reproducible environments
+
+## Problem
+Build outputs depend on local environment state: npm versions, Go compiler, Python packages. Runs fail or diverge when run elsewhere.
+- Nondeterministic outputs break verification receipts
+- Requires environment lockfiles for Node, Go, Python, etc.
+- CI builds differ from local development
+
+## Current state
+- `package.json` and `go.mod` are source-of-truth (no pinned lock files shipped)
+- `scripts/local-ci.sh` does not enforce lockfile generation
+- Docker builds use untagged base images (always latest)
+- `Dockerfile` line 3 uses `FROM node:20` (no SHA pin)
+
+## Proposed v1 scope
+- Mandate `npm ci` (not `npm install`) in all build scripts
+- Pin Go 1.22.x in `go.mod` + `go.sum` required
+- Pin Python dependencies in `requirements.txt` or `uv.lock`
+- Dockerfile uses SHA-pinned base images: `FROM node:20@sha256:abc123...`
+- Build script emits `_environment.json` with tool versions
+- Receipt validation includes environment hash
+
+## Open questions
+- Which lockfile format per language? (npm ci, Poetry, pip-compile?)
+- How often to refresh pins? (monthly, per release, never?)
+- Should CI enforce `git diff --check` on lockfiles?
+- How to handle transitive dependencies that vary per OS?
+
+## Why deferred from 11.0.0
+Design work needed: pin strategy, validation rules. No current receipt validation.

package/docs/v11/C4-bitbucket-azure.md

@@ -0,0 +1,29 @@
+# C4: Bitbucket and Azure DevOps
+
+## Problem
+Loki Mode integrates with GitHub only: issue parsing, webhook dispatch, status updates. Enterprise customers use:
+- Bitbucket Cloud/Server
+- Azure DevOps (ADO)
+- GitLab (via webhook, but no parsing)
+
+## Current state
+- `mcp/server.py` has `/webhooks/github` only (line ~340)
+- Issue parsing in `autonomy/parse-issue.sh` calls GitHub API only
+- Status updates via `gh api repos/...` (GitHub CLI)
+- No abstraction over VCS platform
+
+## Proposed v1 scope
+- VCS abstraction layer: detect provider from webhook origin
+- Bitbucket Cloud: parse PR/issue webhook, query API, post status
+- Azure DevOps: parse webhook, query ADO API, post build status
+- CLI flag `--vcs=bitbucket` to override GitHub default
+- Detect provider from repo URL (bitbucket.org, dev.azure.com, github.com)
+
+## Open questions
+- Bitbucket Cloud vs Server vs Data Center: which to ship first?
+- ADO: personal access token vs service principal auth?
+- Status API parity: are all GitHub status fields available in Bitbucket/ADO?
+- How to test without paid Bitbucket/ADO accounts?
+
+## Why deferred from 11.0.0
+No tier-A demand. Requires test accounts and API key management.

package/docs/v11/C5-open-local-models.md

@@ -0,0 +1,29 @@
+# C5: Open or local models
+
+## Problem
+Loki Mode ships with Claude, Codex, and Gemini APIs only. Customers want:
+- Local LLM inference (Ollama, vLLM) for data privacy
+- Open models (Llama 3, Mistral, Qwen) to reduce cost
+- Model selection per task (Haiku for tests, Opus for planning)
+
+## Current state
+- `providers/claude.sh`, `codex.sh`, `gemini.sh` call their respective APIs
+- No local model runner
+- Model hardcoded in CLI config
+- No OpenAI-compatible API abstraction
+
+## Proposed v1 scope
+- OpenAI-compatible interface (Ollama, vLLM, LocalAI)
+- Provider: `LOKI_PROVIDER=local LOKI_LOCAL_API=http://127.0.0.1:8000`
+- Model selection: `LOKI_MODEL=llama2:70b` or `mistral`
+- Provider loader detects local vs remote API
+- Fallback chain: try local first, fail if unreachable
+
+## Open questions
+- Which local runners to support? (Ollama primary, vLLM, LocalAI fallback?)
+- Model registry: hardcoded list or discovery from endpoint?
+- Context window limits: how to query max_tokens from Ollama?
+- How to test CI without hosting local models?
+
+## Why deferred from 11.0.0
+Adds infrastructure cost and complexity. No tier-A demand. Requires Ollama/vLLM hosting.

package/docs/v11/C6-secrets-handling.md

@@ -0,0 +1,31 @@
+# C6: Secrets handling
+
+## Problem
+Credentials are passed via env vars (AWS_ACCESS_KEY, GITHUB_TOKEN, etc.). Risk:
+- Secrets leak into logs, artifacts, run output
+- No audit trail of secret access
+- Plaintext in environment diff
+- No rotation policy
+
+## Current state
+- Secrets passed as env vars to agent invocations
+- Logs captured to artifacts (may contain redacted secrets)
+- `mcp/server.py` has no secrets table
+- Dashboard shows run output plaintext
+
+## Proposed v1 scope
+- Secrets table: name, provider (AWS, GitHub, etc.), encrypted value
+- Rotation API: `POST /secrets/rotate` with grace period
+- Log redaction: regex patterns to mask secrets in output
+- Audit log: who accessed which secret, when
+- CLI flag `--secret-backend=vault` to specify provider (vault, 1Password, AWS Secrets Manager)
+- Output filter: scrub secrets before storing artifacts
+
+## Open questions
+- Which secret backends to ship: Vault, 1Password, AWS Secrets Manager?
+- Grace period on secret rotation: 0s (immediate) or 24h (slow rollout)?
+- Audit log retention: how long to keep secret access records?
+- How to test secret redaction without real credentials?
+
+## Why deferred from 11.0.0
+Scope: secrets backend integration, redaction and audit together. No tier-A demand. Security review required.

package/docs/v11/C7-windows.md

@@ -0,0 +1,30 @@
+# C7: Windows
+
+## Problem
+Loki Mode is tested on macOS and Linux only. Windows users face:
+- Bash scripts fail or require WSL (Windows Subsystem for Linux)
+- PowerShell incompatibilities (no `set -e` equivalent)
+- Path separators: `/` vs `\` hardcoded
+- No native executable (only Node.js bundle)
+
+## Current state
+- All scripts in `bash/` or sourced by `run.sh` (Bash 4+)
+- No PowerShell equivalents
+- CI uses Linux runners only
+- Binary distribution via npm (requires Node.js on Windows)
+
+## Proposed v1 scope
+- PowerShell shims for core scripts (run.ps1, invoke.ps1)
+- Path abstraction: use cross-platform join logic
+- Package Windows native binary (Go cross-compile to loki-mode.exe)
+- CI: add Windows Server 2022 runner
+- Test matrix: bash (WSL), PowerShell, native exe
+
+## Open questions
+- Ship PowerShell or require WSL?
+- Native exe in Go or keep Node.js only?
+- How to handle symlinks (junction points on Windows)?
+- CI cost: GitHub Windows runners are 2x cost of Linux
+
+## Why deferred from 11.0.0
+Windows demand is not measured. Cross-platform testing complexity. CI cost.

package/docs/v11/C8-public-benchmark.md

@@ -0,0 +1,30 @@
+# C8: Public benchmark
+
+## Problem
+No standardized benchmark for Loki Mode. Claimed metrics (30-60 releases/day, 10x10 slice parallelization) lack published data:
+- No baseline to compare against other systems
+- No proof-of-function for customers
+- Benchmark results not auditable or reproducible
+
+## Current state
+- Internal metrics in `docs/dev/METRICS.md` (not public)
+- Release velocity measured via git log (post hoc)
+- No standardized test suite for competitors
+- No published SWE-bench score or equivalent
+
+## Proposed v1 scope
+- Benchmark suite: 50-100 representative tasks (swebench subset, internal tests)
+- Auto-grade output against oracle (code compiles, tests pass, etc.)
+- Publish results: tasks completed, time-to-first-try, cost per task
+- CI run daily, publish results to website
+- Competitor parity: run same suite on Cursor, Cline, Factory
+- Result dataset: JSON with timestamps, model, cost, success
+
+## Open questions
+- Which benchmark? (swebench, humaneval, internal tasks, or custom?)
+- Grade criteria: test pass only, or coverage, latency, cost?
+- Frequency: daily, weekly, or per release?
+- Competitor data: public (Cursor, Devin) or private agreement?
+
+## Why deferred from 11.0.0
+Benchmark design requires domain expertise. Cost per run unclear. Competitor data agreements needed.x is production-ready.

package/docs/v11/C9-opt-in-telemetry.md

@@ -0,0 +1,33 @@
+# C9: Opt-in telemetry
+
+## Problem
+Loki Mode emits no telemetry: build lifecycle, errors, user flows are invisible. Cannot measure:
+- Which features are used
+- Which gates fail most often
+- Where users drop off
+- How to improve UX
+
+Without telemetry, product decisions are guesses.
+
+## Current state
+- No telemetry client in mcp/server.py or autonomy/run.sh
+- GitHub Actions CI has no event tracking
+- Dashboard renders with no page-load tracking
+- Error reporting is manual only (GitHub issues)
+
+## Proposed v1 scope
+- Event schema: run_start, run_end, gate_failure, error, UI action
+- Collector endpoint: HTTP POST to telemetry backend
+- Opt-in only: default off, nothing sent unless the user turns it on
+- PII redaction: no file paths, user email, or secrets in events
+- Client library: shared across CLI, dashboard, API
+- Data retention: not decided (open question)
+
+## Open questions
+- Which backend? (self-hosted, Segment, Datadog, Amplitude?)
+- What is "error-only" baseline? (auth failures, CI reds, agent errors?)
+- Data ownership: customer data stays in account or shipped to us?
+- GDPR/SOC2: does telemetry require compliance review?
+
+## Why deferred from 11.0.0
+Privacy and compliance review required. Requires backend infrastructure. Data retention policy needs legal.

package/docs/v11/README.md

@@ -0,0 +1,32 @@
+# v11 Roadmap: Tier C Deferred Features
+
+This directory documents the Tier C features deferred from v11.0.0. Each feature file contains:
+- Problem: user need or gap
+- Current state: implementation status with file paths
+- Proposed v1 scope: minimal viable implementation
+- Open questions: design decisions needed
+- Why deferred: rationale and timing
+
+## Features (C1-C11)
+
+| Feature | Title | Scheduled | Status |
+|---------|-------|-----------|--------|
+| C1 | Multi-user logins, roles and SSO | not scheduled | Deferred |
+| C2 | Hosted or remote runner | not scheduled | Deferred |
+| C3 | Reproducible environments | not scheduled | Deferred |
+| C4 | Bitbucket and Azure DevOps | not scheduled | Deferred |
+| C5 | Open or local models | not scheduled | Deferred |
+| C6 | Secrets handling | not scheduled | Deferred |
+| C7 | Windows | not scheduled | Deferred |
+| C8 | Public benchmark | not scheduled | Deferred |
+| C9 | Opt-in telemetry | not scheduled | Deferred |
+| C10 | The 8090 teardown | not scheduled | Deferred |
+| C11 | MCP-MODERN (next minor) | not scheduled | Deferred |
+
+## Deferral rationale
+
+All Tier C features are deferred so that 11.0.0 stays scoped to the Tier A and Tier B rows in docs/v10/RELEASE-11.md. Each file below records the problem, the current state and the open questions; none carries a schedule.
+
+## Reading guide
+
+Start with the feature title in the table above, then read its .md file for context. For strategic decisions (C1 auth, C6 secrets, C9 telemetry), flag open questions with the CTO. For research tasks (C10), assign to the Competitor Intelligence team.