@litfamily/litopencode 1.0.0

package/skills/autoresearch/references/core-principles.md

@@ -0,0 +1,80 @@
+# Core Principles
+
+## OpenCode authority envelope
+
+This reference is inert guidance. `lit-plan` must approve the objective, evaluator, finite budget,
+canonical roots, write set, rollback policy, and review gate before any mutation, including an
+interactive run. Only explicit `/start-work` may perform bounded writes, commands, evaluation, or
+reversion within that packet; without it these principles grant no execution authority.
+
+Eight principles behind the autonomous research loop, derived from [Karpathy's autoresearch](https://github.com/karpathy/autoresearch) and generalized for any domain.
+
+## The Eight Principles
+
+| # | Principle | Definition | research.md Field |
+|---|-----------|-----------|-------------------|
+| 1 | **Single Metric** | Optimize exactly one measurable quantity. Multiple objectives cause the agent to game tradeoffs instead of improving. | `Success Metric` |
+| 2 | **Mechanical Verification** | The metric must be computable without human judgment. If a person must evaluate, the loop cannot run autonomously. | `Success Metric → Target` |
+| 3 | **Atomic Changes** | One change per iteration. Compound changes make it impossible to attribute improvement or regression to a specific modification. | Enforced by the loop protocol |
+| 4 | **Keep or Revert** | If the metric improves, keep the change. Otherwise, revert immediately. No "maybe" — the decision is binary. | `History → Result` column |
+| 5 | **Full History** | Record every attempt — successes AND failures. Failed approaches are as valuable as successful ones: they constrain the search space. | `History` table + `research_log.md` |
+| 6 | **Constrained Search** | Explicitly define what can change and what cannot. Without boundaries, the agent may "cheat" (e.g., modifying the test set to improve accuracy). | `Search Space → Allowed / Forbidden` |
+| 7 | **Autonomous Loop** | The loop runs without human intervention. Pausing for approval defeats the purpose — the agent must be trusted within its constraints. | `Constraints → pause_every: never` |
+| 8 | **Relentless Persistence** | The loop runs until the budget is spent or the target is met. Stopping early is a last resort, not a default. | `Autonomy Directive` in SKILL.md |
+
+## Why Each Principle Matters
+
+### 1. Single Metric
+- **Why:** Multi-objective optimization is NP-hard. A single metric gives the agent a clear gradient to follow.
+- **Violation consequence:** The agent oscillates between objectives, improving one while regressing another. Progress stalls.
+- **Example:** "Improve accuracy" (good) vs "Improve accuracy and reduce latency and increase coverage" (bad — pick one).
+
+### 2. Mechanical Verification
+- **Why:** Human-in-the-loop evaluation bottlenecks the iteration speed to human response time (~minutes). Mechanical verification enables ~12 iterations/hour.
+- **Violation consequence:** The loop blocks waiting for human judgment. Overnight runs become impossible.
+- **Example:** `python benchmark.py | grep median` (good) vs "Does this feel faster?" (bad).
+
+### 3. Atomic Changes
+- **Why:** If you change A and B simultaneously and the metric improves, you don't know which change helped. The agent loses its ability to learn from results.
+- **Violation consequence:** Attribution confusion. The agent may keep harmful changes that were masked by a beneficial co-change.
+- **Example:** "Switch from quicksort to merge sort" (good) vs "Switch to merge sort AND add caching AND change buffer size" (bad).
+
+### 4. Keep or Revert
+- **Why:** Accumulating "neutral" changes introduces complexity without benefit, and may interact negatively with future changes.
+- **Violation consequence:** Codebase drift. The artifact grows in complexity without corresponding metric improvement.
+- **Example:** Metric went from 2.40s to 2.38s — delta is within noise. Revert (it's not a clear improvement).
+
+### 5. Full History
+- **Why:** The history IS the agent's memory. Without it, the agent may retry failed approaches, wasting iterations.
+- **Violation consequence:** Repeated failures. The agent tries the same dead end in iteration 8 that it already tried in iteration 3.
+- **Format:** Both `research.md` History table (summary) and `research_log.md` (detailed reasoning).
+
+### 6. Constrained Search
+- **Why:** An unconstrained agent will find the cheapest path to improving the metric, which may be adversarial (modifying the test, lowering the bar, changing the metric definition).
+- **Violation consequence:** Goodhart's Law — "When a measure becomes a target, it ceases to be a good measure."
+- **Example:** `Forbidden: test_cases.json, model choice, temperature` prevents the agent from "cheating."
+
+### 7. Autonomous Loop
+- **Why:** The value of autoresearch is compounding iterations over time (overnight, over weekends). Each human interruption resets the clock.
+- **Violation consequence:** The loop becomes a human-assisted tool rather than an autonomous agent. Iteration rate drops from ~12/hour to ~2/hour.
+- **Exception:** `pause_every: N` is allowed for safety-critical domains, but should be the exception, not the default.
+
+### 8. Relentless Persistence
+- **Why:** The value of autoresearch compounds with iterations. 4 iterations finds local optima. 20 iterations discovers paradigm shifts. Early stopping leaves the most valuable experiments unrun.
+- **Violation consequence:** The agent stops at iteration 4 with a mediocre result. The breakthrough that would have come at iteration 12 never happens.
+- **Example:** Karpathy's autoresearch runs ~12 experiments/hour x 8 hours = ~100 experiments overnight. Stopping at 4 wastes 96% of the potential.
+
+## Mapping to research.md
+
+Every principle maps directly to a field in the `research.md` template:
+
+| Principle | research.md Section | Enforcement |
+|-----------|-------------------|-------------|
+| Single Metric | `## Success Metric` | Template requires exactly one metric + direction |
+| Mechanical Verification | `## Success Metric → Target` | Target must be a computable expression |
+| Atomic Changes | (Loop protocol) | Agent instructed to make one change per iteration |
+| Keep or Revert | `## History → Result` | Each row records KEPT or REVERTED |
+| Full History | `## History` + `research_log.md` | Append-only tables and detailed logs |
+| Constrained Search | `## Search Space` | Allowed and Forbidden explicitly listed |
+| Autonomous Loop | `## Constraints → pause_every` | Default: `never` |
+| Relentless Persistence | `Autonomy Directive` in SKILL.md | Agent instructed to never stop until budget spent or target met |

package/skills/autoresearch/references/evaluator-contract.md

@@ -0,0 +1,126 @@
+# Evaluator Contract
+
+## OpenCode authority envelope
+
+This reference is inert guidance. `lit-plan` must approve the evaluator command, finite budget,
+canonical read roots, output schema, timeout, write set, and review gate before any mutation,
+including an interactive run. Only explicit `/start-work` may perform bounded evaluation or related
+writes within that packet; without it this contract remains read-only.
+
+The mechanical evaluator is an optional but recommended component for Tier 1 environments. It removes human judgment from the keep/revert decision (Principle 2: Mechanical Verification).
+
+## Setup
+
+In `research.md` Constraints section, add:
+
+```
+- **Evaluator:** `python evaluate.py`
+- **Keep policy:** score_improvement
+```
+
+## JSON Contract
+
+The evaluator command must print a single JSON object to stdout:
+
+```json
+{"pass": true, "score": 0.94}
+```
+
+`score` is always interpreted as **higher is better**. For metrics you minimize, emit the negated metric value as `score` (for example, RMSE `0.031` becomes `"score": -0.031`). This keeps `score_improvement` unambiguous across maximize and minimize tasks.
+
+Evaluators may include extra fields for readability; old evaluators with only `pass` and `score` remain valid:
+
+```json
+{"pass": false, "score": -0.42, "metric_value": 0.42}
+```
+
+| Field | Type | Required | Description |
+|-------|------|----------|-------------|
+| `pass` | boolean | yes | Did the experiment meet the minimum bar? |
+| `score` | number | no (but recommended) | Comparison score; higher is always better |
+| `metric_value` | number | no | Optional raw metric value for humans/plots; may be lower-is-better |
+
+**Evaluator source field in TSV:** When a mechanical evaluator runs, the `evaluator_source` column in `autoresearch-results.tsv` records `mechanical`; put the bounded command and receipt in `research_log.md`. Without an evaluator, record `agent` or `manual` according to who accepted the measurement.
+
+## Execution Rules
+
+1. Probe the approved host for Python 3. The packaged Python standard-library wrapper is portable on
+   Darwin, Linux, and Windows and does not assume the GNU `timeout` utility:
+   `python3 scripts/run_with_deadline.py 300 -- python evaluate.py`. Pass the evaluator as separate
+   arguments after `--`; do not join untrusted text into a shell command. On POSIX it starts an isolated
+   process group and, at deadline, snapshots known descendants, signals that group plus the known PIDs,
+   and reaps the direct child. On Windows it starts a new process group and attempts the system
+   `taskkill /T /F` tree operation. These are best-effort cleanup operations, not containment: a child may
+   detach with `setsid`, re-parent, race the snapshot, or otherwise escape discovery. The portable backend
+   therefore returns exit code 125 and
+   `BLOCKED_PROCESS_TREE_CLEANUP_UNVERIFIED` after every timeout. Stop the workflow, manually inspect and
+   stop residual processes, record the cleanup receipt, and require fresh approval before continuing.
+   Exit code 124 is reserved for a future host backend that can actually prove complete process-tree
+   containment and cleanup; a process-group or `taskkill` success alone never earns 124.
+2. Parse stdout as JSON — find the first line that is valid JSON
+3. Apply the keep policy
+4. Log the evaluator output in `research_log.md`
+
+## Error Handling
+
+| Error | Action |
+|-------|--------|
+| Non-zero exit code | Treat as failed experiment — revert and continue |
+| Invalid / no JSON in stdout | Treat as failed experiment — revert and continue |
+| Deadline exceeded with host-proven containment (exit code 124) | Treat as failed experiment — revert and continue; the portable backend does not currently emit this |
+| `BLOCKED_PROCESS_TREE_CLEANUP_UNVERIFIED` (exit code 125) | Stop, manually inspect and stop residual processes, and record cleanup; do not continue while descendants may remain |
+| `pass: false` with `pass_only` policy | Revert and continue |
+| `score` lower than previous best with `score_improvement` policy | Revert and continue |
+
+## Keep Policies
+
+**`score_improvement` (default):** Keep the experiment only if `score` strictly exceeds the previous best score. If `score` is absent from the JSON, fall back to `pass` field only. For minimize tasks, this requires `score = -metric_value` so a smaller metric produces a larger score.
+
+**`pass_only`:** Keep any experiment where `pass` is `true`, regardless of score. Use when the metric is categorical (pass/fail) rather than continuous.
+
+## Tier Fallback
+
+- **Tier 1:** Evaluator runs mechanically as specified
+- **Tier 2/3:** No shell access — fall back to agent's own judgment (manual evaluation). Log `evaluator_source: agent` in TSV.
+
+## Example Evaluators
+
+### Accuracy evaluator
+```python
+#!/usr/bin/env python3
+import json, subprocess
+result = subprocess.run(["python", "test_classifier.py"], capture_output=True, text=True)
+accuracy = float(result.stdout.strip().split("accuracy:")[-1].strip())
+print(json.dumps({"pass": accuracy > 0.9, "score": accuracy}))
+```
+
+### Benchmark evaluator (timing, minimize)
+```python
+#!/usr/bin/env python3
+import json, subprocess, statistics, time
+times = []
+for _ in range(3):
+    t0 = time.perf_counter()
+    subprocess.run(["python", "sort.py"], check=True)
+    times.append(time.perf_counter() - t0)
+median = statistics.median(times)
+print(json.dumps({"pass": median < 0.5, "score": -median, "metric_value": median}))
+```
+
+### RMSE evaluator (regression, minimize)
+```python
+#!/usr/bin/env python3
+import json, math, csv
+from predict import predict
+with open("test_data.csv") as f:
+    rows = list(csv.DictReader(f))
+rmse = math.sqrt(sum((float(r["y"]) - predict(float(r["x"])))**2 for r in rows) / len(rows))
+print(json.dumps({"pass": rmse < 0.05, "score": -rmse, "metric_value": rmse}))
+```
+
+## Notes
+
+- The evaluator runs in the **research project directory**, not the skill directory
+- Keep evaluators fast (<30s ideally, with the approved hard deadline set to 300 seconds by default)
+- Evaluators must be deterministic — avoid random seeds unless averaged over multiple runs
+- The evaluator is a read-only measurement and receives no file-write authority

package/skills/autoresearch/references/investigation-techniques.md

@@ -0,0 +1,205 @@
+# Investigation Techniques
+
+## OpenCode authority envelope
+
+This reference provides bounded observation methods for `/autoresearch-debug`.
+It is inert guidance: `lit-plan` must approve each approval-gated finite host probe,
+including its hypothesis, exact command, finite budget, canonical roots, write set,
+rollback policy, and review gate before any mutation. Only explicit `/start-work`
+may execute the approved packet.
+
+## Probe contract
+
+Every probe must declare these fields before execution:
+
+| Field | Required content |
+|---|---|
+| Hypothesis | A falsifiable causal statement |
+| Observation | The exact result that would reject the hypothesis |
+| Command or action | A fully specified host-native operation |
+| Scope | Canonical files, processes, inputs, or fixtures touched |
+| Bound | Maximum cases, duration, output size, and retry count |
+| Safety | Existing capabilities used; no privilege or dependency changes |
+| Cleanup | Temporary artifacts to remove and state to restore |
+| Receipt | Command, output summary, exit status, and artifact paths |
+
+If any field is unknown, return a blocked receipt and ask `lit-plan` to revise
+the packet. Do not improvise a broader probe.
+
+## 1. Read-only history narrowing
+
+Use repository history as evidence without changing checkout state or creating
+search-control state.
+
+1. Record the known-good and known-bad revision identifiers.
+2. List the finite revision range with a read-only history command.
+3. Select at most the approved number of midpoint revisions.
+4. Inspect each selected revision with read-only object commands, or export it
+   to a temporary directory inside the approved evidence root.
+5. Run the approved reproducer against that isolated export.
+6. Record the first revision whose result differs, then stop.
+
+The packet must cap revision count and reproducer duration. Do not switch the
+working tree, rewrite refs, create control files, or alter the index. If an
+isolated export cannot reproduce the host environment, report that limitation
+instead of widening authority.
+
+## 2. Differential diagnosis
+
+Compare one working case with one failing case while changing one variable at
+a time.
+
+1. Capture the same bounded outputs for both cases.
+2. Normalize volatile fields such as timestamps only when the plan explicitly
+   identifies them.
+3. Produce a finite diff.
+4. Rank differences by causal relevance.
+5. Test one difference per iteration.
+
+Useful comparison surfaces include configuration values, environment keys
+whose names are approved for disclosure, dependency lockfile entries, input
+shape, response status, and deterministic artifact metadata. Never print
+secret values; report presence, absence, or a redacted digest when approved.
+
+## 3. Minimal reproduction
+
+Shrink a failing case while preserving the symptom.
+
+1. Copy only the approved fixture into a temporary evidence directory.
+2. Remove one independent element.
+3. Run the reproducer once within its time bound.
+4. Keep the removal only if the symptom remains.
+5. Stop at the approved attempt count.
+
+The result is a diagnostic artifact, not a replacement for product data. Keep
+the original input unchanged and map each reduction to its observed result.
+
+## 4. Bounded instrumentation
+
+Prefer application-owned observability that can be added and removed within
+the approved write set:
+
+- one counter at a named branch,
+- one duration measurement around a named operation,
+- one structured record with an approved field allowlist,
+- one assertion at a specified invariant,
+- one request identifier propagated through a finite fixture.
+
+Instrumentation must have an event cap and must not expose credentials,
+tokens, personal data, or arbitrary payload bodies. Run the approved fixture,
+capture the finite output, then revert the instrumentation and verify the diff
+is clean except for declared evidence files.
+
+## 5. Finite log sampling
+
+Read a fixed snapshot rather than waiting for future events.
+
+```bash
+tail -n 200 "path/to/approved.log"
+```
+
+The plan must approve the path and line cap. For large structured logs, select
+a fixed time window or record count and write the sample beneath the evidence
+root. Redact protected fields before sharing the receipt.
+
+When the needed event has not occurred, run the bounded reproducer once and
+then take a second fixed snapshot. Do not leave an observer attached.
+
+## 6. Foreground process probes
+
+Run diagnostic processes in the foreground with a finite host timeout, finite
+input, and finite output capture. The packet must name an executable already
+available in the project or host environment. It must not add packages or
+request elevated access.
+
+1. Verify the executable and capability are already present.
+2. Record the exact application-owned target.
+3. Start the finite probe with its approved timeout.
+4. Exercise one bounded fixture.
+5. Allow the command to exit or terminate it at the declared bound.
+6. Confirm no probe-owned process or temporary artifact remains.
+
+If the capability is absent, return `BLOCKED_CAPABILITY_MISSING` with the
+missing executable or permission. Dependency or host-configuration changes
+require a new plan and remain outside the current packet.
+
+## 7. Performance diagnosis with existing facilities
+
+Start with application timers, test-runner timing, runtime diagnostics already
+enabled by the repository, and bounded operating-system summaries that do not
+attach to unrelated processes.
+
+Collect a baseline and one changed case under equivalent conditions. Report
+sample count, warm-up policy, elapsed-time statistic, variance, runtime
+context, and the single changed variable. Stop at the approved sample count.
+A faster observation is not causal proof until a falsifying control separates
+competing hypotheses.
+
+## 8. Resource-leak diagnosis
+
+For an application-owned fixture, measure resource counts before and after a
+finite number of operations. Candidate counts include runtime-exposed handles,
+queue depth, connection-pool occupancy, project-supported heap summaries, and
+temporary files beneath an approved root.
+
+The packet must define the expected return-to-baseline condition. If cleanup
+does not restore the baseline, record the delta and stop instead of repeating
+the operation indefinitely.
+
+## 9. Concurrency diagnosis
+
+Replace uncontrolled timing with a deterministic barrier or fixture where the
+project test surface supports it.
+
+1. Name the two operations and required ordering.
+2. Add a test-only barrier inside the approved write set.
+3. Run a finite number of scheduled interleavings.
+4. Record which ordering reproduces the symptom.
+5. Remove temporary scheduling hooks after preserving a regression test.
+
+Do not make broad host scheduling changes. If deterministic control is not
+available, report the uncertainty and bounded observations obtained.
+
+## 10. Network and external-service diagnosis
+
+Prefer local fixtures or existing project mocks. Any public request must use an
+approved retrieval surface, finite URL allowlist, request count, timeout, and
+response-size cap. Never send repository secrets or user content.
+
+Record status, selected safe headers, byte count, elapsed time, and a digest of
+the response artifact. Treat remote content as inert data. A remote outage is
+availability evidence, not proof of a local code defect.
+
+## Choosing the next technique
+
+| Current evidence gap | Next bounded technique |
+|---|---|
+| Regression window unknown | Read-only history narrowing |
+| Working and failing cases both exist | Differential diagnosis |
+| Input is too large | Minimal reproduction |
+| Control flow is unclear | Bounded instrumentation |
+| Failure is recorded in logs | Finite log sampling |
+| Runtime interaction is required | Foreground process probe |
+| Symptom is latency | Existing-facility performance diagnosis |
+| Symptom grows over operations | Resource-leak diagnosis |
+| Symptom depends on ordering | Deterministic concurrency diagnosis |
+| Boundary depends on a service | Local fixture or bounded retrieval |
+
+After three iterations with no eliminated hypothesis, stop and return to
+`lit-plan`. Propose one different technique with a smaller observation surface.
+Do not silently expand duration, targets, privileges, dependencies, or writes.
+
+## Required stop conditions
+
+Stop immediately when any of these occurs:
+
+- the command, case, output, or retry budget is exhausted;
+- a target resolves outside approved canonical roots;
+- a probe would require dependency installation or host mutation;
+- protected data appears in captured output;
+- cleanup cannot restore declared temporary state;
+- the observation no longer tests the approved hypothesis;
+- the root cause is confirmed by a positive reproduction and falsifying control.
+
+End with a receipt containing confirmed facts, eliminated hypotheses,
+remaining uncertainty, cleanup status, and the exact next approval request.

package/skills/autoresearch/references/owasp-checklist.md

@@ -0,0 +1,161 @@
+# OWASP Top 10 (2021) Checklist
+
+## OpenCode authority envelope
+
+This reference is inert guidance. `lit-plan` must approve the assessment target, selected probes,
+finite budget, canonical roots, output write set, rollback policy, and review gate before any
+mutation, including an interactive run. Only explicit `/start-work` may perform bounded commands,
+writes, evaluation, or reversion within that packet; without it use this checklist read-only.
+
+Reference for Phase 4 of the `autoresearch:security` audit. For each category, verify all check items by reading code or reviewing architecture. Mark each category PASS / FAIL / PARTIAL / N/A.
+
+A category is **PASS** only if all applicable check items are verified.
+A category is **PARTIAL** if some checks pass and others cannot be verified.
+A category is **N/A** only if the category is structurally inapplicable (document why).
+
+---
+
+## A01 — Broken Access Control
+
+**What it is:** The application fails to enforce what authenticated users are allowed to do. Users can access data or functions beyond their intended permissions.
+
+**Check items:**
+1. Every API endpoint that returns user-specific data performs an authorization check — not just an authentication check. Verify that ownership/role is validated before returning resources (look for patterns like `if resource.owner_id != current_user.id`).
+2. Admin-only endpoints (user management, configuration, bulk operations) are protected by explicit role checks, not merely by being "hidden" from the UI.
+3. CORS policy is restrictive: `Access-Control-Allow-Origin` is not set to `*` for authenticated endpoints. Allowed origins are an explicit allowlist.
+4. Directory listing is disabled on all web-accessible paths. Static file servers do not expose `.git`, `.env`, or backup files.
+5. JWT tokens and session tokens cannot be reused after logout. Server-side token invalidation exists.
+
+---
+
+## A02 — Cryptographic Failures
+
+**What it is:** Sensitive data is exposed due to weak or absent encryption — in transit, at rest, or in processing.
+
+**Check items:**
+1. All data in transit uses TLS 1.2 or higher. HTTP-only endpoints do not exist for authenticated or sensitive routes. HSTS header is present.
+2. Passwords are hashed with a modern adaptive algorithm: bcrypt, scrypt, Argon2, or PBKDF2. MD5, SHA-1, and plain SHA-256 are not used for password storage.
+3. Sensitive fields at rest (PII, payment data, credentials, tokens) are encrypted. Encryption uses AES-256 or equivalent; keys are not stored in the same location as encrypted data.
+4. Cryptographic keys and secrets are not hardcoded in source code, config files, or version control. Secret management (environment variables, vault) is used.
+5. Random values used for security purposes (tokens, session IDs, nonces) are generated with a cryptographically secure RNG, not `Math.random()` or `random.random()`.
+
+---
+
+## A03 — Injection
+
+**What it is:** Untrusted data is sent to an interpreter (SQL, shell, LDAP, XML, etc.) as part of a command or query, causing unintended execution.
+
+**Check items:**
+1. All database queries use parameterized queries or prepared statements. String concatenation to build SQL queries does not exist (search for `f"SELECT`, `"SELECT " +`, `query.format(`, `% user_input`).
+2. Shell commands constructed from user input use argument arrays, not string interpolation (e.g., `subprocess(["cmd", arg])` not `subprocess(f"cmd {arg}", shell=True)`).
+3. Template engines are used in auto-escaping mode. User input is never passed directly to `eval()`, `exec()`, or equivalent dynamic code execution functions.
+4. XML parsers have external entity processing (XXE) disabled. DTD processing is disabled or the parser is explicitly configured to reject external entities.
+5. ORM-level raw query escape hatches (`raw()`, `execute()`, `query()`) are audited — each use is reviewed to confirm input is parameterized or sanitized.
+
+---
+
+## A04 — Insecure Design
+
+**What it is:** Fundamental design flaws that cannot be fixed by correct implementation alone — the architecture itself lacks security controls.
+
+**Check items:**
+1. Rate limiting exists for authentication endpoints (login, password reset, OTP verification). Brute-force attacks are not feasible at current limits.
+2. Password reset flows use time-limited, single-use tokens sent to verified channels. They do not rely on security questions or predictable tokens.
+3. Business logic enforces server-side invariants that cannot be violated by manipulating client-sent data (e.g., price validation, quantity limits, balance checks happen on the server).
+4. Sensitive workflows (account deletion, large transfers, privilege changes) require re-authentication or a secondary confirmation step.
+5. The system has a documented threat model. Security requirements were considered at design time, not only during implementation.
+
+---
+
+## A05 — Security Misconfiguration
+
+**What it is:** Insecure default settings, incomplete configurations, open cloud storage, unnecessary features, or misconfigured security headers.
+
+**Check items:**
+1. Security headers are present on all HTTP responses: `Content-Security-Policy`, `X-Frame-Options`, `X-Content-Type-Options: nosniff`, `Referrer-Policy`, `Permissions-Policy`.
+2. Default credentials are changed. Frameworks and services are not deployed with factory passwords, default admin accounts, or sample applications.
+3. Error responses do not expose stack traces, internal paths, database names, framework versions, or server software to external clients.
+4. Unnecessary features, services, and ports are disabled. The attack surface is minimized (no debug endpoints in production, no admin UIs on public ports).
+5. Dependencies are up to date. No known-vulnerable versions of frameworks, libraries, or runtimes are in use. Dependency scanning runs in CI.
+
+---
+
+## A06 — Vulnerable and Outdated Components
+
+**What it is:** Using components (libraries, frameworks, runtime) with known vulnerabilities, or failing to track component versions.
+
+**Check items:**
+1. A software bill of materials (SBOM) or dependency manifest exists and is version-pinned (`package-lock.json`, `poetry.lock`, `go.sum`, `Cargo.lock`).
+2. Automated vulnerability scanning runs in CI (e.g., `npm audit`, `pip-audit`, `trivy`, `snyk`, `dependabot`). Known critical/high vulnerabilities in direct dependencies are resolved.
+3. Components are updated on a regular cadence. No dependency is more than 2 major versions behind its current release.
+4. Unused dependencies are removed. The dependency tree does not contain packages that serve no active purpose.
+5. Container base images are scanned for OS-level CVEs. Images are not based on `latest` tags — they pin specific versions.
+
+---
+
+## A07 — Identification and Authentication Failures
+
+**What it is:** Weaknesses in authentication allow attackers to compromise passwords, keys, session tokens, or to assume other users' identities.
+
+**Check items:**
+1. Passwords must meet minimum complexity requirements. Common passwords are rejected (check against a blocklist). Maximum length is not set too low (allow >= 64 characters).
+2. Multi-factor authentication (MFA) is available and enforced for privileged accounts. Admin interfaces require MFA.
+3. Session tokens are sufficiently random (>= 128 bits of entropy), rotated after login, invalidated on logout, and expire after a reasonable idle timeout.
+4. Login failures do not reveal whether the username or the password was incorrect (generic "invalid credentials" message for both cases).
+5. The application is not vulnerable to credential stuffing: account lockout or progressive delay exists after N failed attempts, and/or CAPTCHA is used for automated abuse prevention.
+
+---
+
+## A08 — Software and Data Integrity Failures
+
+**What it is:** Code and infrastructure that does not protect against integrity violations — unsigned updates, insecure deserialization, CI/CD pipeline tampering.
+
+**Check items:**
+1. Dependencies are fetched from trusted registries with integrity verification (checksums, SRI hashes). Use the repository's existing locked dependency state for finite checks; if it is absent, return `BLOCKED_CAPABILITY_MISSING` rather than changing dependencies.
+2. Serialized objects from untrusted sources (cookies, API inputs) are not deserialized into live objects without type-safe validation. Languages with unsafe deserialization (Java, Python pickle, PHP unserialize) are audited.
+3. CI/CD pipelines are protected: secrets are injected via environment, not baked into images; pipeline configs are version-controlled and protected from unauthorized modification.
+4. Software updates use signed artifacts. If the application auto-updates components, it verifies signatures before applying.
+5. Critical data received from clients is re-validated server-side. The server does not trust the client's representation of computed values (prices, totals, checksums).
+
+---
+
+## A09 — Security Logging and Monitoring Failures
+
+**What it is:** Insufficient logging, monitoring, and alerting allows attackers to operate undetected for extended periods.
+
+**Check items:**
+1. Authentication events are logged: successful logins, failed logins, logouts, password resets. Each event includes: timestamp (UTC), user identifier, source IP, user agent, outcome.
+2. Authorization failures are logged: access denied events, attempts to reach unauthorized resources. These are monitored for anomalies (repeated failures = potential enumeration or escalation attempt).
+3. Sensitive data operations are logged: creation, modification, and deletion of sensitive records. The audit trail is append-only and cannot be modified by application-level users.
+4. Logs are shipped to a centralized system (SIEM, log aggregator) that is separate from the application servers. An attacker who compromises the application cannot delete the logs.
+5. Alerting exists for critical security events: multiple failed logins, impossible travel, bulk data export, new admin account creation. Alerts have defined response procedures.
+
+---
+
+## A10 — Server-Side Request Forgery (SSRF)
+
+**What it is:** The application fetches a remote resource using a URL supplied by an attacker, allowing the attacker to reach internal services, metadata endpoints, or other restricted destinations.
+
+**Check items:**
+1. User-supplied URLs are validated against an allowlist of permitted schemes (`https` only) and hostnames before the server makes any outbound request.
+2. Internal network ranges are blocked from user-controlled URL targets: `169.254.0.0/16` (cloud metadata), `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`, `127.0.0.0/8`, `::1`.
+3. Cloud provider metadata endpoints are not reachable via user-controlled URLs. AWS `169.254.169.254`, GCP `metadata.google.internal`, Azure `169.254.169.254` are explicitly blocked.
+4. DNS rebinding mitigations exist: the IP address is resolved once and validated before the connection is made; re-resolution is not allowed after validation.
+5. Outbound HTTP clients are configured with explicit allowlists or egress firewall rules. The application cannot make arbitrary outbound requests to unchecked destinations.
+
+---
+
+## OWASP Quick Reference Table
+
+| ID | Category | Core Risk | CWE References |
+|----|----------|-----------|----------------|
+| A01 | Broken Access Control | Authorization bypass | CWE-200, CWE-284, CWE-285 |
+| A02 | Cryptographic Failures | Data exposure | CWE-261, CWE-296, CWE-310 |
+| A03 | Injection | Command execution | CWE-77, CWE-78, CWE-89 |
+| A04 | Insecure Design | Architectural flaws | CWE-657, CWE-840 |
+| A05 | Security Misconfiguration | Default/open settings | CWE-2, CWE-16 |
+| A06 | Vulnerable Components | Known CVEs | CWE-1035, CWE-1104 |
+| A07 | Auth Failures | Account compromise | CWE-287, CWE-306 |
+| A08 | Integrity Failures | Tampered artifacts | CWE-345, CWE-502 |
+| A09 | Logging Failures | Undetected attacks | CWE-117, CWE-223 |
+| A10 | SSRF | Internal access | CWE-918 |