loki-mode 10.5.16 → 10.5.19

package/docs/enterprise/integration-cookbook.md

@@ -1,4 +1,4 @@
-# Loki Mode v5.51.0 -- Integration Cookbook
+# Loki Mode Integration Cookbook
 
 Step-by-step guides for connecting Loki Mode to external services. Each integration is opt-in and configured via environment variables.
 
@@ -173,9 +173,16 @@ curl -X POST "$LOKI_TEAMS_WEBHOOK_URL" \
 | Variable | Required | Description |
 |----------|----------|-------------|
 | `LOKI_JIRA_URL` | Yes | Jira Cloud base URL |
-| `LOKI_JIRA_EMAIL` | Yes | Jira user email for authentication |
 | `LOKI_JIRA_TOKEN` | Yes | Jira API token |
-| `LOKI_JIRA_PROJECT_KEY` | No | Default Jira project key |
+| `LOKI_JIRA_EPIC_KEY` | No | Epic that run events are synced to |
+
+These are read by `src/integrations/sync-subscriber.js`. The Jira user email is
+passed to `JiraApiClient` in code (see below); no environment variable carries it.
+
+Known issue on main: `src/integrations/sync-subscriber.js` constructs `JiraApiClient`
+without the `email` and `apiToken` it requires, so Jira auto-sync from these
+variables does not start. Construct `JiraApiClient({ baseUrl, email, apiToken })`
+in code until that is fixed.
 
 ### Configuration
 
@@ -187,9 +194,7 @@ curl -X POST "$LOKI_TEAMS_WEBHOOK_URL" \
 
    ```bash
    export LOKI_JIRA_URL="https://company.atlassian.net"
-   export LOKI_JIRA_EMAIL="user@company.com"
    export LOKI_JIRA_TOKEN="your-api-token"
-   export LOKI_JIRA_PROJECT_KEY="PROJ"
    ```
 
 3. **Epic Sync:**
@@ -202,7 +207,7 @@ curl -X POST "$LOKI_TEAMS_WEBHOOK_URL" \
 
    const api = new JiraApiClient({
      baseUrl: process.env.LOKI_JIRA_URL,
-     email: process.env.LOKI_JIRA_EMAIL,
+     email: 'user@company.com',
      apiToken: process.env.LOKI_JIRA_TOKEN,
    });
 
@@ -250,11 +255,11 @@ curl -X POST "$LOKI_TEAMS_WEBHOOK_URL" \
 
 ```bash
 # Test Jira API access
-curl -u "$LOKI_JIRA_EMAIL:$LOKI_JIRA_TOKEN" \
+curl -u "user@company.com:$LOKI_JIRA_TOKEN" \
   "$LOKI_JIRA_URL/rest/api/3/myself" | python3 -m json.tool
 
 # Test epic fetch
-curl -u "$LOKI_JIRA_EMAIL:$LOKI_JIRA_TOKEN" \
+curl -u "user@company.com:$LOKI_JIRA_TOKEN" \
   "$LOKI_JIRA_URL/rest/api/3/issue/PROJ-123" | python3 -m json.tool
 ```
 
@@ -282,9 +287,12 @@ curl -u "$LOKI_JIRA_EMAIL:$LOKI_JIRA_TOKEN" \
 
 | Variable | Required | Description |
 |----------|----------|-------------|
-| `LOKI_LINEAR_API_KEY` | Yes | Linear personal API key |
+| `LOKI_LINEAR_TOKEN` | Yes | Linear personal API key |
 | `LOKI_LINEAR_TEAM_ID` | No | Default team ID for issue creation |
-| `LOKI_LINEAR_WEBHOOK_SECRET` | No | Webhook signing secret for inbound events |
+| `LOKI_LINEAR_PROJECT_ID` | No | Project that run events are synced to |
+
+The webhook signing secret is not an environment variable; set `webhook_secret`
+under `integrations.linear` in `.loki/config.yaml`.
 
 ### Configuration
 
