@orkastery/cli 0.5.6 → 0.6.0

package/assets/references-en/definition-of-done.md

@@ -0,0 +1,74 @@
+# Definition of Done
+
+The universal conditions a delivery meets before it is called done. It consolidates the gates
+the `ork` core already runs and invents no doctrine of its own. Items are numbered only once
+across the whole file, so that a reviewer writes a number and every human and every skill resolve to the
+same line. Cite an item as `DoD 4`.
+
+**Sources:** `core/src/phase.ts` (phase contract), `core/src/claims.ts`, `core/src/verify.ts`,
+`core/src/gates.ts`, `core/src/policies.ts`, `core/src/ship.ts`, `core/src/master.ts`,
+`core/src/worktree.ts`, `core/src/leases.ts`, `core/src/retry.ts`, `core/src/fix.ts`,
+`core/src/ratelimit.ts` (block B3: typed retry, GO-FIX/CHECK-REVERIFY and the rate limit queue).
+
+```mermaid
+flowchart LR
+    GOAL["GOAL<br/>DoD 17 e 18<br/>objetivo aprovado"] --> PLAN["PLAN<br/>DoD 19 e 20<br/>tradeoffs decididos"]
+    PLAN --> GO["GO<br/>DoD 1 a 5 por tarefa"]
+    GO --> CHECK["CHECK<br/>DoD 6 a 11<br/>gate da thread"]
+    CHECK --> SHIP["SHIP<br/>DoD 12 a 15<br/>gate do merge"]
+    SHIP --> MASTER["MASTER<br/>DoD 16<br/>gate de fechamento"]
+    CHECK -->|"correcao tipo B"| GO
+```
+
+## Every task, before GO calls it done
+
+| # | Check | How it is proven |
+|---|---|---|
+| 1 | One atomic commit per task, at most five files changed, with the thread and the task in the message (example: `ork-checkout T3: extrai o calculo de frete`). | `git log --oneline` and `git show --stat` on the thread branch. Above five files the task goes back to PLAN to be sliced. |
+| 2 | The task's verify declared in the PLAN was run and passed. | Run the command. A reported pass is not a pass: `ork verify <thread>` reruns it on the real HEAD. |
+| 3 | Anti-hallucination check: every file the runtime cited exists in the diff and every test it cited exists and passes. | Every statement becomes `ork claims add ... --verificar "<comando>"`, and `ork verify <thread>` reruns it. A mismatch comes out as typed reason `claims.failed`. |
+| 4 | Work inside the thread worktree, with the base stamped in `thread.json`, never in the main tree. | `ork worktree audit <thread>` checks against git itself and exits non-zero if they diverge. |
+| 5 | Every relevant delegated decision was recorded in the ledger with who decided, on what evidence and why. The qualifier carries weight: formatting and internal names are delegable too, and demanding an event for each of them is undue escalation, which the audit weighs the same as under-classification. | `ork phase list <thread>` over the thread's `ledger.jsonl`. |
+
+## Every thread, before the CHECK gate passes
+
+| # | Check | How it is proven |
+|---|---|---|
+| 6 | The full suite is green, including the manifest's `verify:` commands, and code health passes: typecheck, lint and coverage with a declared origin. | `ork verify <thread>`. Every number carries `runtime_reported`, `estimated` or `unavailable`; a gap is published as a gap, never as zero. |
+| 7 | The comparison is against the baseline recorded before GO, separating regression from pre-existing debt. | `ork verify <thread> --baseline` before GO and `ork verify <thread>` after it. A command that passed on the baseline and fails now comes out as `verify.regression`; what already failed before comes out as debt, not as the thread's fault. |
+| 8 | The five review axes (correctness, security, performance, maintainability, style) bring findings or an explicit "none", each categorized as blocker, warning or suggestion. | The five-axis table of the CHECK report, per [code-review-axes.md](code-review-axes.md). |
+| 9 | The security audit reports zero blockers, and the web performance audit either ran or states why the target has no web surface. | The report's audit sections, per [security-checklist.md](security-checklist.md) and [performance-checklist.md](performance-checklist.md). |
+| 10 | Fixes classified honestly: type A is one line or equivalent, recorded, with the affected checks rerun; type B sent the task back to GO, and this CHECK round is the full rerun. | `ork fix open <thread>` derives one fix per typed reason, with the exact spec and the command that judges it; `ork fix reverify <thread>` gives the verdict PER fix and REFUSES a partial rerun when there is a type B. The ledger's `go_fix_opened` and `check_reverify` events against the report's counts. These counts measure the quality of the PLAN and of the GO, not that of the reviewer. |
+| 11 | The report is in the thread directory with exactly one verdict (PASSOU = passed, PRECISA DE MUDANCA = needs changes, BLOQUEADO = blocked), every accepted warning has its record, and the gate was resolved through the right path. | The human answer to `ork gate request <thread>`, through the authenticated channel, for a human decision, or the mode's autonomous decision event, which only a PASSOU verdict allows. A verify failure, an anti-hallucination failure, any CHECK with a type B fix, an envelope deviation, a verdict other than PASSOU and an emergency always go up to the human, in any mode. |
+
+## Every merge, before SHIP closes
+
+| # | Check | How it is proven |
+|---|---|---|
+| 12 | Contract guard: nothing in the final diff changes a versioned public contract (telemetry schema, interface contract, state layout, event types) without a ratified class 2 decision. | `git diff <base>...HEAD` over those files and the id of the gate that ratified it, in the ledger. No ratification, no merge. |
+| 13 | The merge went through the serialized queue, updated against the latest base, fully revalidated whenever the update brought changes, with the `DoD 12` guard rerun against the final diff. | `ork ship <thread> --para <base>` takes the `main-tree` lease; the update can bring changes that touch a contract, so a verdict computed before it describes a diff that no longer exists. |
+| 14 | The push was proven by a command, not reported. | `ork ship` compares the local sha with `git ls-remote` on the remote and writes `pushVerificado` to the ledger. A reported push without the remote's sha counts as a push that did not happen. |
+| 15 | An irreversible step only happens with the mode's authorization: push, merge and deletion require the pause the #TAG provided for or a recorded advance authorization. | `ork ship <thread> --para <base> --autorizar-push <quem>`, or the human answer to the mode's pause, visible in `ork phase list <thread>`. |
+
+## Every closure, before the thread dies
+
+| # | Check | How it is proven |
+|---|---|---|
+| 16 | There is a MASTER log valid against the frozen contract `ork.master-log/v1`, with a typed POSTMORTEM, failure classes from the fixed catalog, an integer score from 0 to 5 and a non-empty justification. A delivery without a MASTER log did not happen. | `ork master <thread> --score N --justificativa "<texto>" --por <quem>`. The command refuses a score outside the scale, a score without a justification, a score without human authorship in `--por` and a class outside the catalog, and writes nothing when it refuses. |
+
+## Every thread, at its start
+
+| # | Check | How it is proven |
+|---|---|---|
+| 17 | The goal of the GOAL phase is verifiable: observable criteria (latency, coverage, behavior), never adjectives. In a fix request, reproducing the defect is a mandatory criterion. | The GOAL becomes claims with a verification command; a criterion that does not become a command is not a criterion. |
+| 18 | The assumptions are written down. An implicit assumption is the biggest source of rework and is treated as a process defect, not as cleverness. | The assumptions section of the GOAL and the claims that tie them down. |
+| 19 | The PLAN brings tasks with queryable `touch_paths` and one executable verify per task. | The thread's PLAN and the `path:<glob>` leases it justifies. |
+| 20 | Decisions D1..Dn have a single home and stay locked once decided; reopening is a new decision, with a record, never a silent edit. | The thread's ledger, where the decision appears with who decided and when. |
+
+## Recommendations (not a gate on this machine)
+
+- Test coverage as a number: this repository has no coverage tool installed, so
+  coverage is reported as `unavailable` instead of estimated.
+- Tool-based dependency audit: `npm audit` runs where a dependency is declared; the
+  `ork` core has only development dependencies, and this is stated in the report instead of becoming a
+  convenient zero.

