fenix-claude-plugin 0.1.3 → 0.2.0

package/skills/fenix-application/references/patent-review.md

@@ -1,6 +1,6 @@
 # Patent Application Review
 
-**Version: 21**
+**Version: 48**
 
 Structured pre-filing review. Catches structural defects, malformed claims, patent profanity, and missing spec support.
 
@@ -13,7 +13,9 @@ Trigger when the user asks to review, audit, critique, or red-line a patent appl
 1. Uploaded .docx  --  extract and identify sections: Title, Background, Detailed Description, Claims.
 2. Multiple files  --  extract each, merge for review.
 3. Pasted text  --  work with what is present.
-4. Fenix project  --  call `get_project({ projectId, include: ["claims","sections"] })`.
+4. Fenix project  --  call `read {resource:"project", options:{projectId, include: ["claims","sections"]}}`.
+
+**Reading (and returning) a `.docx` without losing content.** Extract the sections directly from the file. If a single read comes back truncated (long specs do), pull it **in parts / section by section** so you review the WHOLE document  --  a truncated read silently drops the tail (usually the claims), and you would miss real issues. If the attorney wants a red-lined `.docx` back, edit the uploaded file **in place** with targeted changes; do **not** reconstruct the whole document from its read-back text (that is what produces "the file got truncated"). Reopen and confirm every section is present before delivering.
 
 ## Severity
 - 🔴 Blocker  --  must fix before filing
@@ -26,8 +28,10 @@ Trigger when the user asks to review, audit, critique, or red-line a patent appl
 - Intro (before FIG. 1): must include the problem, how the invention solves it, key term definitions, and an advantages paragraph (see `patent-review-advantages.md`).
 - Per-figure descriptions: at least two paragraphs per figure.
 - Reference numerals: every figure component must have a numeral, appear in the spec with that numeral, and be described. Flag orphans in either direction and numeral collisions.
+- Figure component generation: every component of a **non-boilerplate** figure must have `generateElement: true`  --  a component with it `false`/absent produces **no Visio box and no description text** (it is treated as background/boilerplate). Flag any non-boilerplate figure whose components lack `generateElement: true`. Boilerplate figures correctly leave it off. (Include `figures` in `read {resource:"project"}` to inspect the components.)
 - Cross-reference to provisional/foreign priority if applicable.
 - Equations formatted correctly; not in claims.
+- Fonts: flag any non-standard or web font (e.g. Google Sans, Roboto). The USPTO requires legible, standard, fully-embedded fonts (Times New Roman, Arial, Courier)  --  MPEP 608.01 / 37 CFR 1.52(b); non-standard or non-embedded fonts get rejected at Patent Center upload or draw a Notice to File Corrected Application Papers.
 
 ## Section 2  --  Claims
 Count: 3 INDs, 20 total. Acceptable: Method/CRM/System or any set with two or more classes and two or more scopes. Only flag if fewer than 3 INDs, all same scope, or all same statutory class.

package/skills/fenix-application/references/patent-safe.md

@@ -1,6 +1,6 @@
 # Patent Language Guidelines
 
-**Version: 21**
+**Version: 48**
 
 This file is the single source of truth for Fenix patent language and profanity rules.
 Both the patent drafting workflow (references/claims.md) and the patent review workflow (references/patent-review.md) reference this file for profanity guidance.

package/skills/fenix-application/references/patent.md

@@ -1,21 +1,21 @@
 # Patent Drafting Workflow
 
-**Version: 21**
+**Version: 48**
 
 ## Phase overview
-- **Phase 1  --  Claims**: Read `references/claims.md` -> draft one-by-one (confirm each) -> save the whole set **once** at the end with `save_project(type=claims)`. Do not save after each claim.
-- **Phase 2  --  Figures**: agree the figure list (`save_project(type=figures)`), then draft each figure's content one-by-one (confirm each) and save the whole set **once** at the end with `save_project(type=figures)`. Do not save per figure. Then run `scripts/calculate_figure_layout.py` (pipe figure JSON) -> check warnings.
-- **Spec**: `get_project({ projectId, include: ["claims","figures","sections"] })` -> generate each section (see `references/spec.md`) -> `save_project(type=section)` per section as the user confirms it.
+- **Phase 1  --  Claims**: Read `references/claims.md` -> draft one-by-one (confirm each) -> save the whole set **once** at the end with `write {resource:"project", action:"save", options:{type:"claims"}}`. Do not save after each claim.
+- **Phase 2  --  Figures**: agree the figure list (`write {resource:"project", action:"save", options:{type:"figures"}}`), then draft each figure's content one-by-one (confirm each) and save the whole set **once** at the end with `write {resource:"project", action:"save", options:{type:"figures"}}`. Do not save per figure. Then run `scripts/calculate_figure_layout.py` (pipe figure JSON) -> check warnings.
+- **Spec**: `read {resource:"project", options:{projectId, include: ["claims","figures","sections"]}}` -> generate each section (see `references/spec.md`) -> `write {resource:"project", action:"save", options:{type:"section"}}` per section as the user confirms it.
 