@@ -295,7 +303,7 @@ curl -u "$LOKI_JIRA_EMAIL:$LOKI_JIRA_TOKEN" \
 2. **Set Environment Variables:**
 
    ```bash
-   export LOKI_LINEAR_API_KEY="lin_api_your_key_here"
+   export LOKI_LINEAR_TOKEN="lin_api_your_key_here"
    export LOKI_LINEAR_TEAM_ID="your-team-id"
    ```
 
@@ -304,7 +312,7 @@ curl -u "$LOKI_JIRA_EMAIL:$LOKI_JIRA_TOKEN" \
    ```javascript
    const { LinearClient } = require('./src/integrations/linear/client');
 
-   const client = new LinearClient(process.env.LOKI_LINEAR_API_KEY);
+   const client = new LinearClient(process.env.LOKI_LINEAR_TOKEN);
 
    // Fetch a project with all issues
    const project = await client.getProject('project-id');
@@ -338,14 +346,15 @@ curl -u "$LOKI_JIRA_EMAIL:$LOKI_JIRA_TOKEN" \
 
 5. **Webhook Handler (optional):**
 
-   Configure Linear to send webhooks to your Loki Mode instance for bidirectional sync.
+   Configure Linear to send webhooks to your Loki Mode instance. Signatures are
+   verified when `webhook_secret` is set (`src/integrations/linear/sync.js`).
 
 ### Verification
 
 ```bash
 # Test Linear API access
 curl -X POST https://api.linear.app/graphql \