package/assets/references-en/performance-checklist.md

@@ -0,0 +1,53 @@
+# Performance Checklist
+
+The conditional audit: it runs when the target has a surface that suffers from latency, and when it does
+not have one, it is waived by a written contract, never by oversight. Items are numbered only
+once across the whole file. Cite an item as `PERF 2`.
+
+**Sources:** [code-review-axes.md](code-review-axes.md) (axis 3),
+[definition-of-done.md](definition-of-done.md), `core/src/verify.ts`.
+
+```mermaid
+flowchart TB
+    Q{"o alvo tem superficie<br/>sensivel a latencia?"} -->|"nao"| D["dispensa registrada:<br/>PERF 1, com o motivo"]
+    Q -->|"sim"| M["PERF 2 a 6:<br/>medir antes de afirmar"]
+    M --> A["PERF 7 e 8:<br/>custo assintotico e recurso"]
+    A --> H["PERF 9 e 10:<br/>honestidade de medicao"]
+```
+
+## The waiver contract
+
+| # | Check | How it is proven |
+|---|---|---|
+| 1 | When the target has no web surface and no latency-sensitive path, the audit is waived with a line saying what the target is and why it has no such surface. A written waiver is a result; a missing audit with no line at all is a gap. | The performance section of the CHECK report, which always exists, even when its content is the waiver. |
+
+## Measure before asserting
+
+| # | Check | How it is proven |
+|---|---|---|
+| 2 | Every performance statement carries a number, a unit and how the number was obtained. "It got faster" without a measurement is opinion, and opinion does not pass a gate. | The report's measurement table, with the command that produced each number. |
+| 3 | There is a measurement before and after, on the same machine and under the same conditions. Comparing measurements from different machines compares machines, not code. | The two runs, with the machine and the conditions declared. |
+| 4 | The measurement was repeated enough to separate signal from noise, and the variation is stated. A single run becomes `estimated`, never `runtime_reported`. | The number of repetitions in the report. |
+| 5 | The measured path is the user's path, not the convenient microbenchmark. A gain in a function nobody calls on the hot path is a suggestion, not a result. | The stretch of the real flow that the measurement covers. |
+| 6 | A detected performance regression is categorized like any other finding: blocker, recorded warning or suggestion. | [code-review-axes.md](code-review-axes.md), categorization rule. |
+
+## Asymptotic cost and resources
+
+| # | Check | How it is proven |
+|---|---|---|
+| 7 | A loop over a collection that grows with use was examined, and the order of magnitude is stated. A quadratic hidden in small data is a defect with a date already set. | Reading the diff at the points that iterate over accumulated state. |
+| 8 | Repeated work inside a loop (file read, process call, parsing the same data) was pointed out, or it was stated that there is none. In `ork`, reading the whole ledger per event would be exactly this defect. | Reading the diff against the I/O points. |
+
+## Measurement honesty
+
+| # | Check | How it is proven |
+|---|---|---|
+| 9 | Every number carries its source: `runtime_reported`, `estimated` or `unavailable`. It is the same discipline as the `ork` token gate, which would rather say "not measurable" than invent a window occupancy. | The source attached to each number in the report. |
+| 10 | What was not measured shows up as `unavailable` with the reason, never as zero, never as a silent absence. A published gap is a gap; a hidden gap becomes a false number on the next reading. | The metrics section of the report. |
+
+## Recommendations (not a gate on this machine)
+
+- Browser profiling tool (Lighthouse, CPU traces): not installed here. A web performance audit
+  of a target with a web surface comes out `unavailable` with the reason while that is the case.
+- Continuous benchmarking with history: out of reach for this machine; the before-and-after comparison is
+  done in the thread itself, with an explicit `PERF 3`.

