@azure-id/orc 1.6.0 → 1.7.0

package/templates/skills/_shared/phases/rules.md

@@ -0,0 +1,154 @@
+# Phase — Rules   (id: `rules`)
+
+> **Library file.** New at v1.7.0 W5. Layers declared: `core` only — single-layer
+> for the same reason `house-rules.md` is: it is a standing card injected
+> VERBATIM into a slice, and a layered card would be a different card. What
+> varies between lanes is DATA (which packs, whether a task is front-end), not
+> prose. `orc lane phases <lane> --json` names the file and the layers to read.
+>
+> **What is NOT here:** the rules. They are `../rules/` — four packs, read-only,
+> shipped. This file is the SHAPE: who assembles the card, where it sits in a
+> slice, what comes back, and what the phase must never do.
+>
+> **`/orc-doc` does not run this phase.** That lane has its own ledger
+> (`orc doc rules`) and its own frozen-per-document mechanic. Excluded means
+> excluded, and `orc rules slice --lane orc-doc` refuses by name.
+
+<!-- orc:layer core -->
+
+## One assembler, and it is not you
+
+```
+orc rules slice --lane <lane> [--pack ui] [--json]
+```
+
+That command is the **only** thing that builds this card. A lane never
+concatenates the packs itself, never re-orders them, never summarises a rule and
+never drops one it judges irrelevant.
+
+Two reasons, and both have cost this repo money elsewhere:
+
+1. **Drift.** A card assembled in twenty-eight spines is twenty-eight ideas of
+   the precedence order. The same argument as `orc lane phases`: *a second idea
+   of the pipeline is the drift this exists to make impossible.*
+2. **Cost.** This card rides on **every spawn**. One assembler is the only place
+   its token weight can be measured, and therefore the only place it can be cut.
+
+Print the command's `line` VERBATIM at preflight. Never compute it:
+
+```
+rules:    ORC 65 (W 23 · C 22 · D 10 · U 10) · yours 9 lines (P0 4 · P1 2 · P2 3) · 1 override
+rules:    ORC 65 (W 23 · C 22 · D 10 · U 10) · yours none
+```
+
+**Both spellings are mandatory in their state.** `yours none` is an ANSWER — it
+says the project has not written its own rules, which is a different fact from
+the CLI failing to look.
+
+## Where it sits in a slice — the order IS the contract
+
+```
+1  HOUSE RULES              ./house-rules.md, injected verbatim
+2  YOUR PROJECT'S RULES     from the slice, P0 then P1 then P2, verbatim
+3  ORC RULES                from the slice, the packs this lane carries
+4  the task                 the lane's own dispatch contract
+```
+
+Nothing goes above 1. Nothing goes between 2 and 3. The assembler emits 2 and 3
+as one block in that order, so the lane's job is to place that block directly
+under the house card and before the task.
+
+## Precedence, and the one sentence that gets it wrong
+
+```
+house rules  >  your rules  >  ORC rules
+```
+
+**The house card is CODE and BEHAVIOUR only.** It governs how a change is made:
+surgical, simple, honest, in-slice. It says nothing about the words an agent
+writes, so it never overrules a writing rule — *it does not speak about prose at
+all.* A lane that presents the house card as beating `OSW-*` has misread it.
+
+**A project rule beats an ORC rule outright.** Not a waiver and not a
+negotiation: the ORC rule is removed from the slice, and the removal is stated
+inside it. The assembler does that. The lane does not decide it.
+
+Where a lane's preflight prints a report rather than a bare line, the report
+**names** each override. An override the user cannot see is an override they
+cannot audit.
+
+## The `ui` pack rides per TASK, never per lane
+
+`ui` is in no lane's default set. Add it to a single slice, at dispatch time:
+
+> If a task's **declared files** are front-end — `.css`, `.scss`, `.html`,
+> `.jsx`, `.tsx`, `.vue`, `.svelte`, or a directory the wiki or the cached
+> pattern identifies as the UI layer — assemble that task's card with
+> `--pack ui`. Otherwise do not.
+
+A UI rule in a backend slice is tokens paid on every spawn for a rule that
+cannot apply. A lane that dispatches no tasks never passes `--pack ui` at all.
+
+## What comes back
+
+Every return from a slice that carried this card gains three fields
+(`../return-validation.md`):
+
+| Field | What it holds |
+|---|---|
+| `rules_applied[]` | the ids the agent acted on |
+| `rules_conflicts[]` | two rules that disagree. **A gap, never a silent choice** |
+| `rules_overridden[]` | an ORC id a project rule replaced |
+
+A `rules_conflicts[]` entry is relayed to the user as a gap through the lane's
+own gap channel. Resolving it quietly is the failure the field exists to prevent.
+
+## The boundary — declared, never validated
+
+Rules govern **what is written and how it reads**, and **what shape of code is
+acceptable**. They can never change how a lane **runs**: the scoring, the wave
+order, the gates, the dispatch contract, the ship rules, or any lane's
+structural and safety rules.
+
+A rule that asks for one of those comes back as `unsupported_request` and is
+relayed as a gap. **Never a guessed compromise.**
+
+**Do not build a detector for this.** The CLI declares the boundary and does not
+pretend to enforce it, for the reason `orc doc rules` already settled: a
+validator that sometimes works is worse than none, because a clean pass then
+means nothing. The agent is the only reader that can tell a content rule from a
+structural one, so the agent is where the answer comes from.
+
+## The free lint
+
+```
+orc rules lint <path…|--staged|--diff> [--pack w,c,d,u] [--json]
+```
+
+Deterministic, zero tokens. Exit `0` clean · `1` findings · `2` nothing to lint.
+
+It checks only the rules a string match can prove, and it prints — in every
+mode — how many it did not check. **Relay that coverage line whenever you relay
+a lint result.** A clean exit allowed to stand in for a review nobody did is the
+whole failure that line prevents.
+
+Findings are ADVISORY. This phase adds no gate: a style preference that fails a
+build gets switched off within a week, and then nothing is enforced at all.
+
+An exemption is never silent either. The lint skips the rules packs themselves
+(a rule that bans a word has to print that word to define it) and any file
+marked `orc-rules-ignore-file`, and it reports the count of both.
+
+## Cost, and where to cut it
+
+Measured at v1.7.0: roughly **3 600 tokens** per build-lane slice, **4 300** with
+the UI pack, **2 200** for a prose-only lane. The card already carries HARD rules
+in full and PURPOSE/LOCK rules as one line plus the file to open when one
+applies.
+
+If it must come down, the lever is the worked examples inside the HARD bodies,
+and the only place to pull it is `rulesSlice()` in `bin/cli.js`. **Never by a
+lane deciding to trim its own card** — that is the drift this phase exists to
+prevent, arriving disguised as a saving.
+
+<!-- /orc:layer -->