-  -H "Authorization: $LOKI_LINEAR_API_KEY" \
+  -H "Authorization: $LOKI_LINEAR_TOKEN" \
   -H "Content-Type: application/json" \
   -d '{"query": "{ viewer { id name } }"}'
 ```

package/docs/enterprise/migration.md

@@ -1,4 +1,4 @@
-# Loki Mode v5.51.0 -- Migration Guide
+# Loki Mode Migration Guide
 
 ## Upgrading from v5.50.0 to v5.51.0
 
@@ -76,10 +76,7 @@ See `docs/enterprise/sdk-guide.md` for installation and usage.
 | `LOKI_TEAMS_WEBHOOK_SECRET` | (unset) | Teams webhook shared secret |
 | `LOKI_OIDC_ISSUER` | (unset) | OIDC identity provider URL |
 | `LOKI_OIDC_CLIENT_ID` | (unset) | OIDC client ID |
-| `LOKI_OIDC_CLIENT_SECRET` | (unset) | OIDC client secret |
-| `LOKI_OIDC_REDIRECT_URI` | (unset) | OIDC redirect URI |
-| `LOKI_CORS_ORIGINS` | localhost | Allowed CORS origins |
-| `LOKI_API_RATE_LIMIT` | 100 | API rate limit (requests/min) |
+| `LOKI_DASHBOARD_CORS` | localhost | Allowed CORS origins |
 
 ### Existing Environment Variables (Unchanged)
 
@@ -101,12 +98,11 @@ These variables from v5.50.0 continue to work identically:
 | `LOKI_TLS_CERT` | (unset) | TLS certificate path |
 | `LOKI_TLS_KEY` | (unset) | TLS key path |
 | `LOKI_JIRA_URL` | (unset) | Jira Cloud base URL |
-| `LOKI_JIRA_EMAIL` | (unset) | Jira user email |
 | `LOKI_JIRA_TOKEN` | (unset) | Jira API token |
-| `LOKI_JIRA_PROJECT_KEY` | (unset) | Default Jira project key |
-| `LOKI_LINEAR_API_KEY` | (unset) | Linear API key |
+| `LOKI_JIRA_EPIC_KEY` | (unset) | Jira epic that run events sync to |
+| `LOKI_LINEAR_TOKEN` | (unset) | Linear API key |
 | `LOKI_LINEAR_TEAM_ID` | (unset) | Linear team ID |
-| `LOKI_LINEAR_WEBHOOK_SECRET` | (unset) | Linear webhook secret |
+| `LOKI_LINEAR_PROJECT_ID` | (unset) | Linear project that run events sync to |
 | `LOKI_GITHUB_SYNC` | (unset) | Enable GitHub sync |
 
 ### API Changes

package/docs/enterprise/performance.md

@@ -1,4 +1,4 @@
-# Loki Mode v5.51.0 -- Enterprise Performance Tuning
+# Loki Mode Enterprise Performance Tuning
 
 ## Overview
 
@@ -233,11 +233,8 @@ uvicorn dashboard.server:app --workers 4 --host 0.0.0.0 --port 57374
 
 Dashboard API rate limits protect against abuse:
 
-```bash
-# Default rate limits are built into the API layer
-# Override via env vars if needed
-export LOKI_API_RATE_LIMIT="100"  # requests per minute
-```
+Rate limits are built into the API layer (10 requests/min on control endpoints,
+60 on rate-limited read endpoints) and are not configurable by environment variable.
 
 ### Static Asset Caching
 

package/docs/enterprise/sdk-guide.md

@@ -1,4 +1,4 @@
-# Loki Mode v5.51.0 -- SDK Guide
+# Loki Mode SDK Guide
 
 Official Python and TypeScript SDKs for the Autonomi Control Plane API. Both SDKs have zero external dependencies -- they use only standard library features.
 

package/docs/enterprise/security.md

@@ -1,4 +1,4 @@
-# Loki Mode v5.51.0 -- Enterprise Security
+# Loki Mode Enterprise Security
 
 ## Overview
 
@@ -167,27 +167,18 @@ When both variables are set, the dashboard server binds on HTTPS only. Self-sign
 
 ### Rate Limiting
 
-The API enforces rate limits per token/IP:
-
-| Endpoint Group | Default Limit |
-|----------------|---------------|
-| Read operations | 100 req/min |
-| Write operations | 30 req/min |
-| Auth operations | 10 req/min |
-
-Rate limit headers are included in every response:
-```
-X-RateLimit-Limit: 100
-X-RateLimit-Remaining: 95
-X-RateLimit-Reset: 1708520460
-```
+The dashboard API applies in-process rate limits (`_RateLimiter` in
+`dashboard/server.py`): 10 requests/min on control endpoints and 60
+requests/min on rate-limited read endpoints. Exceeding them returns HTTP 429.
+The limits are not configurable by environment variable, and no
+`X-RateLimit-*` headers are sent.
 
 ### CORS
 
 CORS is configured via environment variables:
 
 ```bash