package/assets/references-en/security-checklist.md

@@ -0,0 +1,101 @@
+# Security Checklist
+
+The normative list that the CHECK security audit walks through, whose hard pass condition is
+zero blockers in the consolidated report. It elevates checks that already exist in the core and
+invents none. Items are numbered only once across the whole file. Cite an item as `SEC 5`.
+
+**Sources:** `core/src/policies.ts` (secret patterns and blocking policies),
+`core/src/doctor.ts`, `core/src/ship.ts`, `core/src/gates.ts`,
+`core/src/superficie.ts` (deterministic scan of the network attack surface,
+rules SP8..SP12 of the `security-privacy` pack),
+[definition-of-done.md](definition-of-done.md).
+
+```mermaid
+flowchart TB
+    E["escopo declarado:<br/>diff, historico, prompts, artefatos"] --> S1["SEC 1 a 4:<br/>segredo e credencial"]
+    S1 --> S2["SEC 5 a 8:<br/>entrada e superficie"]
+    S2 --> S3["SEC 9 e 10:<br/>dependencia e cadeia"]
+    S3 --> S4["SEC 11 a 14:<br/>artefatos do repositorio"]
+    S4 --> S5["SEC 15 a 17:<br/>conduta da auditoria"]
+    S5 --> S6["SEC 18 a 22:<br/>superficie de ataque de rede"]
+    S6 --> C{"algum bloqueador?"}
+    C -->|"sim"| B["veredito BLOQUEADO"]
+    C -->|"nao"| P["zero bloqueadores:<br/>condicao dura cumprida"]
+```
+
+## Secrets and credentials
+
+| # | Check | How it is proven |
+|---|---|---|
+| 1 | No secret in the working tree: token, API key, password, private key block, connection string and high-entropy string that looks like a credential, including `.env` files, test fixtures and example configs. | Reading of the branch diff plus a scan of the tree. The report names the tool used or says the pass was manual. With `verify.security_scan` declared, the evidence is the `security_scan` (Gitleaks on the tree); the manual pass is only valid with the scan declared `unavailable`. |
+| 2 | No secret in the history behind the branch. A secret committed and later deleted is still leaked. | `git log -p <base>..HEAD` over the whole range, not just the tree. Blocker until the credential is rotated and the history cleaned, with the rotation verified, not promised. With `verify.security_scan` declared, the `security_scan` also scans the commits of `<base>..HEAD`; the manual pass is only valid with the scan declared `unavailable`. |
+| 3 | No real credential in a dispatched prompt. The `phase.dispatch` gate of `ork` evaluates the `segredo_em_prompt` policy BEFORE writing the prompt to disk: a rejected prompt never comes to exist as a file, because writing a prompt with a credential creates a second leak inside the repository itself. | `ork phase run` exits with typed reason `policy.violation`; the ledger records the pattern name and the line, never the matched excerpt. |
+| 4 | No real credential in a thread artifact, the ledger, captured command output or the audit report itself. A leak report that prints the secret is a second leak. | Reading of the artifacts the thread produced. A redacted placeholder passes and is declared as such; a credential is referenced by location and redacted form. |
+
+## Input and surface
+
+| # | Check | How it is proven |
+|---|---|---|
+| 5 | Every input that crosses a trust boundary is validated on the trusting side, not on the calling side. Client-only validation counts as missing. | Reading of the diff at the touched entry points. |
+| 6 | No concatenation of input into SQL, shell, file path or rendered template. The `ork` core runs commands as an argument list, with no interpolated shell, and the same pattern applies to the reviewed code. | Reading of the diff; any command built by concatenation is a blocker. |
+| 7 | Authentication and authorization checked per operation, not per screen: whoever can read cannot always write, and either the test that proves this exists or the finding is a warning with a record. | Authorization tests in the suite, rerun by `ork verify`. |
+| 8 | Deserialization of untrusted data does not instantiate arbitrary types, and every `JSON.parse` of a state file has its error handled with the path in the error text. | Reading of the diff over the points that read state. |
+
+## Dependencies and supply chain
+
+| # | Check | How it is proven |
+|---|---|---|
+| 9 | No new dependency without justification in the PLAN. A dependency that comes in without a task is scope creep with an attack surface. | Diff of the package manifest files against the PLAN tasks. |
+| 10 | Known vulnerabilities in the declared dependencies were looked up, and the result is in the report with the date and the tool. Where there is no tool, the item comes out `unavailable` with the reason. | `npm audit` where a production dependency is declared. With `verify.security_scan` declared, the evidence is the `security_scan` (dependencies and govulncheck `reachable`); the manual pass is only valid with the scan declared `unavailable`. |
+
+## Repository artifacts
+
+| # | Check | How it is proven |
+|---|---|---|
+| 11 | No mass destructive command in a script, hook or documentation that someone will copy: `rm -rf` with an unanchored variable path, `git add -A`, `git checkout -- .`, `git reset --hard` without a target, `push --force`. | Scan of the touched directories. The `PreToolUse` guard of the Claude Code adapter blocks these same commands at run time. |
+| 12 | No direct push to the base branch. The manifest's `push_direto_na_base` policy is blocking and rejects any delivery whose source and target are the same branch. | `ork ship` exits with `policy.violation` before touching the remote. |
+| 13 | No dispatch through a paid provider when the policy is `subscription-only`. An environment variable that redirects `claude` to a paid provider is a blocker, because the cost shows up on the bill and not at the gate. | `ork doctor` and the `provider` policy, evaluated at the `phase.dispatch` gate and in `ship`. |
+| 14 | Permissions on a file created by a script do not widen access: no `chmod 777`, no state file with the execute bit. | Reading of the diff of the scripts and hooks. |
+
+## Audit conduct
+
+| # | Check | How it is proven |
+|---|---|---|
+| 15 | The audited scope is declared before the findings: which directories, which history range, which artifacts. An audit without a declared scope is not reproducible and does not count as evidence. | The header of the report's security section. |
+| 16 | Each finding comes out categorized as blocker, warning or suggestion, with the `SEC n` item it violates. A finding without an item number is opinion. | The report's findings table. |
+| 17 | Absence of findings is stated as the result of a check, with what was looked at. "Nothing found" without a scope is different from "audited and clean", and the difference is written down. | The section text, against `SEC 15`. |
+
+## Network attack surface
+
+What the product EXPOSES. Items 5 to 8 look at the data that comes in through a boundary; these look at
+the boundary itself: which routes and endpoints exist, who can call them and at what cost. The
+`security-privacy` pack audits this section with a DETERMINISTIC scan (`ork audit surface`, rules
+SP8 to SP12), which runs inside `ork audit run security-privacy` and writes each finding to the
+debt board with `arquivo:linha` evidence and the command that reruns it.
+
+| # | Check | How it is proven |
+|---|---|---|
+| 18 | Every HTTP/API server route declared in production goes through an authentication/authorization layer, or is public by a recorded decision (login, sign-up, health, signed webhook). A route that is public by oversight is a blocker. | `ork audit surface --regra SP8`. The finding brings the route definition with `arquivo:linha`, the recognized framework and the command that proves the absence of a guard in the route block or in the file. |
+| 19 | An administration or operations endpoint (admin, console, debug, swagger/openapi, detailed health, metrics, `pprof`, cluster metadata) is not reachable from outside: there is a network restriction (allowlist, internal network) or oAuth/basic auth. A health check that returns version, hostname, database or dependency is an operations endpoint, not a health one. | `ork audit surface --regra SP9`, plus the network configuration or the middleware cited with `arquivo:linha`. |
+| 20 | An exposed route has a rate limit per IP and per identity, with special attention to the authentication path, password recovery, OTP, search, export and any public route that changes state. Without a limit, a brute-force costs no more than a request. | `ork audit surface --regra SP10`. Limit, quota or rpm middleware cited on the route, on the router that mounts it or on the gateway, with the file and the line. |
+| 21 | CORS does not combine a global origin with credentials, and an open origin does not appear in a service that carries personal data or sessions. An explicit list of origins, always. | `ork audit surface --regra SP11`. The finding cites the configuration with `arquivo:linha`, the origin wildcard and the credentials flag, each with the command that reruns it. |
+| 22 | The route definition declares the payload schema at the edge (schema, validator, typed model), and an invalid payload is rejected before the handler. Complements item 5, which looks at the USE of the data inside the handler. | `ork audit surface --regra SP12`, with the route definition and the absence of a schema at the entry point. |
+
+A finding that the scan marks with confidence `baixa` (low: there is middleware that `ork` does not classify,
+an unrecognized framework, a marker present in the file and absent from the route block) comes out as a
+**warning that asks for human confirmation**, never as a blocker: the machine says where to look, and
+the person decides whether it holds.
+
+## Recommendations (not a gate on this machine)
+
+- Scanning with a dedicated secret tool (gitleaks, trufflehog): not installed here. The
+  patterns in `core/src/policies.ts` cover Anthropic keys, OpenAI keys, AWS access keys, GitHub
+  tokens, PEM private keys and secret assignments in text, and the audit says it covered those
+  classes and no others.
+- Software composition analysis and artifact signing: out of reach for this machine; it comes out
+  `unavailable` with the reason, never as a silent pass.
+- Dynamic surface testing (port scanning, endpoint fuzzing, DAST): out of reach.
+  The scan for items 18 to 22 is STATIC and reads the route definition in the code: it does not see
+  routes generated at run time, nor a proxy, gateway or WAF in front of the service. Where that
+  layer exists, the finding still stands as a question and is resolved with the layer's evidence, never
+  in silence.