-**Do not print (generate a document/file) automatically.** Printing is a separate, explicit step -- only call `print_patent` when the user asks for the drawings, the spec document, or an export. **After any `print_patent` call, always show the returned download URL/link in your reply** -- never run a print and leave the result unshown.
+**Do not print (generate a document/file) automatically.** Printing is a separate, explicit step -- only call `read {resource:"patent-document"}` when the user asks for the drawings, the spec document, or an export. **After any `read {resource:"patent-document"}` call, always show the returned download URL/link in your reply** -- never run a print and leave the result unshown.
 
 ## Intake
-1. Matter  --  `get_project({ identifier })` (exact) or `get_project({ query })` (keyword search)
-2. Template/source  --  optionally call `list_patent_templates` first to show the user the available starting templates (name, figure/claim counts) so they can pick one; then import the chosen template (or copy from another project) via `get_project({ projectId, templateId, include: ["figures","sections","template"] })` or `get_project({ projectId, sourceProjectId, include: ["figures","sections","template"] })`
+1. Matter  --  `read {resource:"project", options:{identifier}}` (exact) or `read {resource:"project", options:{query}}` (keyword search)
+2. Template/source  --  optionally call `read {resource:"patent-templates"}` first to show the user the available starting templates (name, figure/claim counts) so they can pick one; then import the chosen template (or copy from another project) via `read {resource:"project", options:{projectId, templateId, include: ["figures","sections","template"]}}` or `read {resource:"project", options:{projectId, sourceProjectId, include: ["figures","sections","template"]}}`
 3. Disclosure  --  user describes or run `references/disclosure.md` interview
 4. Inventors  --  if the user provides an inventor information sheet, declaration, or ADS (or just names), call `add_inventors({ projectId, inventors: [...] })`. Interpret the document into the Fenix person schema -- `{ name, firstName, middleName, lastName, prefix, suffix, address1, city, stateName, country, postalCode, residenceCity, residenceState, residenceCountry, email, registrationNumber }` (only `name` is required) -- or pass just names. Any number of inventors; they are upserted by name (no duplicates) and added to the matter. Never pass `clientDb`.
 5. Phase  --  ask which to start
 
-**Use the imported data as-is -- do NOT drop or stub any of it.** When a template/source is imported, the response carries real figure data (brief descriptions, components, stencils/placeholders, steps, numbering) and sections. Carry every field through to `save_project` exactly as imported; only fill in genuinely missing pieces. Never replace an imported brief description, component list, stencil/placeholder, or section with a placeholder, an old stub, or invented content. If a field looks empty, confirm with the user rather than substituting a stub.
+**Use the imported data as-is -- do NOT drop or stub any of it.** When a template/source is imported, the response carries real figure data (brief descriptions, components, stencils/placeholders, steps, numbering) and sections. Carry every field through to `write {resource:"project", action:"save"}` exactly as imported; only fill in genuinely missing pieces. Never replace an imported brief description, component list, stencil/placeholder, or section with a placeholder, an old stub, or invented content. If a field looks empty, confirm with the user rather than substituting a stub.
 
-Call `save_project(name, disclosure, templateId|sourceProjectId)` after intake.
+Call `write {resource:"project", action:"save", options:{name, disclosure, templateId}}` (or `sourceProjectId` in place of `templateId`) after intake.

package/skills/fenix-application/references/spec-guidance.md

@@ -1,6 +1,6 @@
 # Spec Section Guidance
 
-**Version: 21**
+**Version: 48**
 
 ## Background
 

package/skills/fenix-application/references/spec.md

@@ -1,18 +1,29 @@
 # Spec Drafting Workflow
 
-**Version: 21**
+**Version: 48**
 
 ## Start
-`get_project({ projectId, include: ["claims","figures","sections"] })`  --  loads claims, figure list, and any previously saved sections.
+`read {resource:"project", options:{projectId, include: ["claims","figures","sections"]}}`  --  loads claims, figure list, and any previously saved sections.
 
 ## Section order
 Field Of The Invention -> Background -> Summary -> Brief Description -> Introduction -> Figure 1 -> Figure 2 -> ... -> Figure N -> Examples -> Clauses -> Additional Description -> Glossary -> Abstract
 
