dsh-aris-panel 0.1.0

package/skills/shared-references/patent-writing-principles.md

@@ -0,0 +1,197 @@
+# Patent Writing Principles
+
+Use this reference when `claims-drafting`, `specification-writing`, or `invention-structuring` need guidance on patent-specific writing rules.
+
+## When to Read
+
+- Read before drafting any claims.
+- Read when specification text needs to support claim scope.
+- Read when choosing between claim formats (Jepson vs. two-part vs. open-ended).
+- Read when the language feels too academic or too vague for patent purposes.
+- Read before jurisdiction-specific formatting.
+
+## Contents
+
+- [Core Patent Writing Rules](#core-patent-writing-rules)
+- [Claim Drafting Principles](#claim-drafting-principles)
+- [Specification Writing Rules](#specification-writing-rules)
+- [Common Pitfalls](#common-pitfalls)
+- [Terminology Discipline](#terminology-discipline)
+
+---
+
+## Core Patent Writing Rules
+
+### The Three Requirements
+
+Every patent application must satisfy three fundamental requirements:
+
+1. **Novelty** (新颖性): The invention must be new -- not anticipated by a single prior art reference.
+2. **Inventive Step / Non-obviousness** (创造性): The invention must not be obvious to a person skilled in the art (POSITA) based on prior art.
+3. **Industrial Applicability / Utility** (实用性): The invention must be capable of being made or used in industry.
+
+### The Written Description Requirement
+
+The specification must demonstrate that the inventor was in **possession** of the claimed invention as of the filing date. This means:
+
+- Every element in every claim must find explicit or inherent support in the specification.
+- Broader claims require broader disclosure. If you claim "a processor," the spec must show you had a processor in mind, not just one specific chip.
+- Adding claim scope after filing that wasn't in the original disclosure is not permitted (no new matter).
+
+### The Enablement Requirement
+
+The specification must teach a **Person Skilled in the Art (POSITA)** to make and use the invention without undue experimentation. Test: could a skilled practitioner reproduce the invention from your description alone?
+
+### Claims Define Scope, Specification Enables It
+
+- **Claims** = the legal boundary (what is protected)
+- **Specification** = the teaching (how to practice the invention)
+- **Figures** = the visual aid (reference numerals link claims to specification)
+
+---
+
+## Claim Drafting Principles
+
+### Broadest Reasonable Interpretation (BRI)
+
+Claims are interpreted under the **broadest reasonable interpretation** during prosecution (USPTO standard; EPO uses a different but analogous approach). This means:
+
+- Common words are given their ordinary meaning.
+- Terms are NOT limited to the embodiments described in the specification.
+- If you want a term to have a special meaning, you must explicitly define it in the specification.
+
+### Claim Structure (Universal)
+
+Every claim has:
+1. **Preamble**: Identifies the category of invention (e.g., "A method for...", "A system comprising...", "An apparatus for...")
+2. **Transitional phrase**: Defines scope boundary
+   - "comprising" / "including" / "containing" = OPEN (additional elements allowed)
+   - "consisting of" = CLOSED (no additional elements)
+   - "consisting essentially of" = SEMI-OPEN (allows insubstantial variations)
+3. **Body**: The claim elements/limitations, each separated by semicolons or commas
+
+### Antecedent Basis
+
+- First mention of an element: use indefinite article ("a", "an") -- "a processor"
+- Subsequent mentions: use definite article ("the", "said") -- "the processor"
+- Never use "the" for something not previously introduced in the claim.
+- Never use "a" again for the same element (implies a second instance).
+
+### Independent vs. Dependent Claims
+
+**Independent claims** define the broadest defensible scope. Draft these first.
+
+**Dependent claims** narrow the scope by adding specific limitations. Each dependent claim:
+- Must refer back to a prior claim ("The method of claim 1, wherein...")
+- Must add at least one meaningful limitation
+- Should provide fallback positions if the independent claim is rejected
+- Should cover preferred embodiments described in the specification
+
+### Multiple Claim Categories
+
+For the same invention, draft claims in multiple categories:
+- **Method/process claims**: Steps performed
+- **System/apparatus claims**: Structural components
+- **Computer-readable medium claims**: (US) Tangible medium storing instructions
+- **Product-by-process claims**: (when structure is difficult to define)
+
+This multiplies the scope of protection without requiring separate applications.
+
+---
+
+## Specification Writing Rules
+
+### Section Structure (Universal)
+
+1. **Title**: Concise, matches broadest claim scope, no trademark names, no "improved" or "new"
+2. **Technical Field** (技术领域): 1-2 paragraphs identifying the technical domain
+3. **Background** (背景技术): Prior art and its deficiencies -- NOT a literature review, but specific technical shortcomings that the invention addresses
+4. **Summary** (发明内容): Problem-Solution-Advantage triple
+5. **Brief Description of Drawings** (附图说明): One sentence per figure
+6. **Detailed Description** (具体实施方式): Detailed embodiments with reference numerals
+7. **Abstract** (摘要): Jurisdiction-specific word limits
+
+### Language Rules for Specifications
+
+**DO:**
+- Use "embodiment", "aspect", "implementation", "configuration"
+- Use "optionally", "preferably", "in some implementations"
+- Use "may" for optional features, "shall" or "is configured to" for required features
+- Reference figures by numeral: "As shown in FIG. 1, the processor 102..."
+- Use consistent terminology throughout (same word for same concept)
+
+**DO NOT:**
+- Use subjective adjectives: "excellent", "surprising", "revolutionary", "superior"
+- Use result-to-be-achieved language: "configured to achieve high accuracy" (instead describe HOW)
+- Use relative terms without definition: "thin", "strong", "fast", "small"
+- Admit prior art is better: avoid "unlike the prior art, which works well, we..."
+- Include experimental results tables (save for prosecution arguments, not the spec itself)
+
+### Reference Numeral Convention
+
+- Use consistent numbering series: 100-series for FIG. 1, 200-series for FIG. 2
+- Every component mentioned in specification must have a numeral
+- Every numeral in figures must be explained in the specification
+- Format: "processor 102", "memory 104", "bus 106" (numeral follows the noun)
+
+---
+
+## Common Pitfalls
+
+### Negative Limitations
+
+Avoid claims that define the invention by what it is NOT:
+- Bad: "A method that does not use a database"
+- Good: "A method comprising storing data in a local cache"
+
+Negative limitations are sometimes necessary but require explicit basis in the specification.
+
+### Result-to-Be-Achieved Claims
+
+Do not claim a result without describing the mechanism:
+- Bad: "A method for achieving 99% accuracy in image classification"
+- Good: "A method comprising: extracting features using a convolutional neural network having at least three residual blocks..."
+
+### Indefinite Terms
+
+Avoid terms that create uncertainty about scope:
+- "approximately", "about", "substantially" -- acceptable if the specification defines the range
+- "high quality", "efficient", "optimal" -- too vague, will receive 112(b) rejection (US)
+- "etc.", "and the like", "or similar" -- creates open-ended ambiguity
+
+### Functional Claiming (Means-Plus-Function)
+
+In US practice, "means for [function]" triggers 35 USC 112(f) and is limited to the corresponding structure in the specification. Use with caution:
+- "means for processing" = limited to the specific processor embodiments described
+- "a processor configured to process" = broader (not means-plus-function)
+- In CN/EP practice, functional claiming is generally more restrictive
+
+### Claim Differentiation Doctrine
+
+Dependent claims are presumed to have different scope from their parent claims. Do not:
+- Copy the parent claim verbatim into a dependent claim
+- Add a limitation that is already inherent in the parent claim
+- Create dependent claims that are merely cumulative combinations of other dependent claims
+
+---
+
+## Terminology Discipline
+
+### Consistency Rule
+
+Once a term is introduced, use it identically throughout:
+- Do NOT alternate between "processor", "processing unit", "CPU", "computing device" for the same component
+- If the invention has a specific component, name it once and reuse that name
+
+### Definition Rule
+
+If a term has a meaning specific to your invention:
+1. Define it explicitly in the specification
+2. Use "hereinafter referred to as" or "herein defined as" language
+3. Use the defined term consistently thereafter
+
+### Jurisdiction-Specific Terminology
+
+- **CN**: Use standard patent Chinese. "所述" (said/the), "其特征在于" (characterized in that), "一种...的方法/装置" (a method/apparatus for...)
+- **US**: Use standard patent English. "comprising", "configured to", "in communication with"
+- **EP**: Follow EPO Guidelines for Examination. Two-part claim form mandatory.

package/skills/shared-references/prior-art-databases.md

@@ -0,0 +1,141 @@
+# Prior Art Search Databases Guide
+
+Use this reference in `/prior-art-search` for systematic patent and literature searching.
+
+## When to Read
+
+- Read when conducting prior art searches
+- Read when formulating search queries for patents
+- Read when classifying search results by IPC/CPC codes
+
+## Patent Databases (Free, Web-Accessible)
+
+### Google Patents
+- **URL**: patents.google.com
+- **Coverage**: US, EP, CN, WIPO, JP, KR, and 100+ jurisdictions
+- **Search syntax**: Full-text search, inventor:, assignee:, CPC:, before:, after:
+- **Strengths**: Best free full-text search, automatic translation of CN/JP/KR patents, family grouping
+- **Weaknesses**: No legal status data, may lag behind official databases by weeks
+- **Usage in skills**: `WebSearch "site:patents.google.com [keywords]"` or `WebFetch` for specific patent pages
+
+### Espacenet (EPO)
+- **URL**: worldwide.espacenet.com
+- **Coverage**: 150+ million patent documents from 100+ authorities
+- **Search syntax**: Classification=(CPC/IPC), Applicant=, Title/Abstract/Claims full text
+- **Strengths**: Most comprehensive free database, machine translation, legal status via INPADOC
+- **Weaknesses**: Interface is less intuitive, some features require registration
+- **Usage**: `WebFetch` for search results and individual patent pages
+
+### CNIPA Patent Search (中国及多国专利审查信息查询)
+- **URL**: pss-system.cponline.cnipa.gov.cn (or similar)
+- **Coverage**: Chinese patents (CN), the authoritative source for CN applications
+- **Strengths**: Official Chinese patent data, full Chinese text, examination status
+- **Weaknesses**: Interface in Chinese only, limited foreign coverage
+- **Usage**: `WebFetch` for Chinese-specific searches
+
+### USPTO Patent Full-Text Databases
+- **PatFT**: patents.google.com/patents (US granted patents)
+- **AppFT**: patents.google.com (US published applications)
+- **PAIR**: patentcenter.uspto.gov (prosecution history)
+- **Coverage**: US patents and applications
+- **Usage**: `WebFetch` for specific US patent numbers
+
+### WIPO PATENTSCOPE
+- **URL**: patentscope.wipo.int
+- **Coverage**: PCT international applications (WO publications)
+- **Strengths**: Full PCT application texts, CLIR cross-lingual search
+- **Usage**: `WebFetch` for PCT applications
+
+## Academic Literature Databases
+
+These are also prior art (non-patent literature, NPL):
+
+| Database | URL | Coverage | API Available |
+|----------|-----|----------|---------------|
+| Google Scholar | scholar.google.com | Broadest academic coverage | No API, use WebSearch |
+| Semantic Scholar | semanticscholar.org | CS, biomedical, 200M+ papers | Yes (SEMANTIC_SCHOLAR_API_KEY) |
+| arXiv | arxiv.org | Preprints (CS, physics, math, etc.) | Yes (arxiv_fetch.py) |
+| DBLP | dblp.org | CS bibliography | Yes (XML API) |
+| CrossRef | crossref.org | DOIs for all published works | Yes (free, no key needed) |
+| OpenAlex | openalex.org | 250M+ scholarly works | Yes (free, no key needed) |
+
+## IPC/CPC Classification System
+
+The International Patent Classification (IPC) and Cooperative Patent Classification (CPC) organize patents hierarchically:
+
+### Structure
+```
+A 61 K  39 / 395
+│  │  │  │   │
+│  │  │  │   └─ Subgroup (specific)
+│  │  │  └─ Group
+│  │  └─ Subclass
+│  └─ Class
+└─ Section (A=Human necessities, B=Performing operations, C=Chemistry, etc.)
+```
+
+### Most Relevant Sections for Software/ML Inventions
+- **G06F**: Electric digital data processing
+- **G06N**: Computing arrangements based on specific computational models (AI/ML)
+- **G06K**: Recognition of data; Presentation of data
+- **G06T**: Image data processing or generation
+- **G06Q**: Data processing systems for business/finance/administration
+- **H04L**: Transmission of digital information (networking)
+- **H04N**: Pictorial communication (video, image)
+
+### Search Strategy with Classifications
+
+1. Identify relevant IPC/CPC classes from the invention description
+2. Search within those classes for targeted results
+3. Expand to parent/child classes for broader coverage
+4. Combine class-restricted searches with keyword searches
+
+## Search Strategy Template
+
+For each invention, execute this search protocol:
+
+### Step 1: Keyword Search
+```
+Primary: [core inventive concept keywords]
+Secondary: [technical problem keywords]
+Tertiary: [advantage/feature keywords]
+```
+
+### Step 2: Classification Search
+```
+IPC/CPC: [identified classes]
+Cross-reference: [related classes]
+```
+
+### Step 3: Assignee/Inventor Search
+```
+Key assignees: [known companies/universities in the field]
+Key inventors: [known researchers in the field]
+```
+
+### Step 4: Citation Analysis
+- Forward citations: who cited the closest prior art?
+- Backward citations: what did the closest prior art cite?
+
+### Step 5: Family Analysis
+- Group results by patent family (same invention, different jurisdictions)
+- Only the most relevant family member needs detailed analysis
+
+## Output Format
+
+For each prior art reference found:
+
+```markdown
+| Field | Content |
+|-------|---------|
+| Reference ID | [Patent number or paper DOI] |
+| Type | Patent / Paper / Other |
+| Title | [Full title] |
+| Date | [Publication/priority date] |
+| Assignee/Authors | [Who] |
+| IPC/CPC | [Classification codes] |
+| Key Teaching | [What does it teach, 2-3 sentences] |
+| Relevant Claims | [Which claims, if patent] |
+| Overlap Risk | HIGH / MEDIUM / LOW |
+| Relationship | [Anticipating / Relevant / Background] |
+```

package/skills/shared-references/resumable-runs.md

@@ -0,0 +1,109 @@
+# Resumable Runs
+
+A long ARIS workflow (`/research-pipeline`, `/paper-writing`, `/idea-discovery`)
+can fail mid-run — a rate limit, a crash, an overnight timeout. Today there is no
+record of *which phase finished*, so a resume restarts from scratch (this is the
+live complaint in issue #272: "the survey run failed — can it continue from the
+last task?"). `tools/run_state.py` fixes that: a run is an **ordered list of
+phases with status**, persisted at `<root>/.aris/runs/<run_id>.json`.
+
+Workflow-level deterministic checks are recorded separately under `gates` in
+the same state file. A gate may emit `PASS` or `BLOCKED` with durable reasons;
+it does not replace the per-phase acceptance record.
+
+## The one idea that makes this ARIS, not just "reopen the session"
+
+Resumption is not "reopen the id" — it is **resolve FORWARD to where progress
+that can be TRUSTED actually landed.** And "trusted" is where ARIS's invariant
+lives. The phase-status enum splits execution from acceptance:
+
+| status | meaning | who sets it | gate class |
+|--------|---------|-------------|-----------|
+| `pending` | not started | `start` | — |
+| `running` | in progress | executor (`set`) | — |
+| `failed` | executor errored | executor (`set`) | — |
+| **`done`** | executor finished writing the artifact | executor (`set`) | **EXECUTION-completeness — safe same-model self-report** |
+| **`accepted`** | a cross-model reviewer **or** a deterministic verifier returned a positive verdict | **`accept` only** — requires a recorded verdict id + reviewer, AND the phase already `done` (use `--force` for a purely-deterministic phase with no executor step) | **QUALITY/correctness — cross-model (or a deterministic check)** |
+| `skipped` | the phase does not apply to this run (e.g. `paper-writing` when `AUTO_WRITE=false`) | executor (`set`) | terminal — a deterministic config decision, not a quality verdict |
+
+**Resume walks forward to the first phase that is NOT terminal ({`accepted`, `skipped`})** — never
+the first non-`done`. So a phase the executor self-considered "done" but that
+crashed *before its cross-model audit* is **re-validated** on resume, never
+silently skipped. This is `acceptance-gate.md` made operational: **a loop can
+DRIVE resume, it cannot ACQUIT a phase past itself.**
+
+The split is enforced in code, not just docs: `set_status()` may only write
+`running/done/failed`; only `accept()` writes `accepted`, and it **requires** a
+non-empty `verdict_id` + `reviewer` — you cannot mark a phase accepted without
+recording who acquitted it. (A `done`-but-never-`accepted` phase is therefore
+*structurally* visible as an unmet acceptance obligation.)
+
+## Who may call `accept`
+
+Only:
+- a **cross-model reviewer** verdict (codex/gemini, per `reviewer-independence.md`)
+  — `reviewer="codex-gpt-5.6-sol"`, `verdict_id=<thread/trace id>`; or
+- a **deterministic verifier** — `verify_papers.py`, a passing test suite, a
+  compile that exits 0, a file-exists check for a purely mechanical phase.
+  Record it as `reviewer="deterministic:verify_papers.py"` so the audit trail
+  shows acceptance was not a model self-report (per `fan-out-pattern.md`: a
+  deterministic verifier is a valid jury; a process is not a model family).
+
+The **executor (Claude) must never call `accept` on its own self-report.** Marking
+your own phase done is fine (`set done`); acquitting it is not. `accept` records
+the `reviewer` and warns loudly if it looks like the executor's own family
+(a `claude*` reviewer ≈ self-acquittal). Record `verdict_id` as a **durable
+handle** — the reviewer thread/trace id, or the path/sha of the verifier's report
+(e.g. `.aris/audit-verifier-report.json`) — not just a label, so the acceptance
+is auditable later.
+
+**Concurrency:** one orchestrator per run (single-writer contract). Mutations are
+load-modify-save under a best-effort `flock` with atomic temp-file replace, so a
+stray concurrent resumer can't corrupt the JSON — but a `/loop`/cron resumer must
+not deliberately double-run a run (per `external-cadence.md`, the scheduler
+triggers resume, it does not own the verdict).
+
+## Helper API / CLI
+
+```
+from run_state import start_run, set_status, accept, record_gate_result, resume_point
+start_run(root, run_id, phases)                 # phases: ["W1","W1.5","W2","W3"]
+set_status(root, run_id, phase, "running"|"done"|"failed", artifact=path)
+accept(root, run_id, phase, verdict_id, reviewer)   # the ONLY path to `accepted`
+record_gate_result(root, run_id, gate, "PASS"|"BLOCKED", reasons)
+resume_point(root, run_id)  # -> first NON-TERMINAL phase ({accepted,skipped} skipped), or None
+```
+
+```
+python3 tools/run_state.py start  <root> <run_id> --phases "W1,W1.5,W2,W3"
+python3 tools/run_state.py set    <root> <run_id> W1 done --artifact idea-stage/IDEA_REPORT.md
+python3 tools/run_state.py accept <root> <run_id> W1 --verdict-id codex:019e... --reviewer codex-gpt-5.6-sol
+python3 tools/run_state.py resume <root> <run_id>   # prints the resume-target phase name on stdout
+python3 tools/run_state.py status <root> <run_id>
+```
+
+## Integration pattern for a workflow skill
+
+1. **At run start** (or `— resume <run_id>`): if resuming, `resume_point` gives
+   the phase to start at; else `start_run` with the phase list.
+2. **Per phase:** `set running` → do the work → `set done --artifact <path>`.
+3. **At the phase's gate:** run the phase's existing cross-model audit / jury (or
+   deterministic verifier). **Only on a positive verdict** call
+   `accept --verdict-id <id> --reviewer <name>`. A failed/ambiguous verdict leaves
+   the phase `done` (unaccepted) → it will be re-validated on the next resume.
+4. **Resume** therefore re-runs `running`/`failed` phases and **re-audits**
+   `done`-but-unaccepted phases, and skips only terminal (`accepted`/`skipped`) ones.
+
+## Cross-references
+- `acceptance-gate.md` — the source rule (`done` = execution-completeness, safe
+  same-model; `accepted` = quality/correctness, must be cross-model or
+  deterministic). This file is that rule applied to multi-phase resume.
+- `external-cadence.md` — `/loop` / `/schedule` may *trigger* a resume (fire-control)
+  but the acceptance status is owned by the gate, not the scheduler.
+- `reviewer-independence.md` — the `accept` verdict comes from a fresh cross-model
+  thread (paths only), and its id is recorded for audit.
+
+> Shape inspired by NousResearch/hermes-agent's resume-resolves-forward insight
+> (`hermes_state.py` resolve_resume_session_id). ARIS's increment: Hermes's phase
+> is execution-driven only ("the agent finished → resumable"); ARIS adds the
+> `accepted` gate so resume cannot carry a self-judged-but-unverified phase forward.

package/skills/shared-references/review-scope-limits.md

@@ -0,0 +1,81 @@
+# Review Scope Limits — what a reviewer may propose
+
+ARIS is a research-workflow tool. Its reviewers exist to find what is **actually
+wrong**, not to harden a codebase against what is not happening.
+
+This contract is about what a reviewer may **propose**. It never limits what a
+reviewer may **look for** — see *Find vs propose* below.
+
+## The block
+
+Every reviewer prompt that can result in a proposed change to code, prompts, or
+mechanism carries this verbatim:
+
+```
+=== SCOPE LIMITS (these bound what you PROPOSE, never what you look for) ===
+Report anything that is actually wrong here — including a rare-looking case, if
+this repo actually produces it. Then keep the fix in scope:
+1. This is a RESEARCH-WORKFLOW tool, not a security paper. Verification is
+   welcome; over-defense is not. Assume a cooperating operator on their own
+   machine — a malicious local user is NOT in the threat model.
+2. Do NOT propose SHA / hash / content-fingerprint / digest-binding schemes.
+   Reporting a real defect in hashing code that already exists is fine.
+3. NO speculative machinery: do not add feature flags, migration frameworks,
+   compat layers, wrappers, pins, or similar mechanisms unless evidence shows
+   a current repo defect they fix or an explicit existing invariant they must
+   preserve. "Load-bearing", "compatibility", and "not scaffolding" are labels,
+   not evidence. Point to the failing path/artifact or invariant, and check the
+   proposal's factual premises, such as whether a named package version exists.
+4. NO corner-case obsession: exotic encodings, symlink races, RTL text and
+   millisecond races are out of scope unless you can show the case arises here.
+5. Where a rubric or checklist is genuinely needed, do not over-mechanize
+   judgement. A clear sentence a human reads beats a scored table nobody
+   maintains.
+Exception: code that runs remote commands, starts a network service, or installs
+an MCP server runs on the user's machine with their credentials — trust-boundary
+findings there are in scope and the default is strict.
+Say plainly when something is correct. Do not manufacture findings.
+```
+
+## Find vs propose
+
+These limits bound the **fix**, never the **search**. A reviewer should still
+report:
+
+- a bug that only fires on an unusual input, **if that input actually occurs**
+  here (a documented example that produces it counts as occurring);
+- a real defect in existing hash/fingerprint code — the ban is on *proposing new*
+  binding, not on reading what exists;
+- a case where the code and its own documentation disagree.
+
+Worded the wrong way, "no corner cases" would suppress real findings. The test is
+not *how rare does this sound*, it is **does this happen here**.
+
+## The one exception
+
+Code that **executes remote commands, starts a network service, or installs an
+MCP server** is different. Trust-boundary findings there are in scope and the
+default is strict — that code runs on a user's GPU box with their credentials.
+`/experiment-queue`, `/run-experiment`, `/vast-gpu`, `/serverless-modal`,
+`mcp-servers/*` and the installers are the surfaces this covers.
+
+## Why this exists
+
+Not a style preference. Measured over one day of real maintenance review
+(2026-08-10, ~10 rounds of gpt-5.6-sol at xhigh/ultra), every discarded proposal
+fell in these categories: adding hash binding to a gate that already had four
+layers, adding a lint to mechanize a rule the corpus deliberately keeps as prose,
+adding a dual-spelling compatibility layer for what was a typo, and hardening a
+race that closes in milliseconds. None was self-limiting; each had to be refused
+by hand.
+
+The same reviewer, in the same rounds, found five genuine defects that had shipped
+— including one that killed every job in the experiment queue at 60 seconds. The
+reviewer is worth its cost. This contract is how that value arrives without the
+tax.
+
+## Related
+
+- [`acceptance-gate.md`](acceptance-gate.md) — what a reviewer verdict may and may not settle.
+- [`reviewer-independence.md`](reviewer-independence.md) — what the reviewer is allowed to see.
+- [`reviewer-routing.md`](reviewer-routing.md) — which backend, which effort tier.