package/templates/skills/_shared/return-validation.md

@@ -194,6 +194,34 @@ shipped into every slice and read by nobody is the failure mode this field
 exists to make visible, and it is invisible if `none` is quietly dropped. Absent
 on a slice that carried wiki material is malformed. Not required otherwise.
 
+## 5c. Rules attestation (when the anti-slop card was injected — v1.7.0)
+
+A slice assembled by `orc rules slice` (`phases/rules.md`) must return three
+fields. All three may be empty; **absent is malformed**, because an empty array
+and a missing one are the difference between "nothing applied" and "nobody
+looked".
+
+| Field | What it holds | Empty means |
+|---|---|---|
+| `rules_applied[]` | the rule ids the agent acted on | it changed nothing for this task |
+| `rules_conflicts[]` | two rules that disagree, each named by id or quote | none collided |
+| `rules_overridden[]` | an ORC id a project rule replaced | the project replaced none |
+
+**A `rules_conflicts[]` entry is a GAP, never a resolution.** Relay it through
+the lane's own gap channel and let the user decide. An agent that quietly picks
+a winner has made a standing decision for the project in a slice nobody will
+read again.
+
+`rules_overridden[]` is cross-checked against the `overrides` the CLI already
+computed. The agent may return MORE than the CLI counted — the CLI only counts
+ids a user NAMED, and the agent is the only reader that can spot an unnamed
+contradiction — but an id the CLI listed and the return omits means the card was
+not read.
+
+A rule the slice could not honour because this lane structurally cannot do it
+comes back as `unsupported_request`, relayed as a gap. **Never a guessed
+compromise.**
+
 ## 6. Worktree delta (post-wave, every lane that dispatches executors)
 
 Compare `git status --short` before and after each dispatch. A path that