-export LOKI_CORS_ORIGINS="https://dashboard.company.com,https://admin.company.com"
+export LOKI_DASHBOARD_CORS="https://dashboard.company.com,https://admin.company.com"
 ```
 
 Default behavior: `localhost` origins are allowed for development. In production, explicitly set allowed origins.
@@ -228,7 +219,7 @@ This is a deliberate fail-closed design. Invalid or missing signatures always re
 
 ## Audit Logging
 
-### Hash-Chained Tamper-Evident Logs
+### Hash-Chained Audit Logs
 
 Audit logs use SHA-256 hash chains for tamper evidence. Each entry's hash depends on the previous entry's hash, creating an immutable chain from the genesis record.
 

package/docs/exit-codes.md

@@ -50,6 +50,20 @@ immediately instead of burning `backoffLimit`. Requires Kubernetes 1.31+.
 Both the bash runner and the Bun runner (`LOKI_SDK_LOOP`) implement this
 identically; a parity test asserts they agree status for status.
 
+## `loki quick`
+
+| Code | Meaning |
+|---|---|
+| 0 | The run completed and its diff did not weaken the tests |
+| 3 | The diff weakened the tests (a skip marker added in a test file, a test runner config changed, or an existing test file deleted or renamed). The receipt headline is NOT VERIFIED and names what was weakened, for example `NOT VERIFIED (tests weakened: skip added in sum.test.js)` |
+| other nonzero | The run itself failed; this code is passed through unchanged |
+
+Code 3 only ever raises an exit of 0, in quiet and `LOKI_VERBOSE=1` modes alike;
+it never lowers another nonzero code. Edited assertion lines are disclosed in
+the receipt (`tests_integrity:assertions_edited`) and keep exit 0. A NOT VERIFIED
+headline caused by unproven gates alone also keeps exit 0. The signal is the
+`tests_integrity` item in the proof's `honesty.degraded`, not the headline text.
+
 ## `loki verify`
 
 | Code | Verdict |
@@ -63,6 +77,21 @@ Code 3 matters more than it looks. A verifier that cannot run is not a pass,
 so `[ $rc -eq 0 ]` is the only safe test for "verified" -- `[ $rc -ne 2 ]`
 would treat a broken verifier as acceptable.
 
+### UNSIGNED receipts (D47)
+
+An UNSIGNED receipt (no attestation, so its integrity is not attested) is never
+a pass, on either engine, with or without a local key. A stripped receipt must
+not rank above UNCHECKED.
+
+| Engine | UNSIGNED without the flag | With `--allow-unsigned` or `LOKI_VERIFY_ALLOW_UNSIGNED=1` |
+|---|---|---|
+| Engine10 (`loki-ts`, `verify_cmd.ts`) | exit 3, `attestation: UNSIGNED, integrity not attested; refusing (pass --allow-unsigned to accept)` | exit 0, `attestation: UNSIGNED (accepted by --allow-unsigned; integrity not attested)` |
+| Legacy shell (`autonomy/verify.sh`) | BLOCKED (non-zero) | the receipt line passes with the same accepted line |
+
+Engine10 `loki verify [run-id]` exits: 0 verified, 1 tampered, 2 unchecked,
+3 unsigned (refused), 66 no runs. The flag never changes TAMPERED or UNCHECKED,
+and verify never creates a signing key.
+
 An early draft spec listed `1=BLOCKED, 2=CONCERNS`. That ordering was rejected:
 it is not used anywhere, it has no consumers, and it inverts the
 severity-rises-with-the-code rule that every other command follows.

package/docs/git-workflow.md

@@ -19,7 +19,7 @@ When enabled, Loki Mode automatically:
 
 1. Creates a feature branch: `loki/session-<timestamp>-<pid>`
 2. Performs all agent work on the feature branch
-3. Creates a PR at session end (if GitHub CLI is available)
+3. Creates a PR at session end when `LOKI_AUTO_PR=1` (and GitHub CLI is available)
 4. Requires manual review and merge to main
 
 ### Feature Branch Naming
@@ -62,25 +62,8 @@ Delete feature branch
 
 | Variable | Default | Description |
 |----------|---------|-------------|
-| `LOKI_BRANCH_PROTECTION` | `false` | Enable automatic feature branch workflow |
-| `LOKI_BASE_BRANCH` | `main` | Target branch for PRs (or `master` if detected) |
-| `LOKI_BRANCH_PREFIX` | `loki/session-` | Prefix for auto-created branches |
-| `LOKI_AUTO_PR` | `true` | Automatically create PR at session end |
-| `LOKI_PR_TEMPLATE` | - | Path to PR description template |
-
-### Configuration File
-
-```yaml
-# .loki/config.yaml
-git:
-  branch_protection:
-    enabled: true
-    base_branch: main
-    branch_prefix: loki/session-
-    auto_pr: true
-    squash_merge: true
-    delete_after_merge: true
-```
+| `LOKI_BRANCH_PROTECTION` | `true` | Run agent work on an auto-created `loki/session-<timestamp>-<pid>` branch |
+| `LOKI_AUTO_PR` | off | Set to `1` to push the session branch and open a PR at session end |
 
 ## Manual Git Workflow
 
@@ -126,7 +109,7 @@ git push origin feature/my-feature
 
 ### Automatic PR Creation
 
-When `LOKI_AUTO_PR=true` and GitHub CLI is installed:
+When `LOKI_AUTO_PR=1` and GitHub CLI is installed:
 
 ```bash
 # Loki Mode automatically runs at session end