+## Section names — exact save keys (read before saving ANY section)
+`write {resource:"project", action:"save", options:{type: "section", sectionName, paragraphs}}` stores content under **whatever `sectionName` you pass — it does not validate or normalize the name**, and the document renderer looks each section up by its **exact key (case- and wording-sensitive)**. A mis-cased, re-worded, or invented section name is silently stored under that stray key and **never appears in the generated document** — so it looks like nothing saved. Use exactly these keys:
+
+`Field Of The Invention`, `Background`, `Summary`, `Brief Description`, `Introduction`, `Examples`, `Clauses`, `Additional Description`, `Glossary`, `Abstract` — plus one `Figure N` key per figure (`Figure 1`, `Figure 2`, … `Figure 10`).
+
+**Never save to a "Detailed Description" section — it is not a stored section.** The detailed description is **virtual**: it is assembled at print time from the per-figure `Figure N` sections. Content saved under `Detailed Description` (or `Detailed Description of the Invention`, etc.) is **ignored** whenever the matter has figures. In particular, an **introduction** is its own `Introduction` section — do **not** put it (or anything else) under `Detailed Description`.
+
+After each save, the response returns `sectionNames` (all section keys now on the matter). Glance at it: every key should be one of the canonical names above; a key that is not means that content will not render.
+
+**Put the whole section in ONE `paragraphs` element.** The spec-section editor reads only `paragraphs[0]`, so content split across multiple array elements is dropped there (everything after the first element disappears). Save each section's body as a **single** element — one HTML string holding all the `<p>…</p>` blocks: `paragraphs: ["<p>First paragraph.</p><p>Second paragraph.</p>"]`, **not** `["<p>First paragraph.</p>", "<p>Second paragraph.</p>"]`. (The print renderer splits the `<p>` tags back apart, so the Word output is unchanged.)
+
 ## Per-section loop
 For each section:
 (a) Generate the section text (see generation rules below). If already saved in `sections`, show that text first.
 (b) Show to user  --  **END TURN**. Ask "Does [Section Name] look right, or any changes?"
-(c) After user confirms: `save_project({ type: "section", sectionName, paragraphs })` immediately. Never accumulate.
+(c) After user confirms: `write {resource:"project", action:"save", options:{type: "section", sectionName, paragraphs}}` immediately. Never accumulate.
 
 ## How to generate each section
 
@@ -41,9 +52,8 @@ Read `references/figure-description.md` for the full protocol. Key rules:
 Read `references/spec-guidance.md` for the drafting prompt for each section.
 
 ## Editor (accordion)
-**Always ask the user whether they want to open the spec editor to review/edit all sections at once** -- e.g. "Want me to open the spec editor so you can review every section together?" Only open it if they say yes. **In Cowork, prefer the live spec sections editor:** `get_live_artifacts({ name: "sections-editor" })`, substitute `__PROJECT_ID__` (project id) and `__SERVER_PREFIX__` (your MCP tool prefix, e.g. `mcp__<id>__` — see `references/editors.md`) in the returned HTML, and open it — it loads the current sections and **saves them itself**; when the user pastes a `[SECTIONS SAVED - sectionsRev N]` block, apply that delta and do **not** call `save_project` again (see `references/editors.md`). **Otherwise (non-Cowork), open `assets/spec_editor.html`** with `INITIAL_CONTENT` set to the full sections object (each key a section name, including each "Figure N" as its own section). Each section is a collapsible accordion item with a text box (blank line = new paragraph). The user opens any section to edit, can add/remove sections, then clicks Copy for Save. On `[EDITOR SUBMIT - sections]`, strip the prefix and call `save_project({ type: "sections", sections: {...} })` with the returned object.
-
+**Always ask the user whether they want to open the spec editor to review/edit all sections at once** -- e.g. "Want me to open the spec editor so you can review every section together?" Only open it if they say yes. To open it: call `write {resource:"context", options:{ids: { projectId }, label: "<matter number>"}}` to bind the matter, then tell the user to open the **installed Fenix Patent Editor** (Specification view) from their artifacts sidebar. **Never write, edit, or substitute anything into the artifact**; see `references/editors.md`. When the user pastes a `[SECTIONS SAVED - sectionsRev N]` block, apply that delta and do **not** call `write {resource:"project", action:"save"}` again.
 ## Notes
 - Claims are already saved  --  do not include them as a section here.
-- For the one-at-a-time flow, use `save_project(type=section)` directly after the user confirms each section. For a full review pass, use the accordion editor above and save all at once with `save_project(type=sections)`.
-- **Do NOT print automatically.** After all sections are saved, tell the user the specification is complete and ask whether they want the Word document generated. Only call `print_patent(type=spec)` when the user explicitly asks for it. **When you do, show the returned download URL/link in your reply** (e.g. "Specification ready: <url>") -- never run the print and leave the result unshown.
+- For the one-at-a-time flow, use `write {resource:"project", action:"save", options:{type:"section"}}` directly after the user confirms each section. For a full review pass, use the accordion editor above and save all at once with `write {resource:"project", action:"save", options:{type:"sections"}}`.
+- **Do NOT print automatically.** After all sections are saved, tell the user the specification is complete and ask whether they want the Word document generated. Only call `read {resource:"patent-document", options:{type:"spec"}}` when the user explicitly asks for it. **When you do, show the returned download URL/link in your reply** (e.g. "Specification ready: <url>") -- never run the print and leave the result unshown.