package/assets/references-en/testing-patterns.md

@@ -0,0 +1,51 @@
+# Testing Patterns
+
+What a suite must prove and how a green suite is earned honestly. Items are numbered
+only once across the whole file. Cite an item as `TEST 3`.
+
+**Sources:** `core/src/verify.ts` (baseline and re-run), `core/src/claims.ts`,
+[definition-of-done.md](definition-of-done.md), [code-review-axes.md](code-review-axes.md).
+
+```mermaid
+flowchart LR
+    B["baseline gravada<br/>antes do GO"] --> G["GO: implementacao<br/>slice por slice"]
+    G --> R["reexecucao no HEAD real"]
+    R --> D{"comparacao contra a baseline"}
+    D -->|"passava e falha"| RG["regressao:<br/>TEST 1, gate verify.regression"]
+    D -->|"ja falhava"| DV["divida pre-existente:<br/>declarada, nao imputada a thread"]
+    D -->|"tudo verde"| OK["suite verde ganha"]
+```
+
+## What the suite proves
+
+| # | Check | How it is proven |
+|---|---|---|
+| 1 | There is a baseline recorded before GO. Without it, a failure cannot tell a regression from pre-existing debt, and the thread takes the blame for a defect that was already there or, worse, hides what it broke itself. | `ork verify <thread> --baseline` before GO. |
+| 2 | Every GOAL success criterion has a command that proves it. A criterion that does not become a command is not a criterion, it is an adjective. | The thread's claims, with `--verificar`. |
+| 3 | In a fix request, there is a test that reproduces the defect and that failed before the fix. A fix whose defect was never reproduced cannot prove it fixed anything. | The new test, run against the commit before the fix. |
+| 4 | The failure path has a test, not only the happy path. A suite that only exercises success measures optimism. | Reading the suite against the PLAN edge cases. |
+| 5 | A new test fails when the implementation is reverted. A test that passes with and without the change does not test the change. | Revert locally and run, or mutate the central line and confirm the failure. |
+
+## How the green suite is earned
+
+| # | Check | How it is proven |
+|---|---|---|
+| 6 | The suite runs on the real HEAD, in the thread's working directory. A pass reported by an agent is not a pass. | `ork verify <thread>` re-runs the manifest commands and the claims, and stamps the real commit. |
+| 7 | No test was disabled, marked to skip or loosened to close the delivery. Skipping a test is a recorded scope change, never a silent course correction. | Diff over the test files, looking for removed tests, `skip` and relaxed assertions. |
+| 8 | No assertion was swapped for the value the code produces today without someone saying why the right value changed. Adjusting the expected to the observed is the most common way to turn a defect into a contract. | Diff of the assertions against the intent declared in the PLAN. |
+| 9 | A test does not depend on the network, on a paid credential or on the wall clock. A deterministic fixture is the standard; whatever needs the outside world stays out of the gate and is declared. | Run the suite offline. In `ork`, the `ork eval` canaries build a temporary git repository and do not touch the network. |
+| 10 | A test does not depend on another test or on the execution order. State shared between cases is a defect, even when the suite is green today. | Run the suspect case in shuffled order or in isolation. |
+
+## Count and coverage
+
+| # | Check | How it is proven |
+|---|---|---|
+| 11 | The reported test count is the one the command printed, pasted from the real output. A suite number typed from memory is not evidence. | The runner output in the delivery report. |
+| 12 | Coverage is reported with its source: `runtime_reported` when the tool measured it, `estimated` when someone estimated it and said so, `unavailable` when there is no tool. A gap is published as a gap, never as zero. | The metrics section of the report. |
+
+## Recommendations (not a gate on this machine)
+
+- Tool-measured coverage: this repository has no such tool installed, so coverage comes out
+  `unavailable` per `TEST 12`, and is not estimated for convenience.
+- Mutation testing to prove `TEST 5` automatically: out of reach for this machine; the proof
+  here is manual and declared as manual.