@@ -137,47 +120,6 @@ gh pr create \
   --head loki/session-20260215-143022-12345
 ```
 
-### PR Description Template
-
-Create a template for consistent PR descriptions:
-
-```markdown
-# .loki/pr-template.md
-
-## Changes
-
-<!-- Auto-generated summary of changes -->
-
-## Tasks Completed
-
-<!-- List of completed tasks from task queue -->
-
-## Quality Gates
-
-- [ ] All tests passing
-- [ ] Code review completed
-- [ ] No security vulnerabilities
-- [ ] Documentation updated
-
-## Cost
-
-Estimated cost: $X.XX USD
-
-## Session Info
-
-- Start: YYYY-MM-DD HH:MM:SS
-- End: YYYY-MM-DD HH:MM:SS
-- Duration: X hours
-- Iterations: X
-- Provider: claude/cline/codex/aider/opencode
-```
-
-Set template path:
-
-```bash
-export LOKI_PR_TEMPLATE=.loki/pr-template.md
-```
-
 ## Agent Action Audit
 
 All Git operations performed by agents are logged to `.loki/logs/agent-audit.jsonl`:

package/docs/network-security.md

@@ -6,19 +6,9 @@ Network egress control and isolation for Loki Mode deployments.
 
 This guide covers network-level security controls for restricting outbound network access from Loki Mode containers and pods to only the AI API endpoints required for operation.
 
-## Environment Variables
-
-**None of the variables below are implemented. Do not rely on them.** They are
-reserved names for a planned application-level enforcement layer, and no
-runtime code reads any of them today. Network security is enforced entirely at
-the infrastructure level, using the Docker network and Kubernetes NetworkPolicy
-recipes in the rest of this guide.
-
-| Variable | Default | Description | Status |
-|----------|---------|-------------|--------|
-| `LOKI_NETWORK_EGRESS_POLICY` | `unrestricted` | `unrestricted` (default), `ai-only` (restrict to AI APIs), `none` (block all outbound) | Planned, target TBD |
-| `LOKI_ALLOWED_HOSTS` | (empty) | Comma-separated list of additional hostnames to allow when egress policy is `ai-only` | Planned, target TBD |
-| `LOKI_BLOCK_METADATA_ENDPOINT` | `false` | Block cloud metadata endpoint (169.254.169.254) from within the application | Planned, target TBD |
+Loki Mode has no application-level egress setting: no runtime code restricts
+outbound hosts. Network security is enforced entirely at the infrastructure
+level, using the Docker network and Kubernetes NetworkPolicy recipes below.
 
 ## Docker Network Isolation
 

package/docs/plans/ULTRAPLAN-FORGE-BAAS.md

@@ -25,7 +25,7 @@ Loki Mode today is a **multi-agent autonomous orchestrator**, not a BaaS. It own
 - An auth layer (`dashboard/auth.py`, `web-app/auth.py`) supporting Bearer tokens, OIDC (Google/Azure/Okta), bcrypt password hashing, RBAC scopes
 - A working completion-council with anti-sycophancy, 3-reviewer parallel review, devil's-advocate fallback
 - A healing-mode for legacy systems (v6.67+) with friction-as-semantics
-- 41 specialized agent types and a queue system
+- Specialized agent types and a queue system
 
 **The gap:** every backend primitive Loki owns is for orchestrating the agent. None of it is for the *application the agent is building*. When `loki start ./prd.md` builds "a Twitter clone with login and image uploads", the agent has to invent the auth flow, choose a DB, set up storage, wire Stripe, etc. - and the user has to run a parallel set of tools (Supabase, Stripe, Cloudflare R2) to support the resulting app.
 

package/docs/prd-purple-lab-platform-v2.md

@@ -165,7 +165,7 @@ URL bar showing current preview path, Refresh button, Open in New Tab button.
 Based on feedback:
 - Memory System Viewer (power-user debug tool, not customer-facing)
 - Full Integrations page (keep GitHub only, defer Jira/Linear/Slack/Teams)
-- 41-agent grid (most sessions have 1-3 agents active; show compact list instead)
+- Agent grid (most sessions have 1-3 agents active; show compact list instead)
 - Code Review panel (let quality gates surface findings inline)
 - Collaboration/multiplayer (acknowledged as future need, not v1)
 - Database provisioning (out of scope for v1)

package/docs/prd-purple-lab-platform.md

@@ -137,8 +137,6 @@ Each card:
 
 Integrations available:
 - **GitHub**: Connect repo, import issues, create PRs (`loki github`, `loki run`)
-- **Jira**: Bidirectional sync (`LOKI_JIRA_*` env vars)
-- **Linear**: Issue sync (`LOKI_LINEAR_*` env vars)
 - **Slack**: Notifications + slash commands (`LOKI_SLACK_*`)
 - **Teams**: Adaptive Cards notifications (`LOKI_TEAMS_*`)
 - **OpenTelemetry**: Trace export (`loki telemetry`)
@@ -197,7 +195,7 @@ Each gate: name, status (pass/fail/pending), details expandable
 
 ### Agent Activity
 
-Real-time grid showing which of the 41 agent types are active:
+Real-time grid showing which agent types are active:
 - Agent name, type, domain, model tier (Opus/Sonnet/Haiku)
 - Current task
 - Status (working/idle/completed)

package/docs/research-2026-07/GAP-ANALYSIS-BACKLOG.md

@@ -65,7 +65,7 @@ Acceptance criteria:
 Validation: Fixture repos: (A) spec names endpoint /orders that exists -> no finding; (B) spec names /orders but no handler -> High finding; (C) plaintext password store -> invariant finding. Measure false-positive rate on 3 clean real repos (must be zero). Prove accuracy lift on the FrontierCode-style benchmark (rank 12): source-grounded checklists should catch wrong-but-internally-consistent implementations that prose-only checklists pass.
 
 ### #3 Annotate-before-act: pre-committed expected-outcome ledger, diffed against reality at verify time (loki-mode, high/L)
-Before running verification for a change/checklist-item, the runtime writes a tamper-evident ledger of EXPECTED observable outcomes (e.g. 'GET /health -> 200 {status:ok}', 'test X fails before fix, passes after', 'endpoint Y should now exist'). At verify time, actual results are compared to the pre-committed prediction; any expectation silently dropped or contradicted becomes a finding. Reuse the proof-verify canonical-hash + drift pattern so the ledger is tamper-evident and edits-after-the-fact are detectable. Forces a falsifiable prediction, cutting self-serving post-hoc rationalization.
+Before running verification for a change/checklist-item, the runtime writes a hash-chained ledger of EXPECTED observable outcomes (e.g. 'GET /health -> 200 {status:ok}', 'test X fails before fix, passes after', 'endpoint Y should now exist'). At verify time, actual results are compared to the pre-committed prediction; any expectation silently dropped or contradicted becomes a finding. Reuse the proof-verify canonical-hash + drift pattern so the ledger is tamper-evident and edits-after-the-fact are detectable. Forces a falsifiable prediction, cutting self-serving post-hoc rationalization.
 Acceptance criteria:
 - .loki/expectations/<iter>.json written BEFORE the verify/checklist run, each entry {id, statement, check_ref, expected}, canonicalized and hashed like proof-generator
 - loki verify (or the completion gate) reads the ledger and emits a finding for any expectation with no matching executed check, or whose actual contradicts expected

package/docs/show-hn-post.md

@@ -2,13 +2,13 @@
 
 ## Title
 
-Show HN: Loki Mode - PRD in, tested code out (41 agent roles, 8 quality gates, RARV self-verification)
+Show HN: Loki Mode - PRD in, tested code out (8 quality gates, RARV self-verification)
 
 ## Body
 
 I built Loki Mode because I got tired of the copy-paste loop between AI coding assistants and my terminal. I wanted to hand over a PRD and get back a working, tested codebase -- not perfect, but a solid starting point.
 
-**What it does:** You give it a Product Requirements Document. It breaks the work into tasks across 41 specialized agent roles organized into 8 domains (engineering, operations, business, data, product, growth, review, orchestration) -- prompt-defined specifications the orchestrator adopts per phase, with parallel review (blind council) and optional worktree streams on Claude Code, sequential on other providers -- and runs every iteration through a self-verification loop called RARV: Reason, Act, Reflect, Verify. The idea is that the system catches its own mistakes before you have to.
+**What it does:** You give it a Product Requirements Document. It breaks the work into tasks across specialized agent roles (engineering, operations, business, data, product, growth, review, orchestration) -- prompt-defined specifications the orchestrator adopts per phase, with parallel review (blind council) and optional worktree streams on Claude Code, sequential on other providers -- and runs every iteration through a self-verification loop called RARV: Reason, Act, Reflect, Verify. The idea is that the system catches its own mistakes before you have to.
 
 **Quality gates:** 8 automated gates including 3-reviewer blind review (agents review each other's work without seeing prior reviews), anti-sycophancy checks (a devil's advocate pass on unanimous approvals), and mock/mutation detection. These are not foolproof, but they catch a surprising number of issues that single-pass generation misses.
 
@@ -20,9 +20,8 @@ I built Loki Mode because I got tired of the copy-paste loop between AI coding a
 
 **Research foundation:** The architecture draws from Anthropic's Constitutional AI (principles-based self-critique), DeepMind's Scalable Oversight via Debate, and OpenAI's Agents SDK patterns (guardrails, tripwires, handoffs). References to specific papers are in the repo.
 
-**What it does NOT do:** It does not deploy anything. It generates deployment configs (Helm, Docker Compose, Terraform), but a human deploys. Complex domain logic will need human review. The system can and does make mistakes, especially on novel problems. Token costs scale with project complexity. Our SWE-bench numbers (299/300 patches generated) measure output, not resolution -- the official evaluator has not been run, so the actual fix rate is unknown and likely significantly lower than the generation rate. The HumanEval score is self-reported with max 3 retries per problem.
+**What it does NOT do:** It does not deploy anything. It generates deployment configs (Helm, Docker Compose, Terraform), but a human deploys. Complex domain logic will need human review. The system can and does make mistakes, especially on novel problems. Token costs scale with project complexity. There is no published benchmark score.
 
-**Test suite:** 683 npm tests, 631 pytest tests, 16 shell tests. Self-reported HumanEval score of 162/164 (98.78%).
 
 Built solo. BUSL-1.1 source-available.
 

package/docs/siem-integration.md

@@ -8,7 +8,7 @@ Loki Mode supports integration with enterprise SIEM systems for:
 
 - Centralized security monitoring
 - Real-time threat detection
-- Compliance reporting (SOC2, HIPAA, PCI-DSS)
+- Audit evidence for your own compliance reporting
 - Incident response
 - Forensic analysis
 
@@ -385,7 +385,6 @@ logs:
     tags:
       - env:production
       - team:security
-      - compliance:soc2
 
 # Process JSON logs
 logs_config:
@@ -487,14 +486,13 @@ in your SIEM, where the correlation and retention rules already live.
 To pull an evidence slice locally for an auditor:
 
 ```bash