package/skills/fenix-application/scripts/figure_strategy_server.py

@@ -0,0 +1,136 @@
+#!/usr/bin/env python3
+"""
+Serve the figure-strategy worksheet and persist the user's edits to disk.
+
+Why this exists: a page loaded from `file://` cannot write back to itself, so an HTML file the
+assistant drops in the sandbox is write-only -- the user types into it and the assistant, re-reading
+the file, still sees its own original markup. This server closes the loop:
+
+    browser (edits)  --POST /save-->  figure-strategy.json  --read-->  assistant
+
+Run it, hand the user the printed URL (NOT the .html path), and then read `figure-strategy.json`
+whenever you want their current plan. That JSON is the source of truth; the HTML is just the view.
+
+    python3 figure_strategy_server.py --dir /path/to/sandbox [--port 8765]
+
+Serves:
+    GET  /                     figure-strategy.html
+    GET  /figure-strategy.json current state (so the page can rehydrate on reload)
+    POST /save                 replace the state; body is the whole JSON document
+"""
+
+import argparse
+import json
+import os
+import shutil
+import tempfile
+import threading
+from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer
+
+HTML_NAME = "figure-strategy.html"
+STATE_NAME = "figure-strategy.json"
+
+# The page autosaves on every keystroke (debounced), so writes are frequent and can overlap.
+_write_lock = threading.Lock()
+
+
+def _write_state_atomically(path: str, raw: bytes) -> None:
+    """Write via a temp file + replace, so a half-written save can never truncate the plan."""
+    directory = os.path.dirname(path) or "."
+    fd, tmp = tempfile.mkstemp(dir=directory, prefix=".figure-strategy-", suffix=".tmp")
+    try:
+        with os.fdopen(fd, "wb") as f:
+            f.write(raw)
+            f.flush()
+            os.fsync(f.fileno())
+        os.replace(tmp, path)
+    except BaseException:
+        if os.path.exists(tmp):
+            os.unlink(tmp)
+        raise
+
+
+class Handler(BaseHTTPRequestHandler):
+    directory = "."
+
+    # Keep the console readable: one line per save, no per-asset request spam.
+    def log_message(self, fmt, *args):  # noqa: A003
+        if "POST" in (fmt % args):
+            print("saved figure-strategy.json")
+
+    def _send(self, code, body=b"", content_type="text/plain; charset=utf-8"):
+        self.send_response(code)
+        self.send_header("Content-Type", content_type)
+        self.send_header("Content-Length", str(len(body)))
+        # The page reloads its own state; never let a stale cache mask a save.
+        self.send_header("Cache-Control", "no-store")
+        self.end_headers()
+        if body:
+            self.wfile.write(body)
+
+    def _path(self, name):
+        return os.path.join(self.directory, name)
+
+    def do_GET(self):
+        route = self.path.split("?", 1)[0]
+
+        if route in ("/", "/index.html", "/" + HTML_NAME):
+            path = self._path(HTML_NAME)
+            if not os.path.exists(path):
+                return self._send(404, f"{HTML_NAME} not found in {self.directory}".encode())
+            with open(path, "rb") as f:
+                return self._send(200, f.read(), "text/html; charset=utf-8")
+
+        if route == "/" + STATE_NAME:
+            path = self._path(STATE_NAME)
+            if not os.path.exists(path):
+                return self._send(200, b"{}", "application/json; charset=utf-8")
+            with open(path, "rb") as f:
+                return self._send(200, f.read(), "application/json; charset=utf-8")
+
+        return self._send(404, b"not found")
+
+    def do_POST(self):
+        if self.path.split("?", 1)[0] != "/save":
+            return self._send(404, b"not found")
+
+        length = int(self.headers.get("Content-Length") or 0)
+        raw = self.rfile.read(length) if length else b""
+
+        # Validate before touching disk: a malformed body must not clobber a good plan.
+        try:
+            parsed = json.loads(raw.decode("utf-8"))
+        except (ValueError, UnicodeDecodeError) as e:
+            return self._send(400, f"invalid JSON: {e}".encode())
+
+        pretty = json.dumps(parsed, indent=2, ensure_ascii=False).encode("utf-8")
+        with _write_lock:
+            _write_state_atomically(self._path(STATE_NAME), pretty)
+
+        return self._send(200, b'{"ok":true}', "application/json; charset=utf-8")
+
+
+def main():
+    ap = argparse.ArgumentParser(description=__doc__)
+    ap.add_argument("--dir", default=".", help="directory holding figure-strategy.html")
+    ap.add_argument("--port", type=int, default=8765)
+    args = ap.parse_args()
+
+    Handler.directory = os.path.abspath(args.dir)
+
+    if not os.path.exists(os.path.join(Handler.directory, HTML_NAME)):
+        raise SystemExit(f"{HTML_NAME} not found in {Handler.directory} — write it first.")
+
+    # Bind to loopback only: this serves a client's unpublished invention.
+    server = ThreadingHTTPServer(("127.0.0.1", args.port), Handler)
+    print(f"figure strategy: http://127.0.0.1:{args.port}/")
+    print(f"edits persist to: {os.path.join(Handler.directory, STATE_NAME)}")
+    print("give the user the URL above — NOT the .html path (file:// cannot save).")
+    try:
+        server.serve_forever()
+    except KeyboardInterrupt:
+        server.shutdown()
+
+
+if __name__ == "__main__":
+    main()