package/assets/security-scan/defaults/.golangci.yml

@@ -0,0 +1,2 @@
+# golangci-lint default linters; project rules go in .ork-security/.golangci.yml
+version: "2"

package/assets/security-scan/defaults/eslint.config.mjs

@@ -0,0 +1,11 @@
+// Default quality config: typescript-eslint recommendedTypeChecked with the project's tsconfig (container cwd = repo root)
+import tseslint from 'typescript-eslint';
+
+export default tseslint.config(
+  { ignores: ['**/node_modules/**', '**/dist/**', '**/build/**', '**/coverage/**'] },
+  {
+    files: ['**/*.ts', '**/*.tsx', '**/*.mts', '**/*.cts'],
+    extends: [tseslint.configs.recommendedTypeChecked],
+    languageOptions: { parserOptions: { projectService: true, tsconfigRootDir: process.cwd() } },
+  },
+);

package/assets/security-scan/defaults/gitleaks.toml

@@ -0,0 +1,3 @@
+# Extends the gitleaks default ruleset; project rules go in .ork-security/gitleaks.toml
+[extend]
+useDefault = true

package/assets/security-scan/defaults/ruff.toml

@@ -0,0 +1 @@
+# Ruff default rules; project rules go in .ork-security/ruff.toml

package/assets/security-scan/tools-agil.json