-AUDIT=~/.loki/dashboard/audit/audit.jsonl
+AUDIT=~/.loki/dashboard/audit   # one audit-YYYY-MM-DD.jsonl file per day
 
-# Access events in a date range (SOC2 / HIPAA evidence)
-jq -s 'map(select(.timestamp >= "2026-01-01" and .timestamp <= "2026-12-31"))' \
-  "$AUDIT" > audit-evidence.json
+# Events in a date range
+cat "$AUDIT"/audit-*.jsonl | jq -s 'map(select(.timestamp >= "2026-01-01" and .timestamp <= "2026-12-31"))' > audit-evidence.json
 
-# Token lifecycle events (PCI-DSS Requirement 8)
-jq -c 'select(.event | startswith("auth.token."))' "$AUDIT"
+# Token lifecycle events
+cat "$AUDIT"/audit-*.jsonl | jq -c 'select(.resource_type == "token")'
 ```
 
 Verify the hash chain before handing the file over. There is no
@@ -592,8 +590,8 @@ logger -n syslog.example.com -P 514 "Test from Loki Mode"
 echo $LOKI_AUDIT_SYSLOG_HOST
 loki syslog test
 
-# Check for forwarding errors
-loki enterprise audit tail --event syslog.error
+# Check recent audit entries
+loki enterprise audit tail
 ```
 
 ### Format Issues