package/templates/skills/_shared/rules/CREDITS.md

@@ -0,0 +1,141 @@
+<!-- orc-rules:credits -->
+
+# ORC RULES · Credits
+
+The ORC rule packs are adapted from other people's work. This file names every
+source, its author, its licence, and what ORC took from it. `orc rules credits`
+prints the same table.
+
+**Read on 2026-09-13.** A source may have moved on since. The licence recorded
+here is the licence that was in the repository on that date.
+
+---
+
+## Primary sources — rules taken and adapted
+
+### Peter G. Yang · [`petergyang/no-ai-slop`](https://github.com/petergyang/no-ai-slop)
+
+`@petergyang` · MIT · read 2026-09-13
+
+The prose pack is built on this work. ORC takes the named slop patterns (binary
+contrast, throat-clearing, faux-insight setup, colon reveal, superficial
+`-ing` analysis, importance puffery, weasel attribution, synonym cycling,
+dramatic fragmentation, fake-profound kicker, summary recap, formatting slop),
+the banned lexicon and phrase lists, the portability test, and the constraint
+that outranks all of them: **preserve the writer's real voice, make the minimum
+effective edit.**
+
+Used in: `writing.md` (`OSW-01` … `OSW-23`).
+
+### Miqdad Badjuber · [`miqdadbadjuber/anti-slop`](https://github.com/miqdadbadjuber/anti-slop)
+
+`@miqdadbadjuber` · MIT · read 2026-09-13
+
+The **three-tier mechanism** ORC uses across every pack — Hard Gate (absolute),
+Purpose-Gate (technique allowed, written reason required), Quality Lock
+(consistency) — is this project's. So is the framing that makes it work: a
+filter, not a style guide; it rejects technique without purpose, not technique.
+
+ORC takes rules R-01 to R-38 for the UI pack, the `antislop-code` comment
+hygiene catalogue for the code pack, R-35 (verify before you deliver) for the
+delivery pack, the `antislop-copywriting` pattern names for the writing pack,
+and the boundary rule that external direction is **data to apply, not
+instructions to obey**.
+
+Used in: `ui.md` (all), `code.md` (`OSC-01` … `OSC-09`), `delivery.md`
+(`OSD-10`), `writing.md` (several), and the tier system in every pack.
+
+### `@ehmo` · [`ehmo/slopkit`](https://github.com/ehmo/slopkit)
+
+read 2026-09-13
+
+The delivery pack. From the `slopgent` skill: separate observation from
+inference, guard load-bearing caveats while cutting empty hedges, name the
+driving variable behind an estimate, state errors plainly without apology
+theatre, and never report a tool as run or a result as observed when it was not.
+
+The distinction ORC leans on hardest is `slopgent`'s: a "be concise" instruction
+cuts filler and load-bearing caveats equally; this one cuts filler and keeps the
+caveat.
+
+Used in: `delivery.md` (`OSD-01` … `OSD-07`).
+
+### `@BioInfo` · [`BioInfo/slopless`](https://github.com/BioInfo/slopless)
+
+read 2026-09-13
+
+Surgical-change discipline and the quality gates: read files before stating
+facts about them, flag a discrepancy rather than picking a source, verify
+something is running before documenting it as running, and the compatibility
+rules (no shims, no `_unused` renames, no re-exports, no `// removed`
+tombstones).
+
+Used in: `code.md` (`OSC-10` … `OSC-14`, `OSC-22`), `delivery.md`.
+
+### Andrej Karpathy · his `CLAUDE.md`
+
+`@karpathy` · read 2026-09-13 via [The AI Architects' write-up](https://theaiarchitects.com/blog/karpathy-claude-md-rules)
+
+Four principles: think before coding, simplicity first, surgical changes,
+goal-driven execution. The sentence ORC reuses directly is the test for a
+surgical change: **every changed line should trace directly to the user's
+request.**
+
+Used in: `code.md` (`OSC-10`, `OSC-13`).
+
+### Matty Cartwright · [The Anti-Slop Writing Rules](https://mattycartwright.com/blog/the-anti-slop-writing-rules)
+
+read 2026-09-13
+
+The layered ban structure — words, then phrases, then sentence patterns, then
+structural patterns — which is how `writing.md` is ordered. Also the read-aloud
+tests (specificity, infomercial, commitment) that sit behind `OSW-20`.
+
+Used in: `writing.md` (structure, `OSW-10`, `OSW-11`, `OSW-20`).
+
+---
+
+## Research papers — rules derived, not copied
+
+### [Specification and Detection of LLM Code Smells](https://arxiv.org/html/2512.18020v1)
+
+Five named smells in code that calls a model: unbounded max metrics, no model
+version pinning, no system message, no structured output, temperature not
+explicitly set. `OSC-20` is these five, stated as a purpose-gate.
+
+### [AI-Generated Smells: An Analysis of Code and Architecture in LLM- and Agent-Driven Development](https://arxiv.org/html/2605.02741v1)
+
+Two findings ORC turned into rules. The **Reasoning-Complexity Paradox**:
+stronger models produce longer methods, not shorter ones, because they
+consolidate complex logic into one procedural block (`OSC-15`). The **Modular
+Mirage**: agents achieve structural modularity by separating files while related
+behaviour fragments across the tree, so cohesion drops as file count rises
+(`OSC-16`). The paper's God-class and Too-Many-Branches findings are `OSC-17`.
+
+### [Investigating the Smells of LLM Generated Code](https://arxiv.org/pdf/2510.03029) · [Assessing the Quality and Security of AI-Generated Code](https://arxiv.org/pdf/2508.14727)
+
+Over-commenting, redundant defensive checks for conditions that cannot happen,
+dead assignments, and functions that reimplement something already present.
+Behind `OSC-01`, `OSC-11` and `OSC-18`.
+
+---
+
+## Read, nothing taken
+
+Listed so a reader can follow the same trail. Each restates patterns the primary
+sources already cover.
+
+- [`adewale/anti-slop-writing`](https://github.com/adewale/anti-slop-writing)
+- [`jalaalrd/anti-ai-slop-writing`](https://github.com/jalaalrd/anti-ai-slop-writing)
+- `tmdgusya/engineering-discipline`, the `clean-ai-slop` skill
+
+---
+
+## If you are one of these authors
+
+The rule text here is adapted, not copied verbatim, and reorganised into ORC's
+own id scheme so that a lint finding and a conflict report can name the same
+thing across versions. If you would prefer different wording, a different
+attribution, or removal, open an issue on
+[`azure-id/orc`](https://github.com/azure-id/orc) and it will be changed in the
+next release.

package/templates/skills/_shared/rules/INDEX.md

@@ -0,0 +1,107 @@
+<!-- orc-rules:index -->
+
+# ORC RULES — the anti-slop baseline
+
+> **READ-ONLY.** Everything in this folder ships with ORC and changes only with
+> `orc update`. Nothing in ORC writes here, and `orc rules set --pack …` is
+> refused by name.
+>
+> Your own rules live in `.claude/orc/rules.md`. Write them with
+> `orc rules add --priority P0 --text "…"`, or in `orc ui` ▸ **Rules**.
+
+ORC generates a lot of text and a lot of code. Both come out carrying the same
+recognisable defaults: prose that says nothing in a confident shape, and code
+that is longer, more defensive and more abstract than the task asked for. These
+packs are the filter.
+
+**This is a filter, not a style guide.** It prescribes no voice, no aesthetic
+and no architecture. It rejects technique without purpose, and it never invents
+direction of its own.
+
+---
+
+## The packs
+
+| Pack | File | Ids | Rules | Layer | Applies to |
+|---|---|---|---|---|---|
+| **Writing** | `writing.md` | `OSW-01…23` | 23 | `writing` | every word an agent writes |
+| **Code** | `code.md` | `OSC-01…22` | 22 | `code` | source an agent writes or edits |
+| **Delivery** | `delivery.md` | `OSD-01…10` | 10 | `core` | what an agent reports about its own work |
+| **UI** | `ui.md` | `OSU-01…10` | 10 | `ui` | front-end work only, added **per task** |
+
+**65 rules.** `orc rules --json` is the count's only source. Never compute it
+here, and never compute it in a skill.
+
+Credits, licences and what was taken from whom: `CREDITS.md`, or
+`orc rules credits`.
+
+---
+
+## The three tiers
+
+| Tier | Meaning | On a finding |
+|---|---|---|
+| **HARD** | Absolute. No exception, no purpose that redeems it. | A finding. |
+| **PURPOSE** | The technique is allowed. It needs a written one-line reason. | Missing reason is a finding; the technique is not. |
+| **LOCK** | A consistency requirement. | Reported, never blocking. |
+
+The tier system is Miqdad Badjuber's (`miqdadbadjuber/anti-slop`). The mechanism
+it exists for: a ban list alone leaves a void, and a model fills a void with its
+most generic output. A purpose gate asks for the reason instead, which is the
+only thing that separates craft from default.
+
+---
+
+## Precedence — three layers, and the order never changes
+
+```
+1.  PROJECT CODE HOUSE RULES        ../phases/house-rules.md + the project's CLAUDE.md P0
+    ├ scope: CODE and agent BEHAVIOUR only
+    └ beats everything below it, always
+
+2.  USER RULES                      .claude/orc/rules.md    (P0 > P1 > P2)
+    └ beats the ORC rules OUTRIGHT on any conflict
+
+3.  ORC RULES                       these packs — read-only
+```
+
+**Layer 1 is code-only.** The house card governs how a change is made: surgical,
+simple, honest, in-slice. It says nothing about the words an agent writes, so it
+never overrules a writing rule — it does not speak about prose at all.
+
+**Layer 2 wins outright over layer 3.** A user rule that contradicts an ORC rule
+disables that ORC rule for this project. This is never silent: the agent returns
+`rules_overridden[]` naming the ORC id and the user line that replaced it, and
+the preflight prints the count. A silent override is the one outcome nobody can
+audit.
+
+---
+
+## The boundary
+
+Rules govern **what is written and how it reads**, and **what shape of code is
+acceptable**. They can never change how a lane **runs**: the scoring, the wave
+order, the gates, the dispatch contract, the ship rules, or any lane's
+structural and safety rules.
+
+A rule that asks for one of those comes back as `unsupported_request` and is
+relayed as a gap. **Never a guessed compromise.**
+
+**There is no fake validator here.** The CLI cannot parse intent, so it does not
+pretend to. It does not detect a user rule that would break a structural rule.
+It **declares** the boundary — in `orc rules`, at the top of every dispatched
+slice, and in the panel. This is the same decision `orc doc rules` made, and for
+the same reason: a validator that sometimes works is worse than none.
+
+---
+
+## What reads these packs
+
+- `orc rules slice --lane <lane>` is the **only** assembler. No skill builds the
+  card itself, so no two lanes can drift.
+- `../phases/rules.md` is the phase that injects it.
+- `orc rules lint` checks the mechanically checkable subset and says, in every
+  mode, how many rules it did **not** check.
+- `/orc-doc` reads **none** of this. That lane has its own ledger, written with
+  `orc doc rules`, and its own frozen-per-document mechanic. The two surfaces
+  never mix.

package/templates/skills/_shared/rules/code.md

@@ -0,0 +1,229 @@
+<!-- orc-rules:pack id=code prefix=OSC layer=code -->
+
+# ORC RULES · Code (`OSC`)
+
+> **READ-ONLY.** This file ships with ORC and changes only with `orc update`.
+> Your own rules go in `.claude/orc/rules.md`, and **yours win** wherever the two
+> disagree.
+
+**Applies to** source an agent writes or edits.
+
+**Precedence note.** The project's CODE house rules
+(`../phases/house-rules.md` and the project's own `CLAUDE.md` P0) beat this pack
+and beat the user ledger. This pack never restates a house rule; where one
+already covers the ground, the rule below cites it.
+
+**Source.** Andrej Karpathy's `CLAUDE.md` ·
+[`BioInfo/slopless`](https://github.com/BioInfo/slopless) ·
+Miqdad Badjuber — [`miqdadbadjuber/anti-slop`](https://github.com/miqdadbadjuber/anti-slop), the `antislop-code` skill (MIT) ·
+[Specification and Detection of LLM Code Smells](https://arxiv.org/html/2512.18020v1) ·
+[AI-Generated Smells](https://arxiv.org/html/2605.02741v1) ·
+[Investigating the Smells of LLM Generated Code](https://arxiv.org/pdf/2510.03029).
+Full attribution in `CREDITS.md`.
+
+---
+
+### OSC-01 · HARD · A comment never restates the code
+
+Delete a comment that repeats what the next line, the declaration or the
+signature already shows: `// Initialize the variable` above `let count = 0`,
+`// User class` above `class User {}`, `const userAge = 25; // User age is 25`.
+
+It doubles the reading load and adds nothing. Remove the comment. Leave the code.
+
+### OSC-02 · HARD · No decorative separator
+
+No banner built from repeated characters, no ALL-CAPS section label, no
+box-drawn header: `// ==========`, `// -------- WORKFLOW --------`,
+`/* ---- ROUTES ---- */`.
+
+The decoration is the message, and the message is "generated". Use one plain
+line, or nothing.
+
+Checked by `orc rules lint`.
+
+### OSC-03 · HARD · No workflow narration
+
+No `// Step 1: Validate input`, `// Step 2: Process`, `// First…`, `// Next…`,
+`// Finally…`. The control flow is already visible.
+
+If the flow is genuinely hard to follow, that is a structure problem, not a
+missing comment.
+
+Checked by `orc rules lint`.
+
+### OSC-04 · HARD · No empty label
+
+No `// Main logic`, `// Core logic`, `// Business logic`, `// Helper function`,
+`// Entry point`, `// Error handling`, `// Note: this is important`,
+`// Important: please read`.
+
+The label names a category, not a fact. "Note: retries happen only on 5xx" earns
+its place. "Note: this is important" does not.
+
+Checked by `orc rules lint`.
+
+### OSC-05 · HARD · A TODO names a task
+
+No `// TODO: improve this`, `// Future improvements`, `// Additional
+optimization can be added here`, `// Add more validation`.
+
+A vague TODO names a feeling, not a task. Keep a TODO only when it says what to
+do and carries enough context to act on. Otherwise delete it.
+
+Checked by `orc rules lint`.
+
+### OSC-06 · HARD · No decorative emoji in code
+
+No emoji as decoration in a comment, a log line or an identifier: `// ✅
+Validation`, `// 🚀 Performance`, `// 🔒 Security`. Emoji is visual noise in
+source, and that exact set is the generated vocabulary.
+
+Carve-out: a string the product actually renders to a user, and a test asserting
+on it.
+
+Checked by `orc rules lint`.
+
+### OSC-07 · HARD · No end markers
+
+No `} // end if`, `# End of function`, `// End processOrder`. The closing brace
+already ends the block.
+
+Checked by `orc rules lint`.
+
+### OSC-08 · LOCK · One line per comment
+
+One line. Two only when the second carries a new fact. Never three.
+
+A person leaves a note; a generator writes a case. Cut the reasoning chain, the
+issue number and the version history. Keep the constraint: the platform trap,
+the silent failure, the protocol rule, the performance cost.
+
+**Value is not length.** A comment that legitimately earns its place still does
+not earn a paragraph.
+
+### OSC-09 · HARD · Comments explain why, never what
+
+Never strip a comment that carries: business logic and intent · an architectural
+decision · a security consideration · a performance trade-off · concurrency
+behaviour · a protocol detail · an API contract · a workaround · an edge case or
+assumption · a licence or legal notice.
+
+```js
+// Stripe may retry webhook deliveries for up to three days.
+// Ignore duplicate events using the event ID.
+```
+
+That comment stays. A comment earns its place when it explains something the
+code does not already show.
+
+### OSC-10 · HARD · No speculative abstraction
+
+Minimum code that solves the stated problem. No helper for a one-time operation.
+No abstraction for a single call site. No configurability nobody asked for. No
+design for a hypothetical future requirement.
+
+Three similar lines of code beat a premature abstraction.
+
+### OSC-11 · HARD · No defence against impossible states
+
+No error handling, fallback or validation for a scenario that cannot happen.
+Trust internal code and framework guarantees.
+
+Validate at system boundaries only: user input, external APIs, parsed files, and
+anything crossing a process boundary.
+
+### OSC-12 · HARD · No backwards-compatibility shim
+
+When the code can just change, change it. No feature flag, no compatibility
+layer, no `_unused` rename, no re-export of a moved type, no `// removed`
+tombstone.
+
+If it is unused, delete it completely.
+
+### OSC-13 · HARD · Surgical
+
+Every changed line traces directly to the request. Do not improve adjacent code,
+comments or formatting. Do not refactor what is not broken. Do not add
+docstrings or type annotations to code you did not change.
+
+Cites house card rule 1. Where the house card and this rule differ, the house
+card wins.
+
+### OSC-14 · HARD · Pre-existing dead code: mention, do not delete
+
+Remove the imports, variables and functions **your** change left unused. Report
+any other dead code you notice; do not remove it unless asked.
+
+### OSC-15 · PURPOSE · Method length
+
+A function longer than the file's own norm is split, or the reason is written in
+one line.
+
+Stronger models write longer methods, not shorter ones: they consolidate complex
+logic into a single procedural block because that is locally the most probable
+continuation. This rule is the counterweight.
+
+### OSC-16 · PURPOSE · No Modular Mirage
+
+New files that spread one behaviour across the tree produce structural
+modularity with no semantic cohesion. If a change adds files, the reason each
+boundary exists is written in one line.
+
+Separating files is not the same as separating concerns.
+
+### OSC-17 · PURPOSE · No God class, no branch sink
+
+No "manager" or "service" class that centralises every branch. No class whose
+response set spans most of the module. Where one is genuinely right, write the
+reason.
+
+### OSC-18 · HARD · Look before you write a helper
+
+Before adding a helper, a util, a formatter or a validator, search for the one
+that already exists. Redundant reimplementation is the most expensive slop in
+this pack: it compiles, it passes, and it doubles the maintenance surface
+silently.
+
+### OSC-19 · HARD · Match the existing style
+
+Match the surrounding code's naming, comment density, error handling and file
+layout, even where you would do it differently. The cached project pattern
+(`orc pattern`) is the reference when one exists.
+
+### OSC-20 · PURPOSE · LLM-calling code is pinned and bounded
+
+When the task writes code that calls a model, each of these is done or the
+reason is written:
+
+- Pin the model **version**, never a bare provider alias.
+- Set `temperature` explicitly. Provider defaults differ and change.
+- Bound max tokens, timeouts and retries. Unbounded is not "no limit", it is an
+  unknown limit.
+- Send a system message.
+- Enforce a structured output schema where the caller expects fields.
+
+### OSC-21 · HARD · No unrequested artifact files
+
+Do not create a file nobody asked for: `SUMMARY.md`, `IMPLEMENTATION_NOTES.md`,
+`CHANGES.md`, `NOTES.md`, `*_final`, `*_v2`, `*_new`, `*.bak`, `*.old`.
+
+Report in the return. Do not leave a file behind as the report.
+
+Checked by `orc rules lint` on new files.
+
+### OSC-22 · HARD · Introduce no OWASP Top 10 weakness
+
+Injection, broken access control, insecure deserialisation, secrets in source,
+missing authorisation on a new endpoint, unvalidated redirect. If you notice
+insecure code you wrote, fix it in the same slice and say so in the return.
+
+---
+
+## Not a ban — keep these
+
+- Every comment on the `OSC-09` list, at whatever length its facts require.
+- Validation at a real system boundary (`OSC-11` is about impossible states, not
+  about untrusted input).
+- An abstraction with two or more real call sites today.
+- Defensive code the project's own pattern already established (`OSC-19` wins).