@@ -0,0 +1,87 @@
+[
+  {
+    "name": "osv-scanner",
+    "category": "dependency",
+    "stacks": "all",
+    "image": "ghcr.io/google/osv-scanner@sha256:fca9be4446310094be881b63f6862879282647f121ad3326e91dd90afbf8ef50",
+    "version": "2.2.3",
+    "native": {
+      "bin": "osv-scanner",
+      "versionArgs": [
+        "--version"
+      ],
+      "versionPattern": "\\b2\\.2\\.\\d+\\b"
+    },
+    "network": "default",
+    "baseMode": "worktree",
+    "timeoutMs": 300000,
+    "severityMap": {
+      "CRITICAL": "critical",
+      "HIGH": "high",
+      "MODERATE": "medium",
+      "MEDIUM": "medium",
+      "LOW": "low"
+    },
+    "args": [
+      "sh",
+      "-c",
+      "bin=$(command -v osv-scanner || echo /osv-scanner); \"$bin\" scan source --recursive --format json --output \"$1\" \"$2\"; rc=$?; if [ $rc -eq 128 ]; then printf '{\"results\":[]}\\n' > \"$1\"; exit 0; fi; [ $rc -le 1 ] || exit $rc",
+      "sh",
+      "{out}/osv-scanner.json",
+      "{src}"
+    ],
+    "env": {
+      "HOME": "/tmp"
+    },
+    "expect": {
+      "files": [
+        "osv-scanner.json"
+      ],
+      "shape": "object",
+      "requireKey": [
+        "results"
+      ]
+    }
+  },
+  {
+    "name": "oxlint",
+    "category": "quality",
+    "stacks": [
+      "js"
+    ],
+    "image": "node@sha256:6f08a523443ddedf52941874c203475b0ad503e859ad70cb26ab8be9a517dbd5",
+    "version": "1.89.0",
+    "network": "default",
+    "baseMode": "worktree",
+    "timeoutMs": 300000,
+    "severityMap": {
+      "error": "medium",
+      "warning": "low"
+    },
+    "install": [
+      "oxlint@1.89.0"
+    ],
+    "args": [
+      "sh",
+      "-c",
+      "mkdir -p /tmp/ox && npm install --prefix /tmp/ox --ignore-scripts --no-audit --no-fund --no-save {install} >&2 && cd \"$2\" && /tmp/ox/node_modules/.bin/oxlint --format json . > /tmp/ox/saida.txt; rc=$?; [ $rc -le 1 ] || exit $rc; node -e 'const fs=require(\"fs\");const t=fs.readFileSync(\"/tmp/ox/saida.txt\",\"utf8\");const i=t.indexOf(\"{\");if(i<0)process.exit(3);const j=JSON.parse(t.slice(i));if(!Array.isArray(j.diagnostics))process.exit(3);fs.writeFileSync(process.argv[1],JSON.stringify(j))' \"$1\" || exit 3",
+      "sh",
+      "{out}/oxlint.json",
+      "{stackDir}"
+    ],
+    "env": {
+      "HOME": "/tmp",
+      "npm_config_cache": "/tmp/npm-cache",
+      "npm_config_update_notifier": "false"
+    },
+    "expect": {
+      "files": [
+        "oxlint.json"
+      ],
+      "shape": "object",
+      "requireKey": [
+        "diagnostics"
+      ]
+    }
+  }
+]