package/docs/test-scenarios/edge-cases.md

@@ -1,7 +1,7 @@
 # Loki Mode Edge Case Test Scenarios
 
 Agent 12 - Scenario Writing: Edge Cases, Error Paths, Concurrent Usage
-Version: v6.71.1 | Date: 2026-03-24
+Date: 2026-03-24
 
 ---
 
@@ -55,7 +55,7 @@ Version: v6.71.1 | Date: 2026-03-24
 **Given** an autonomous session is running at iteration 15 of 1000
 **When** the network connection drops (DNS resolution fails, API timeout)
 **Then** the system should:
-- The provider CLI (claude/codex/gemini) exits with a non-zero exit code
+- The provider CLI (claude/codex/cline/aider/opencode) exits with a non-zero exit code
 - `run_autonomous()` captures the exit code in `$exit_code` (run.sh:9406)
 - Rate limit detection runs via `is_rate_limited()` (checks for common rate limit strings)
 - If failover is enabled (`LOKI_FAILOVER=true`), attempt `attempt_provider_failover()`

package/docs/test-scenarios/enterprise-scenarios.md

@@ -52,7 +52,7 @@ Source: `.github/workflows/loki-ci-example.yml:41-44`
 ### TW-04: Handoff Between Human and AI Coding
 
 ```
-GIVEN a loki autonomous session is running (iteration 5 of 20)
+GIVEN a Loki autonomous session is running (iteration 5 of 20)
   AND the human developer notices a design issue
 WHEN the developer creates .loki/PAUSE signal file
 THEN the session pauses after the current RARV iteration completes
@@ -66,7 +66,7 @@ Source: `autonomy/run.sh:7897` (check_human_intervention)
 ### TW-05: Project Template Sharing Across Team
 
 ```
-GIVEN the team uses loki templates (13 types: saas, cli, discord-bot, etc.)
+GIVEN the team uses Loki PRD templates (saas, cli, discord-bot, etc.)
   AND the team lead wants to standardize on a custom template
 WHEN the lead creates a PRD template at templates/custom-team.md
   AND commits it to the shared repository
@@ -195,7 +195,7 @@ Source: `skills/parallel-workflows.md`
 ### GI-02: Meaningful AI Commit Messages
 
 ```
-GIVEN a loki session has completed a RARV iteration
+GIVEN a Loki session has completed a RARV iteration
   AND the iteration modified 4 files
 WHEN the autonomous system commits changes
 THEN the commit message follows the format: "<type>: <description>"
@@ -437,7 +437,7 @@ Source: `.github/workflows/release.yml:238-496`
 
 ```
 GIVEN the dashboard WebSocket endpoint is available at /ws
-  AND a CI pipeline is running a loki session
+  AND a CI pipeline is running a Loki session
 WHEN the WebSocket client connects
 THEN real-time events are streamed including:
      - iteration_start / iteration_complete