Bridge context does not always inject enum globals; SCH wire coordinates must be a flat array (both undocumented)

**Summary**

While using this skill in production against a live EasyEDA Pro client (4 iterations of empirical testing, real bridge server + real client, not simulated), we found several places where documented behavior doesn't match observed runtime behavior, or where the SKILL.md is silent about a footgun that reliably trips up AI agents. Filing the narrowest, most factual subset first; a second, more opinionated proposal (workflow recommendations, failure-pattern catalog) will follow separately.

**Findings (reproducible, not opinion)**

| # | Area | Current doc says | Observed behavior | Fix proposed |
|---|------|-------------------|--------------------|---------------|
| 1 | Enum access in bridge `/execute` context | "use enum members, not raw numbers" (e.g. `EPCB_LayerId.TOP`) | Enum globals (`EPCB_LayerId`, `ESYS_NetlistType`, etc.) are **not always injected** into the bridge execution context — code that references them can throw "not defined" | Document a fallback: try the enum name first; on "not defined", fall back to the literal value documented in `references/enums/*.md` |
| 2 | `sch_PrimitiveWire.create()` coordinate format | Not specified | Must be passed as a **flat** array `[x1, y1, x2, y2, ...]`, not nested pairs `[[x,y],[x,y]]`. Passing nested pairs fails silently / produces wrong geometry | Add an explicit example with the flat-array format and an explicit "NOT nested" callout |
| 3 | Net label / net port placement on schematics | Not specified | Placing a net port/label **directly on a component pin** leaves the pin electrically floating. The port must be placed at the end of a short stub wire drawn from the pin, not on the pin coordinate itself | Add the stub-wire pattern as a documented Common Pattern, with a worked example |
| 4 | `pcb_Drc.check()` / schematic DRC (ERC) return semantics | Documented as returning a boolean | PCB DRC does return boolean, but **schematic DRC (ERC) return shape varies by version** — sometimes boolean, sometimes an array of `{type, count}` category objects. Also, **DRC is not idempotent**: repeated runs can accumulate UI markers and inflate violation counts | Document both return shapes, warn against re-running DRC multiple times per verification cycle, and note a netlist-dump fallback for independent connection verification |
| 5 | Concurrency model across multiple agents/windows | Not specified | The bridge server's "active document" is a **singleton per window**. Two agents writing to the same window race and cross-contaminate (components land on whichever page happens to be active) | Document a "one agent per window" rule: always `openDocument()` your target page before writing, and use `windowId`-scoped `/execute` calls for true parallelism |
| 6 | Window reconnection | Not specified | EasyEDA clients can disconnect/reconnect mid-session, which **rotates `windowId`**. A pinned `windowId` from before the reconnect becomes invalid, while document UUIDs remain stable | Document the detection (disconnection error on `/execute`) and recovery sequence (`GET /eda-windows` → re-select → re-open target document) |

**Why this matters for AI agents specifically**: every one of these is a case where an agent following the SKILL.md literally produces code that either throws, silently no-ops, or produces geometrically/electrically wrong output, and the failure mode gives no hint back to the correct fix (e.g. "EPCB_LayerId is not defined" doesn't say "fall back to the numeric value"; a net port silently not connecting doesn't say "you placed it on the pin instead of a stub"). These are exactly the class of gap that's expensive for a human to notice but cheap to document once found.

**Related**: #2 (`setState_Net().done()` clearing instead of updating a net) touches the same net-handling surface as finding #3 above and may share a root cause worth investigating together.

**Offer**: Happy to open a PR with the exact SKILL.md diff for these six items if maintainers are open to it. Keeping this as a separate, smaller PR from a follow-up workflow-recommendations PR (Tier 2) so the factual fixes aren't blocked on a larger design discussion.

Start by reading SKILL.md and the enum references in references/enums/*.md, then inspect the existing bridge /execute, schematic, DRC, and window-management documentation. Document the six reported runtime behaviors, including the flat wire-coordinate example, stub-wire pattern, variable ERC results, singleton-window guidance, and windowId reconnection recovery. Done means each behavior and its proposed fallback or workflow is covered explicitly without expanding into the separate recommendations proposal.

Written by the indexing model from the issue text.