package/skills/fenix-diagram/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: fenix-diagram
+description: >-
+  Render a patent figure as SVG: turn a claim (or a described process) into a top-to-bottom data-flow flowchart in the Fenix drawing style -- square-cornered steps, rounded input/output boxes, filled arrows, S-curve lead lines, and reference numerals.
+---
+
+# Fenix Diagram
+
+**Skill version: 2** (authoritative version is in the top-level `VERSION` file; this line is for reference only).
+
+## Triggers
+
+- make a diagram
+- make a figure
+- draw a flowchart
+- render the claim as a figure
+- patent figure svg
+- data-flow diagram
+- draw claim 1
+- generate a figure
+- flowchart for this method
+- create a patent drawing
+
+## Customization
+
+User overrides for this skill live in a `CUSTOMIZE.md` file in this skill directory. This file is **not shipped with the skill** -- it belongs to the user. **If `CUSTOMIZE.md` does not already exist in this skill directory, create it now** containing exactly the single line `place custom instructions here`. **If it already exists, never overwrite it** -- it holds the user's own instructions.
+
+Before applying any workflow in this skill, read `CUSTOMIZE.md`. If it contains anything other than the placeholder text "place custom instructions here", treat its contents as user overrides that take precedence over the default instructions in this SKILL.md and its reference files.
+
+Apply the custom overrides **only as long as the result still satisfies every structured-output contract** this skill depends on, including:
+- the JSON shapes passed to `save_project` (claims, figures, sections)
+- the figure ElementSchema (`type`, `label`, `number`, `text`) and component numbering rules
+- the spec section names and ordering required by the save/print tools
+
+Custom instructions may freely change tone, phrasing, default counts, section preferences, review emphasis, and similar. If a custom instruction would break a required format, follow the default format and tell the user which customization could not be applied and why.
+
+## Contents
+- `references/diagram-svg-guide.md`  --  full SVG generation guide: conventions, building the element list from a claim, canvas/layout, reusable snippets (arrowhead + drop-shadow defs, boxes, arrows, labels, numerals), the S-curve lead line, and a finalizing checklist
+
+## When to use this skill
+
+Trigger whenever the user wants a patent-style figure rendered as an SVG from a claim or a described process:
+- "make a diagram / figure for claim 1", "render this claim as a figure", "draw the flowchart"
+- "generate a patent figure SVG", "data-flow diagram", "FIG. N for this method"
+
+## How to use
+
+Read `references/diagram-svg-guide.md` and follow it end to end:
+1. **Build the element list from the claim**  --  each verb clause is a **step** (square box); each noun that flows between steps is an **input/output** (rounded box); side inputs branch in; two inputs to the first step (or two outputs of the last) share a row. Assign numerals top-to-bottom by 5, starting at FIG## * 100 + 5.
+2. **Lay out** on the 680-wide canvas: main column centered at x=300 (box width 240), side inputs at x=448, paired peers on one row.
+3. **Assemble the SVG** from the reusable snippets: the filled curvy arrowhead + drop-shadow `<defs>`, the single shadowed box group, flow arrows, centered labels, S-curve lead lines, and edge-anchored numerals.
+4. **Run the finalizing checklist** (section 6) before returning the SVG.
+
+Return the SVG only  --  do **not** include a "FIG. ##" caption (the figure template's background page supplies it).

package/skills/fenix-diagram/VERSION

@@ -0,0 +1 @@
+2

package/skills/fenix-diagram/references/diagram-svg-guide.md

@@ -0,0 +1,271 @@
+# Patent-Style Data-Flow Flowchart — SVG Generation Guide
+
+**Version: 2**
+
+Instructions for generating a patent figure like FIG. 10 (a claim rendered as a
+top-to-bottom data-flow diagram): square-cornered **steps**, rounded-corner
+**inputs/outputs**, arrows connecting them, and an S-curve **lead line** with a
+reference numeral on every element.
+
+---
+
+## 1. Conventions
+
+| Element | Shape | Meaning |
+|---|---|---|
+| **Step** (method operation) | Rectangle, **square corners** (`rx="0"`) | An action from the claim: "obtaining", "extracting", "repositioning", "generating". |
+| **Input / Output** (data) | Rectangle, **rounded corners** (`rx="16"`) | A datum produced or consumed by a step: an image, entity information, a pose constraint, a model, the result. |
+| **Flow** | Straight line with a **filled** arrowhead | Direction of data flow, generally top-to-bottom. |
+| **Lead line** | Short **S-curve**, no arrowhead | Connects each box to its reference numeral. |
+| **Reference numeral** | Plain text, `FIG## + nn` | Increments by **5** in reading order (top-to-bottom). |
+| **Component enclosure** (optional) | Rectangle, **square corners**, **dotted** stroke, **no shadow** | The physical component that performs a step (e.g. "Encoder"). Wraps the step box; flow arrows touch the **outer dotted** box, not the inner step box. |
+
+Black line art on white. Boxes carry a subtle **black drop shadow** to the
+bottom-right for depth; arrowheads are **filled** solid triangles with gently
+curved edges. Otherwise no color, no fills other than white, no shading.
+
+---
+
+## 2. Building the element list from a claim
+
+1. Read the independent claim. Each **verb clause** ("obtaining X", "extracting
+   Y") becomes a **step** (square box).
+2. Each **noun that flows between steps** — the thing obtained, extracted,
+   produced, or consumed — becomes an **input/output** (rounded box). Place the
+   output of one step as the input of the next.
+3. **Side inputs** (a constraint, a model, a reference the step uses but that is
+   not produced by the prior step) branch in from the side into the step that
+   uses them (e.g., "pose constraint" → reposition; "image generation model" →
+   generate).
+   - **Parallel inputs/outputs — same row.** When the **first** step consumes two
+     (or more) inputs, or the **last** step produces two (or more) outputs, place
+     them **side by side on one row** and fan the arrows straight down into (or
+     out of) the step — do **not** put one above the step and the other coming in
+     from the side. A side input is reserved for something merging into a *middle*
+     step; peers of the first/last step share a row so the symmetry reads clearly.
+4. Assign numerals in **reading order, top to bottom**, incrementing by 5,
+   starting at `FIG## * 100 + 5`. For FIG. 10 that is 1005, 1010, 1015 … For
+   FIG. 3 it would be 305, 310, 315 …
+
+**Worked example (claim 1 → FIG. 10):**
+
+| # | Box | Type |
+|---|---|---|
+| 1005 | Obtain image | step |
+| 1010 | Image | output |
+| 1015 | Extract entity information | step |
+| 1020 | Entity information (identity, location) | output |
+| 1025 | Pose constraint | side input |
+| 1030 | Reposition entities | step |
+| 1035 | Modified entity information (second arrangement) | output |
+| 1040 | Image generation model | side input |
+| 1045 | Generate modified image | step |
+| 1050 | Modified image | output |
+
+**Second worked example — two inputs → intermediate → final (claim 1 → FIG. 10):**
+
+> A method comprising: receiving a first audio signal and a second audio signal;
+> combining them to produce a mixed signal; applying a noise-reduction filter to
+> the mixed signal to produce a filtered signal; and encoding the filtered signal
+> to produce an output audio file.
+
+Both inputs sit on the **same top row** (1005 left, 1010 right) and fan down into
+the combine step:
+
+| # | Box | Type |
+|---|---|---|
+| 1005 | First audio signal | input (row, left) |
+| 1010 | Second audio signal | input (row, right) |
+| 1015 | Combine signals | step |
+| 1020 | Mixed signal | output |
+| 1025 | Apply noise-reduction filter | step |
+| 1030 | Filtered signal | output |
+| 1035 | Encode signal | step |
+| 1040 | Output audio file | output |
+
+---
+
+## 3. Canvas and layout
+
+- `viewBox="0 0 680 H"` — keep width **680**; set **H** to the last element's
+  bottom + ~30px. Do **not** add a "FIG. ##" caption — the figure number is
+  supplied by the template's background page, so leave it out of the SVG.
+- Draw a white background rect first: `<rect x="0" y="0" width="680" height="H" fill="#ffffff"/>`.
+- **Main column** centered at `x=300`, box width **240** (`x=180`→`420`).
+- **Side inputs** at `x=448`, width **150** (`x=448`→`598`).
+- Vertical rhythm: box height **46**, gap **~46** between a box bottom and the
+  next box top (leave a longer gap where a side input merges).
+- **Paired-row inputs/outputs.** For two peers sharing a row, use two narrower
+  boxes width **190**, centered as a pair on `x=300`: left `x=90`→`280`
+  (center 185), right `x=320`→`510` (center 415). Fan two arrows from the pair's
+  bottom centers into the step's top edge, e.g. `185,88 → 235,138` and
+  `415,88 → 365,138` (mirror the endpoints for a paired-output last step). Number
+  left-to-right (left = lower numeral). Put the left peer's numeral + lead line on
+  its **left** edge (`x=90`) and the right peer's numeral + a **mirrored** lead
+  line on its **right** edge (`x=510`).
+- Draw order (so strokes layer cleanly): connectors → **shadowed box group**
+  (step boxes → I/O boxes) → labels → lead lines → numerals. (No caption — the
+  template's background page carries the "FIG. ##" label.)
+- Wrap all step + I/O boxes in a single `<g filter="url(#sh)">` so the drop
+  shadow applies once to the whole group (connectors, labels, lead lines, and
+  numerals stay outside the group so they cast no shadow).
+
+---
+
+## 4. Reusable snippets
+
+### Defs — filled curvy arrowhead + drop shadow
+```xml
+<defs>
+  <marker id="ar" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="8" markerHeight="8" orient="auto-start-reverse">
+    <path d="M1,1 Q6,3 9,5 Q6,7 1,9 Q3.2,5 1,1 Z" fill="#111111" stroke="#111111" stroke-width="0.8" stroke-linejoin="round"/>
+  </marker>
+  <!-- Expanded drop shadow (feDropShadow needs Inkscape 1.0+; this chain works everywhere) -->
+  <filter id="sh" x="-20%" y="-20%" width="140%" height="140%">
+    <feGaussianBlur in="SourceAlpha" stdDeviation="0.6"/>
+    <feOffset dx="1.5" dy="1.5" result="off"/>
+    <feFlood flood-color="#000000" flood-opacity="0.85"/>
+    <feComposite in2="off" operator="in"/>
+    <feMerge>
+      <feMergeNode/>
+      <feMergeNode in="SourceGraphic"/>
+    </feMerge>
+  </filter>
+</defs>
+```
+The arrowhead is a solid triangle whose two long sides bow outward (`Q6,3` /
+`Q6,7`) and whose back edge is slightly concave (`Q3.2,5`), giving a soft swept
+look. The shadow is a tight, near-opaque black offset — crisp thin edge, not a
+gray halo. Tune `dx`/`dy` (offset), `stdDeviation` (blur), and `flood-opacity`.
+
+### Shadowed box group
+```xml
+<g filter="url(#sh)">
+  <!-- step boxes (square corners) -->
+  <rect x="180" y="Y" width="240" height="46" fill="#ffffff" stroke="#111111" stroke-width="2"/>
+  <!-- input/output boxes (rounded corners) -->
+  <rect x="180" y="Y" width="240" height="46" rx="16" fill="#ffffff" stroke="#111111" stroke-width="2"/>
+</g>
+```
+
+### Step box (square corners)
+```xml
+<rect x="180" y="Y" width="240" height="46" fill="#ffffff" stroke="#111111" stroke-width="2"/>
+```
+
+### Input/output box (rounded corners)
+```xml
+<rect x="180" y="Y" width="240" height="46" rx="16" fill="#ffffff" stroke="#111111" stroke-width="2"/>
+```
+
+### Flow arrow
+```xml
+<line x1="300" y1="Ybottom" x2="300" y2="Ytop_next" stroke="#111111" stroke-width="2" marker-end="url(#ar)"/>
+```
+
+### Label (centered; use two `<text>` lines for long labels — SVG does not wrap)
+```xml
+<text x="300" y="Yc" font-family="Arial, sans-serif" font-size="13" text-anchor="middle">Reposition entities</text>
+```
+
+### Reference numeral
+Anchor the numeral on the edge nearest its lead line and offset it by a small
+gap, so numeral **width never crowds the lead line** regardless of digit count
+(a 3-digit `905` and a 4-digit `1115` then keep the same clearance):
+- **Left-side numeral** (lead line starts at `x≈155`): right-anchor it just
+  before that — `text-anchor="end"` at `x=152` (~3px gap).
+- **Right-side numeral** (mirrored lead line, free end at `x≈535`): left-anchor
+  it just after — `text-anchor="start"` at `x=538`.
+- **Left input of a paired row** (lead line starts at `x≈65`): `text-anchor="end"`
+  at `x=62`.
+
+```xml
+<!-- left-side numeral -->
+<text x="152" y="Yc" font-family="Arial, sans-serif" font-size="15" text-anchor="end">1030</text>
+```
+
+If you prefer to keep numerals center-anchored, instead nudge the center **away
+from the lead line by ~4px for each digit beyond three** (e.g. 3-digit centered
+at `x=138`; 4-digit at `x=134`). Anchoring is preferred — it needs no per-width math.
+
+### Component enclosure (optional — show what performs a step)
+When a step is performed by a named component, wrap the step box in a **dotted,
+square-cornered** rectangle with **no shadow**, and label the component (italic)
+at the top inside the enclosure. Pad ~14px on the sides and bottom of the step
+box and ~30px on top (to seat the label). **Retarget the flow arrows to the outer
+dotted box**, not the inner step box: the incoming arrow ends at the enclosure's
+top edge and the outgoing arrow starts at its bottom edge.
+
+**Spacing is measured to the enclosure, not the inner step box.** Treat the whole
+dotted box as the row element: leave the normal ~46px gap between the previous
+box's bottom and the enclosure's top, and between the enclosure's bottom and the
+next box's top. Because the enclosure is taller than a bare step (the ~30px top
+pad + ~14px bottom pad), everything below it shifts down and the `viewBox` height
+grows accordingly. The step's numeral/lead line still points at the **inner**
+step box (at its center), even though the lead line crosses the dotted border.
+
+```xml
+<!-- draw OUTSIDE the shadowed box group (no shadow), before/behind the step box -->
+<rect x="166" y="508" width="268" height="90" fill="none" stroke="#111111" stroke-width="1.5" stroke-dasharray="4 3"/>
+<text x="300" y="527" font-family="Arial, sans-serif" font-size="12" font-style="italic" text-anchor="middle">Encoder</text>
+```
+Worked example (from FIG. 11): the previous box (output) bottom is `462`; the
+enclosure sits `46px` below at `x=166,y=508,w=268,h=90` (so `508`→`598`); the
+inner step box is `x=180,y=538,w=240,h=46`. The incoming arrow runs `462`→`508`
+(enclosure top); the outgoing arrow runs `598`→`644` (enclosure bottom to the
+next box `46px` further down).
+
+---
+
+## 5. The S-curve lead line (the important part)
+
+Profile taken from the Visio **"Lead Line - Right"** stencil: two cubic Béziers
+that start and end at the same baseline with a shallow S wiggle, spanning ~25px.
+
+**Horizontal lead line** — numeral on the left at height `y`, curving into the
+box's left edge (`x≈180`). Substitute `y`:
+```xml
+<path d="M155,{y} C162.64,{y-2.55} 164.04,{y-1.76} 165.51,{y-0.9} C170.14,{y+1.8} 175.36,{y+5.09} 180.46,{y}"
+      fill="none" stroke="#111111" stroke-width="1.4" stroke-linecap="round" stroke-linejoin="round"/>
+```
+
+**Vertical lead line** — numeral above a side box at column `x`, curving down
+onto the box top (`y0` = numeral-side start). Same profile rotated 90°:
+```xml
+<path d="M{x},{y0} C{x-2.55},{y0+7.64} {x-1.76},{y0+9.04} {x-0.9},{y0+10.51} C{x+1.8},{y0+15.14} {x+5.09},{y0+20.36} {x},{y0+25.46}"
+      fill="none" stroke="#111111" stroke-width="1.4" stroke-linecap="round" stroke-linejoin="round"/>
+```
+
+**Mirrored (right-edge) lead line** — for the right peer of a paired row, the
+numeral sits to the right and the curve enters the box's **right** edge (`xr`).
+Reflect the horizontal profile; e.g. for `xr=510`:
+```xml
+<path d="M535.46,{y} C527.82,{y-2.55} 526.42,{y-1.76} 524.95,{y-0.9} C520.32,{y+1.8} 515.1,{y+5.09} 509.54,{y}"
+      fill="none" stroke="#111111" stroke-width="1.4" stroke-linecap="round" stroke-linejoin="round"/>
+```
+
+Keep lead lines short (~24–26px run), no arrowhead, `stroke-width` ~1.4 with
+round caps. Place the numeral just beyond the free end of the curve. Lead lines
+and numerals stay **outside** the shadowed box group.
+
+---
+
+## 6. Checklist before finalizing
+
+- [ ] Every step is a **square** box; every input/output is a **rounded** box.
+- [ ] Each step's output feeds the next step's input; side inputs branch in.
+- [ ] Two inputs to the first step (or two outputs of the last step) sit **on the
+      same row**, fanned in/out — not one from the top and one from the side.
+- [ ] Every box has exactly one lead line and one numeral.
+- [ ] Numerals are edge-anchored (or width-nudged) so no numeral touches its lead
+      line — check the widest (4-digit) numerals.
+- [ ] Arrowheads are **filled** (solid, curvy) — not open line strokes.
+- [ ] All boxes sit in one `<g filter="url(#sh)">`; connectors, labels, lead
+      lines, and numerals are outside it (no stray shadows).
+- [ ] Numerals increase by **5** in top-to-bottom reading order, prefixed by the
+      figure number (`FIG## * 100 + 5, +10, …`).
+- [ ] No numeral collisions; no numeral appears in the drawing without a matching
+      description in the specification (and vice-versa).
+- [ ] All black on white; nothing relies on color.
+- [ ] `viewBox` height leaves ~30px below the last element; **no** "FIG. ##"
+      caption in the SVG (the template background supplies it).