loki-mode 10.5.17 → 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 |

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

package/docs/v10/BOARD.md

@@ -630,6 +630,8 @@ Source: ~/git/autonomi-dev/research/2026-09-30-adoption/SWARM-PROMPT-ADOPTION.md
 | E-160 | D46 runner contention (peer steer 02:11Z): a green train SHA fast-forwarded to main re-runs Tests (8 shards), Bun Parity, Security Audit and First-run gate on the identical SHA, doubling runner load and queueing the next train. Proposal: on push to main, a first job checks for a successful run of the same workflow at the same SHA from a train/** push and, if found, exits success recording the reused run id (D28: same SHA = same tree); any SHA not train-tested runs in full. CTO call FIRST: OPERATING-MODEL says "Tier B full verification on every main commit (never cancelled on main)"; confirm reuse does not weaken Release required-ci, branch-conditional steps (train vs main), or the Security Audit range (base tag config). Sequence after E-157 r4 (same files) | .github/workflows/test.yml, bun-parity.yml, security-audit.yml, tests/test_release_required_ci.py | HIGH | main push of a train-green SHA records reuse and finishes in under 1 min; an untested SHA runs in full; a train-red SHA is not reused | ready@2026-10-01T02:10Z | CTO decision first; after E-157 |
 | E-161 | INCIDENT 02:46Z: an opus reviewer ran `git checkout --detach <tag>` x7 plus a `.gitleaksignore` overwrite in the SHARED main checkout (reflog 02:46:04Z to 02:46:38Z). Cause: its run-owned clone dir was deleted, the next `cd` into a new clone failed, and the shell cwd fell back to the main checkout; every later command ran there. Restored by the Chief of Staff (`git checkout main`, fafe50dd, clean). Guard: v10-guard.sh (PreToolUse) blocks `git checkout`/`git switch`/`git reset`/`git worktree remove` and writes to tracked files when cwd resolves to the main checkout and the caller is an agent (not the leader session); agent prompts use `cd DIR` followed by an exit-on-failure check. Test: a hook test with cwd=main checkout blocks a detached checkout and allows it in a worktree | scripts/v10-guard.sh, tests | HIGH | detached checkout in main checkout blocked; same in a worktree allowed | ready@2026-10-01T02:47Z | GUARDS.md entry |
 | E-162 | Founder "faster" (03:05Z): slice CI runs only Tier A plus diff-selected suites (the existing Tier A selection), Bun Parity and the structural guards; the full 8-shard Tests stays on train/** and main, and the train stays the release verdict. Frees runners and targets about 2 min slice CI | .github/workflows/test.yml (slice-* job matrix only), tests | HIGH | slice-* push runs no 8-shard matrix; train/** and main still run all 8 shards; a slice touching a suite runs that suite | ready@2026-10-01T03:01Z | after E-157 r4 (same file) |
+| E-165 | tests/test-mirofish-integration.sh line 413 runs `autonomy/loki start --no-mirofish` in the repo root: a live autonomous build that ran about 45 min, switched a worktree branch to loki/session-* and committed a docs change (found by DOC-02). Guard: the test must run against a run-owned fixture repo with a stub provider and LOKI_NO_BROWSER=1, never the repo root; add a structural guard that no test launches start/run against REPO_ROOT | tests/test-mirofish-integration.sh, a structural guard | HIGH | the test never runs loki start in the repo root; guard catches a planted case | ready@2026-10-01T04:07Z | P0 guard (D26) |
+| E-166 | Jira auto-sync never starts: src/integrations/sync-subscriber.js builds JiraApiClient without the required email and apiToken, so LOKI_JIRA_URL plus LOKI_JIRA_TOKEN do nothing (DOC-02 added a known-issue note to the setup docs). Fix the wiring or remove the advertised auto-sync | src/integrations/sync-subscriber.js, tests | MEDIUM | with env set, the subscriber constructs a working client (mocked API) | ready@2026-10-01T04:07Z | none |
 | D49-auto | Auto-promote to latest on Post-Release Smoke success (founder D49) | .github/workflows/promote.yml, tests/test_release_next_tag.py | HIGH | smoke-success from Release promotes; manual smoke never promotes; not-lower guard | merged@2026-10-01T03:03Z | opus APPROVE 5510b8c8. Follow-ups (D49-auto-b): not-lower guard fails OPEN on an npm error (make it fail closed); loki-mode-sdk latest has no not-lower guard; a newer queued promote can replace a pending one in a release burst |
 | D51-A3 | Headless `loki backlog owner/repo --all/--label/--issues` plus loki.yaml (schema, validator, env overrides) | autonomy/lib/backlog.py, autonomy/lib/loki_yaml.py, autonomy/loki, schemas/loki-yaml.schema.json, tests/test-backlog.sh | HIGH | backlog 47/0 | merged@2026-10-01T03:11Z | sonnet APPROVE 14ff9ae2; follow-up D51-A3b: `loki_yaml.py show` echoes a token pasted into git.token_env (redact x-secret-ref fields); no-parser test case; re-run of a failed issue discards its kept worktree |
 | D51-A4 | Slack on the v10 path (PR opened, BLOCKED, finished), webhook from the env var named by LOKI_SLACK_WEBHOOK_ENV, URL redacted, 5s bounded post | loki-ts/src/e10ext/slack_events.ts, engine10/supervisor.ts, tests | MEDIUM | slack tests 40/0 | merged@2026-10-01T03:11Z | sonnet APPROVE adb838b2; one labelled test message after it ships |

package/docs/v10/GUIDE.md

@@ -140,9 +140,11 @@ provider names (`claude`, `codex`, `cline`, `aider`); it is not supported.
 
 Once v10 becomes the default (docs/v10/DECISIONS.md, D29), `loki`, `loki
 status`, `loki verify` and `loki dashboard` with no `LOKI_ENGINE` set will
-mean the v10 commands described above. The previous engine stays fully
-reachable: `loki legacy <args>` and `LOKI_ENGINE=legacy` both route to it,
-unchanged. Nothing is removed at the flip.
+mean the v10 commands described above. The previous engine stays
+reachable through `LOKI_ENGINE=legacy` (bin/loki sends every value other
+than `v10` to it), unchanged. Nothing is removed at the flip. A separate
+legacy alias command is planned (docs/v10/ENGINE.md, E-31) but is not on
+main.
 
 That flip has not happened on main as of this guide. The opt-in line near
 the top of this file and of README.md's section is the one place that

package/docs/v10/METRICS.md

@@ -534,3 +534,39 @@ profiling implement's own internal turn-by-turn timing (not available from
 
 Command: `python3 eval/loki10/stage-profile.py
 ~/loki-ci-logs/eval/e98f-engine/{default,nocascade,nowall}-r{1,2,3}`
+
+## D50 model-lift baseline (small tier)
+
+Measured 2026-09-30 on main c5eaddb0 (harness_sha c5eaddb0, clean; loki-ts deps via `bun install --frozen-lockfile`), claude 2.1.286, 1 rep, 900s cap, EV-3 isolation, provider-reported cost only, hidden tests decide completion. Models from providers/model_catalog.json: claude-haiku-4-5 and claude-sonnet-5. Opus arms not run. The Loki arm is `v10` at default knobs (LOKI_ENGINE=v10, same model pinned via LOKI_EVAL_MODEL).
+
+Subset: the small tier has 29 tasks; 4 arms x 29 would be 116 runs, over the 40-run budget, so the first 10 small-tier tasks by id are used (40 runs total): aiq-52-searchbar, pub-click-2877, pub-click-3059, pub-click-3487, pub-click-3572, pub-humanize-152, pub-humanize-174, pub-humanize-333, pub-jsonschema-1389, pub-markupsafe-417. aiq-52-searchbar is an `expected_outcome: no_change_needed` task. n=10 per arm, 1 rep: every rate has a wide interval (one task is 10 points); this is a baseline, not a gate. Machine load average was 24-37 during the run (more than 2 concurrent arms never ran); wall times are inflated and noisy.
+
+| arm | attempted | completed | rate | median wall, all runs | median wall, completed | total cost | cost per completed | timed out |
+|---|---|---|---|---|---|---|---|---|
+| raw haiku-4-5 | 10 | 4 | 40% | 103.2s | 100.5s | $2.3124 | $0.5781 | 0 |
+| Loki+haiku (v10) | 10 | 7 | 70% | 123.0s | 127.7s | $3.4649 (1 run unmeasured) | $0.4950 | 0 |
+| raw sonnet-5 | 10 | 9 | 90% | 111.6s | 118.0s | $4.9239 | $0.5471 | 0 |
+| Loki+sonnet (v10) | 10 | 5 | 50% | 92.9s | 128.8s | $3.7278 (1 run unmeasured) | $0.7456 | 0 |
+
+Cost per completed = total spend of all 10 runs (failures included) / completed. The 2 unmeasured v10 runs are the aiq-52-searchbar runs that exited in about 1s before any model call (no spend, no provider cost record).
+
+Model lift (D50 targets):
+
+| comparison | completion | cost per completed | time (median, all runs) | verdict |
+|---|---|---|---|---|
+| Loki+haiku vs raw haiku | 70% vs 40% (+30 points, 3 tasks) | $0.4950 vs $0.5781 (-14%) | 123.0s vs 103.2s (1.19x) | lift, within 1.2x |
+| Loki+sonnet vs raw sonnet | 50% vs 90% (-40 points, 4 tasks) | $0.7456 vs $0.5471 (+36%) | 92.9s vs 111.6s (0.83x) | LOSS: below raw X |
+| Loki+haiku vs raw sonnet (cross) | 70% vs 90% (-20 points) | $0.4950 vs $0.5471 (-10%); total $3.46 vs $4.92 (-30%) | 123.0s vs 111.6s | target (>= raw sonnet) NOT met |
+| Loki+sonnet vs raw opus | not run | | | |
+
+Failures by category (every failed or non-completed cell listed; no run timed out or was capped; all rows status ok):
+- raw haiku (6): hidden tests failed with a PR pushed: pub-click-2877, pub-click-3059, pub-humanize-174, pub-humanize-333, pub-jsonschema-1389. aiq-52-searchbar: hidden regression test passed but it pushed a PR on a no-change task (wrong outcome).
+- raw sonnet (1): hidden tests failed with a PR: pub-click-3059.
+- Loki+haiku (3): aiq-52-searchbar: engine refused to start in 1.3s, "dirty tracked tree: M frontend/package-lock.json" (task `setup` npm install rewrote a tracked file; no model call). pub-humanize-174: outcome BLOCKED (spec conflict claimed against existing tests), no PR. pub-humanize-333: PR opened, hidden tests failed.
+- Loki+sonnet (5): aiq-52-searchbar: same dirty-tree refusal in 0.7s. pub-click-2877: outcome ALREADY_SATISFIED claimed, no PR, hidden tests fail (false already-done). pub-humanize-174: FAILED "empty diff without an already_done marker", no PR. pub-click-3059 and pub-humanize-333: PR opened, hidden tests failed.
+
+Findings: (1) the v10 dirty-tree refusal is a harness-vs-engine defect that costs both Loki arms the aiq task (the `no_change_needed` outcome is unreachable when `setup` dirties a tracked file); not fixed in this slice. (2) Loki+sonnet loses to raw sonnet mainly through no-PR outcomes (ALREADY_SATISFIED false positive, empty diff) and BLOCKED, not through slow runs. (3) Per D50 a slice that lowers lift is dropped; this baseline is the bar.
+
+Reproduce (per arm; a run-owned temp is created by run.sh; needs `cd loki-ts && bun install --frozen-lockfile` for the v10 arm):
+`LOKI_NO_BROWSER=1 LOKI_EVAL_MAX_LOAD=80 LOKI_EVAL_MODEL=<claude-haiku-4-5|claude-sonnet-5> eval/loki10/run.sh --arm <raw-claude|v10> --tasks aiq-52-searchbar,pub-click-2877,pub-click-3059,pub-click-3487,pub-click-3572,pub-humanize-152,pub-humanize-174,pub-humanize-333,pub-jsonschema-1389,pub-markupsafe-417 --parallel 1 --out ~/loki-ci-logs/d50-<arm>-<model>`
+Raw rows: ~/loki-ci-logs/d50-{raw-haiku,raw-sonnet,v10-haiku,v10-sonnet}/results.jsonl.