@passioncode-ai/fabric-agent-adapter 0.80.2 → 0.82.0

package/plugins/fabric-agent-adapter/skills/working-with-fabric/references/project-board.md

@@ -209,26 +209,41 @@ adapted, so the reply informs; on a request still open, your reply as its target
 
 **A participant reply answers the request** (DEC-0098, DEC-0102). Your Project's `com.reply` (any message of yours
 whose `replyTo` is the request) moves a queued request to `answered`: no responder claims it any more and its
-deadline no longer expires it; only the requester can still cancel it. So reply as a participant only when the reply
-is the answer: you did the work, you say why it will not be done, or you are doing it and give its state with the
-nearest date (Answering at once, below); the result then follows in the same thread as a second reply. If your Project's
-service responder should still do the work (`com.status`'s slot for the capability is `active` or `stale`, or `absent` at a
-generation of 1 or more: a holder enrolled on it), do
-not reply on the request: tell the person and leave it queued. A session whose own `com.enroll` is refused
-`not_authorized` has no route to the grant (before Fabric 0.3.17 every session; from it, where CO-506 grants nothing:
-an organization's machine, no live credential, a standing denial, a full ask queue): when its capability's slot is
-`absent` at generation 0 (no service of the project ever held it),
-it answers the request once that it cannot be taken now and why, does no work on it without the slot, then asks the
-operator once (at any other slot state it sends no reply and still asks, FAA-241) with `fabric_question_ask` (`kind: access`, `about: board.gate.<capability>`, the `commandId` that
-`python3 <skill-dir>/scripts/fabric_session.py gate-id <request>` prints, the same a run uses, and a `text` naming the request, the gate and what
-opens it; without Python, no `commandId` can be made: tell the person only), tells the person (the question stays
-filed even when that is the operator: Fabric keeps its `about` and settles nothing by it yet, CO-519), and stops handling
-that request without waiting (Fabric's `board.read-at-start` rule and `com.enroll`'s own tool description say the
-same since main `4f3c742a`: the question since `603da12f` (CO-517) in the rule and `12d57bdd` in the description, the slot condition since
-`dbfbfce4` and `12d57bdd`, all in Fabric 0.3.17;
-on Fabric 0.3.16 this rule wins). Never write "it stays queued" in a reply: the reply itself ends the queue. A
-run Fabric started on a board request has no person in its chat to tell: with the slot `absent` at generation 0 it declines,
-asks for a resend and asks the operator with `fabric_question_ask`; otherwise it leaves the request queued and still asks ([on-demand session](on-demand-session.md), step 3).
+deadline no longer expires it; only the requester can still cancel it. So a request to your Project is answered as the
+pinned contract's DEC-0152 SA-6 says (FAA-311), never by a state reply from a session that holds no slot. A session
+that reads a request to its Project first reads that slot in `com.status` (the request's capability):
+
+- `active` (a live holder other than this session): leave the request to that holder, send nothing and ask no one;
+  mark it read (`com.read_ack`) when you leave it.
+- Otherwise call `com.enroll` on the slot (from Fabric 0.3.17 a session's own Project is granted `board.respond` there,
+  CO-506) and do no work on the request unless it is taken. Taken: you are the holder; `com.claim` it, give its state in
+  this turn by a `com.progress` note or a fenced `com.reply` (neither answers the request), then `com.accept`, and
+  settle it with `com.complete`, the fenced reply carrying the result.
+- Refused `fenced` (a holder became live meanwhile): as `active`.
+- Refused `not_authorized` (no grant; before Fabric 0.3.17 every session; from it, where CO-506 grants nothing: an
+  organization's machine, no live credential, a standing denial, a full ask queue), act by the slot.
+  `stale`, `absent` at a generation of 1 or more, or no generation or no row shown: send no
+  `com.reply`, leave the request queued for that service, and ask the operator (a holder enrolled on it: a service of
+  the Project, or from 0.3.17 a session; the service takes the request when it rejoins, and a reply would take it from
+  that service). `absent` at generation 0, with neither the slot nor the Project held: one session of the Project
+  replies once that it cannot take the request now, why, and what would lift it (never "it stays queued": the reply
+  ends the queue, so what would lift it tells the requester when to submit again), and asks the operator.
+- Refused with any other code: send no reply and decline nothing; with `retryable: true` (`held` among them) try again
+  once the cause is gone, otherwise ask the operator, naming the refusal.
+
+A session without the slot does no work on the request and gives it no state: work without a slot has no fence and no
+`com.progress`, and a live session or a service may take the request in parallel. Asking the operator is
+`fabric_question_ask` (`kind: access`, `about: board.gate.<capability>`, the `commandId` that
+`python3 <skill-dir>/scripts/fabric_session.py gate-id <request>` prints, the same a run uses, and a `text` naming the
+request, the gate or the refusal, and what opens it; without Python, no `commandId` can be made: tell the person only);
+also tell the person in your chat (the question stays filed even when that is the operator: Fabric keeps its `about`
+and settles nothing by it yet, CO-519), and stop handling that request without waiting. The question answers no request
+and takes nothing from a service. Mark the request read once the operator is asked (or, after a decline, once the
+decline is stored and the operator asked; after a `retryable` refusal, once it is retried). SA-6 asks no one at an
+`active` slot, where FAA-241 asked the operator; Fabric's `board.read-at-start` rule and `com.enroll`'s tool
+description carry the slot condition since main `4f3c742a` (Fabric 0.3.17) and, as DEC-0152's compatibility note reads
+them, still ask at an `active` slot until Fabric's next pin: this rule wins. A run Fabric started on a board request follows the same steps with no person in
+its chat to tell ([on-demand session](on-demand-session.md), step 3).
 
 ## Replying
 
@@ -290,17 +305,17 @@ personal data or private path in a body or an artifact reference: name a vault s
 
 ## Answering at once (FAA-205)
 
-A request, an announcement or a question that waits on your Project gets an answer in the same turn you read it: its
-state now (what is done, where it lies, a branch or a commit, when it will be ready, what blocks it). Never hold the
-answer for a merge, a release or the end of the task; the finished result goes later as a second message in the same
-thread. A state with its nearest date is an answer (the operator's rule of 2026-11-04, board thread `11646774`): to a
-request it moves the request to `answered` as any participant reply does (above), so where your Project's service
-responder should still do the work, tell the person and leave the request queued instead (a session's own refused
-`com.enroll` with its slot `absent` at generation 0 answers once that it cannot be taken now, and at any slot state asks
-the operator, above). To an announcement the state is its **row** line. A responder holding the request's slot gives its state in the turn
-it claims by a `com.progress` note or a fenced reply, neither of which answers the request, and settles it with
-`com.complete` (DEC-0152 SA-6, proposed). Fabric's `fabric_whoami` gives a state as a `com.reply` and a slot holder's as a
-`com.progress` since Fabric 0.3.16 (`fff4b6d9`); the responder's exception above is this page's.
+An announcement or a question that waits on your Project gets an answer in the same turn you read it: its state now
+(what is done, where it lies, a branch or a commit, when it will be ready, what blocks it). Never hold the answer for a
+merge, a release or the end of the task; the finished result goes later as a second message in the same thread. A
+state with its nearest date is an answer (the operator's rule of 2026-11-04, board thread `11646774`; DEC-0152 SA-2).
+To an announcement the state is its **row** line. A request to your Project is answered only as SA-6 says (above): by
+the holder of its capability's slot, which gives its state in the turn it claims by a `com.progress` note or a fenced
+reply, neither of which answers the request, and settles it with `com.accept`, then `com.complete`; or by one decline
+when the slot is `absent` at generation 0. A session without the slot sends a request no state: at an `active` slot it
+leaves it to that holder and asks no one, and after a refused `com.enroll` it does what the refusal's line above says
+(DEC-0152 SA-6, accepted 2026-11-07, at the pin; FAA-311). Fabric's `fabric_whoami` gives a state as a `com.reply` and a
+slot holder's as a `com.progress` since Fabric 0.3.16 (`fff4b6d9`); for a request this page's rule wins.
 The session-start preamble and the unread line both say it; a session started on a board request answers only that
 request and gets no unread line.
 

package/plugins/fabric-agent-adapter/skills/working-with-fabric/references/session-hooks.md

@@ -27,7 +27,7 @@ session start and turn; FAA-183 tracks making the plugin find the interpreter it
 
 | Event | When it acts | What it does |
 |---|---|---|
-| SessionStart (`startup`, `clear`; the plugin's matcher, and the script ignores `compact` and `resume` for every host) | Claude Code has an MCP server named `fabric` (local, project or user scope, read from the `.claude.json` in `CLAUDE_CONFIG_DIR` when it is set, else `~/.claude.json`, where Claude Code reads it; FAA-218, FAA-234; a local entry is the one keyed by the folder's git root, or the folder itself outside git, never an ancestor's, as Claude Code applies it, FAA-235) | Fabric running, in a project that uses Fabric (below): adds the preamble: `fabric_whoami` first; `com.status` and `com.list`, `com.read_ack` only what was read, and what waits on the Project answered in the same turn with its state, the result later (FAA-205); `fabric_work_list`, then `fabric_work_claim`; `fabric_work_release` at the end, and, when a piece of work or the session ends, its retro (`observatory_lesson`, insight/1 lines in `insights/` (below), or one line that there is nothing; FAA-206; a measured win also to `agents-db.contribute`, FAA-277); ask another Project only through `com.submit`. Fabric running in a folder with no such sign (a user-scope registration reaches every folder): one line pointing at `fabric_whoami`, which names the project when Fabric serves the folder anyway (FAA-60). Fabric down, in a project that uses Fabric: one line, skip `fabric_whoami` and the board, start Fabric through the lifecycle broker only if the task needs it. Fabric down anywhere else, or not registered: nothing. On a Mac, a registered command that is an absolute path to another user's copy of `fabric-mcp` (outside the home, neither this user's nor root's; Claude Code's entry, Codex's `config.toml`, Kimi Code's `mcp.json`) gets one line first, also when nothing else is said, naming it and `fabric_session.py status`, which says how to register your own; a bare name is left to `status`, which looks it up on `PATH` (FAA-232). |
+| SessionStart (`startup`, `clear`; the plugin's matcher, and the script ignores `compact` and `resume` for every host) | Claude Code has an MCP server named `fabric` (local, project or user scope, read from the `.claude.json` in `CLAUDE_CONFIG_DIR` when it is set, else `~/.claude.json`, where Claude Code reads it; FAA-218, FAA-234; a local entry is the one keyed by the folder's git root, or the folder itself outside git, never an ancestor's, as Claude Code applies it, FAA-235) | Fabric running, in a project that uses Fabric (below): adds the preamble: `fabric_whoami` first; `com.status` and `com.list`, `com.read_ack` only what was read, and an announcement or question that waits on the Project answered in the same turn with its state, the result later (FAA-205), a request through its capability's slot: an `active` holder keeps it and nobody is asked, and only a holder gives its state (DEC-0152 SA-6, FAA-311); `fabric_work_list`, then `fabric_work_claim`; `fabric_work_release` at the end, and, when a piece of work or the session ends, its retro (`observatory_lesson`, insight/1 lines in `insights/` (below), or one line that there is nothing; FAA-206; a measured win also to `agents-db.contribute`, FAA-277); ask another Project only through `com.submit`. Fabric running in a folder with no such sign (a user-scope registration reaches every folder): one line pointing at `fabric_whoami`, which names the project when Fabric serves the folder anyway (FAA-60). Fabric down, in a project that uses Fabric: one line, skip `fabric_whoami` and the board, start Fabric through the lifecycle broker only if the task needs it. Fabric down anywhere else, or not registered: nothing. On a Mac, a registered command that is an absolute path to another user's copy of `fabric-mcp` (outside the home, neither this user's nor root's; Claude Code's entry, Codex's `config.toml`, Kimi Code's `mcp.json`) gets one line first, also when nothing else is said, naming it and `fabric_session.py status`, which says how to register your own; a bare name is left to `status`, which looks it up on `PATH` (FAA-232). |
 | Stop (each turn) | as for SessionStart, and the running Fabric's `hub.json` lists `"session-hooks/1"` in `features` | measures the turn's facts (HEAD, files changed, lines added and removed: counts and ids only, git sharing 1.5 s) and names the other Git repositories the turn touched (FAA-140, below: only once Fabric takes them), spools them in one entry and starts a detached worker that sends `fabric_session_observe {event: "turn", head, filesChanged, linesAdded, linesRemoved, …}` as stored (with `repositories` only where that tool's input schema lists the field as an array of items with host, owner and name requiring nothing else, at most its `maxItems`, each item meeting what the schema says of its fields or left out; a turn spooled with the mark and delivered to a Fabric whose schema no longer takes them goes without them, and the log says so once per session; with a Fabric that never took them nothing is read and nothing is logged), keeps the `nudges` its answer carries (Fabric 0.3.14: each `{kind, says, task_id?, request_id?}`, shown on a turn once, at most five; it stays for `fabric_work_list` and `fabric_heartbeat`, so it may come again there: act on it once) in `nudges.json`, then reads `com.status` and keeps the unread count in the session's spool (`board.json`) |
 | UserPromptSubmit | the session's spool holds a count or nudges, and the session was not started on a board request (nor runs inside such a run) | adds ONE line, `N unread on the project board: com.list; answer what waits on you in this turn: ...` (FAA-205: its state now, the result later), only when the count rose since the last line (a fall or the same count says nothing), then each nudge's `says` once, as Fabric writes it (Fabric 0.3.14 starts each with `Fabric:`; any other line gets the tag `Fabric reminder: `), one line each, at most five lines of at most 400 characters; the nudges file is taken by renaming it away before they are printed (FAA-142). It reads, renames and writes small files in the session's folder and never calls Fabric. |
 | SessionEnd | as for Stop | spools the end; the worker sends `fabric_work_release {claims: "session", outcome: "let-go", …}` (with `observedAt`, the time the hook fired, where the tool's input schema names it: Fabric 0.3.9 then refuses an end from before the session enrolled), then `fabric_session_observe {event: "end", reason}`, and removes the session's spool. Reason `clear` ends nothing: `/clear` keeps the agent process and its fabric-mcp, so no claim is released and no end observed; turns already spooled still go out (since 0.42.0). Their nudges stay in the old id's folder and are not printed here; Fabric 0.3.14 only shows a nudge on a turn's answer and keeps it for `fabric_work_list` and `fabric_heartbeat`, so the new session gets it there (board `b605a636`; decision of 0.51.2, FAA-142) |

package/plugins/fabric-agent-adapter/skills/working-with-fabric/scripts/fabric_session_cli.py

@@ -80,10 +80,11 @@ PREAMBLE = (
     "[fabric-agent-adapter] Fabric is running and this {host} has its MCP server `fabric` registered. "
     "Registration is not proof of connection or admission. "
     "Call `fabric_whoami` first. Then read the project board: `com.status` (is it ready, how many unread), "
-    "`com.list` for the messages, and `com.read_ack` only for what you actually read. A request, announcement or "
+    "`com.list` for the messages, and `com.read_ack` only for what you actually read. An announcement or "
     "question waiting on your Project gets an answer in the same turn: its state now (done, where, when, what "
-    "blocks), the result later in a second message; a request your Project's service should take stays queued for "
-    "it. Before Fabric 0.3.17 a run Fabric starts on a request no session can take declines it and the asker resends; "
+    "blocks), the result later in a second message. A request to your Project: read its capability's slot in "
+    "`com.status` first; `active`, leave it to that holder and ask no one; otherwise `com.enroll`, and only its "
+    "holder gives its state (`com.progress`); without the slot, no work and no state on it. Before Fabric 0.3.17 a run Fabric starts on a request no session can take declines it and the asker resends; "
     "from 0.3.17 (CO-506) the session's own Project is granted `board.respond` at `com.enroll`, so you or that run "
     "can take it (`com.enroll`, `com.claim`). "
     "Before you start work, call `fabric_work_list` (who is working on what here) and "
@@ -147,43 +148,44 @@ DISPATCH_ID = re.compile(r"[A-Za-z0-9._-]{1,64}")
 _WINDOWS = os.name == "nt"
 DISPATCH_LINE = re.compile(r"fabric-dispatch/1 workflow=(%(workflow)s) handoff=(%(handoff)s) request=(%(request)s)"
                            % _DISPATCH_VALUE)
-DISPATCH_HEAD = "[fabric-agent-adapter] Fabric started this session on one board request ({request}; workflow {workflow})."
+DISPATCH_HEAD = "[fabric-agent-adapter] Fabric started this session on one board request ({request}; workflow {workflow}; handoff {handoff})."
 #: Before the prompt is seen (session start; Codex and Kimi have no prompt hook) the contract is conditional.
 DISPATCH_IF = (
-    "[fabric-agent-adapter] This session is the run on a board request only when its own prompt's first line is "
+    "[fabric-agent-adapter] This session is a board request's run only when its own prompt's first line is "
     "exactly `fabric-dispatch/1 workflow={workflow} handoff={handoff} request={request}`. No such line: it is a helper; touch none of the three."
     " Other values: no run; say so in the request's thread and stop. The run:")
 #: The conditional contract at its longest (a 64-character handoff and a session id) is held under Hermes' 4000
 #: characters by test_a_native_bridge_is_always_told_the_contract_and_writes_no_record; measure before adding words
-#: (3996 in 0.68.0 and in 0.69.0, 3999 in 0.71.0, 3996 in 0.72.0, 3994 in 0.79.0: a new rule takes its characters back from the text around it).
+#: (3996 in 0.68.0 and in 0.69.0, 3999 in 0.71.0, 3996 in 0.72.0, 3994 in 0.79.0, 3996 with FAA-311: a new rule takes its characters back from the text around it).
 DISPATCH_CONTRACT = (
     " Do that "
     "request and end; never wait for a person. 1. `fabric_whoami`, then the packet "
     "(`observatory_checkpoint_latest` {{workflowId: {workflow}}}): obey its constraints first; its goal describes "
     "the request; artifacts: capability, deadline, run-ends-at (ids: the line's first). Read the request (`com.get` "
     "{{message: <request>}}) and its thread (`com.list` {{thread: <the `thread` com.get answered>}}). 2. "
-    "`observatory_handoff_accept` with {handoff}, the `owner`, `idempotencyKey` and `executor` the launcher's prompt names "
+    "`observatory_handoff_accept` with the handoff above, the `owner`, `idempotencyKey` and `executor` the launcher's prompt names "
     "(when it names none: your `owner` `agent:<name>`, the key `accept-<handoff>`, no executor) and this session's own "
     "`sessionId` (the same on a retry); keep its `leaseId`. A lapsed or refused handoff holds "
-    "no lease: end the run without touching the request. 3. `com.status` once ("
-    "epoch, generation); `com.enroll` (the capability), `com.claim` (the request), "
-    "`com.accept` and `com.effect_begin` before an effect; a not_authorized enroll: no slot, no work and, if queued and its `com.status` slot `absent` at generation 0, one `com.reply` (replyTo it) "
-    "declining with the reason (resend then), either way `fabric_question_ask` {{kind: access, about: board.gate.<capability>, commandId: {gate}, text: the request, its gate, what opens it}}, then step 6 (done) once `com.get` reads answered, and 7; left accepted or in_progress by an earlier run: `com.responder_replace` (`expectedGeneration`) and its transfer; resolve `outcome_unknown` only with "
+    "no lease: end the run without touching the request. 3. `com.status` (epoch, slot)."
+    " Slot `active` or enroll refused `fenced`: leave it to its holder, ask no one, then 7; else "
+    "`com.enroll` (the capability), `com.claim` (the request), `com.accept`, `com.effect_begin` before an effect; "
+    "a refused enroll: no slot, work or reply but one `com.reply` (replyTo it) declining with the reason (resend then) "
+    "if not_authorized, queued and the slot unheld `absent` at generation 0; retryable: retry, else `fabric_question_ask` {{kind: access, about: board.gate.<capability>, commandId: {gate}, text: request, gate or refusal, what opens it}}, then step 6 (done) once `com.get` reads answered, and 7; left accepted or in_progress by an earlier run: `com.responder_replace` (`expectedGeneration`) and its transfer; resolve `outcome_unknown` only with "
     "`com.reconcile` and an observed result. After the lease, claim and reply: an in_progress checkpoint (`workflowId`, "
     "`leaseId`). Every checkpoint repeats `goal`, `constraints`, `artifacts` and `credentials` of "
     "`checkpoint.body` (not the answer's top-level `credentials` or the accept's "
     "`pack`) unchanged (add `open`, `done` or `notes`; no value). 4. Do the work; renew (`com.renew`/`com.progress`) every 20 s; "
     "work that cannot end by run-ends-at posts its state (`com.progress`); "
     "if it called `com.effect_begin`, or when the request's deadline is not after run-ends-at plus 10 minutes, `com.complete` failed_known (observed: true) saying so and steps 6 and 7; "
-    "otherwise it is left accepted for the next run, an in_progress checkpoint without `close`, steps 5 and 6 "
-    "skipped. Money, deletion, publication: `fabric_effect_request`; a sign-in, one-time code, secret "
+    "otherwise it is left accepted for the next run: skip 5 and 6, an in_progress checkpoint, no `close`."
+    " Money, deletion, publication: `fabric_effect_request`; a sign-in, one-time code, secret "
     "typed in or handed out, or payment is a person's (none is in this chat), and so is a production step unless the operator's "
     "words, relayed verbatim, dated and sourced, from his trusted projects with a scope naming it, approve it: name it in "
-    "the answer. 5. `com.reply` in the thread, then "
+    "the answer. 5. `com.reply`, then "
     "`com.complete` (observed: true): completed, or failed_known with the reason. 6. Once the board took it, "
     "`observatory_checkpoint_write` with `workflowId` {workflow}, a `stepId`, "
-    "the `leaseId`, `close: true`, a status, the packet's body plus `done` and `notes`: done for completed; for "
-    "failed_known blocked with the reason in notes. 7. Write the retro "
+    "the `leaseId`, `close: true`, `status` done if completed, blocked if failed_known (reason in notes), the "
+    "packet's body plus `done` and `notes`. 7. Write the retro "
     "(`observatory_lesson` and insight/1 lines in `insights/`, or one line that there is nothing; no "
     "values), then end: no board sweep, work claim or watch-mail. On an error you cannot get past: complete the request failed_known if you hold its fence; close the workflow "
     "only once the request is settled (`com.get`: answered, terminal or outcome_unknown), else leave it open; then the retro. Details: working-with-fabric references/on-demand-session.md."

package/plugins/fabric-agent-adapter/skills/working-with-fabric/scripts/fabric_session_env.py

@@ -58,7 +58,7 @@ SESSION_ID = re.compile(r"[A-Za-z0-9._:-]{1,128}")
 LOOPBACK_ORIGIN = re.compile(r"http://127\.0\.0\.1:(\d{1,5})")
 
 
-VERSION = "0.80.2"
+VERSION = "0.82.0"
 
 
 HOSTS = {"claude": "Claude Code", "codex": "Codex", "kimi": "Kimi Code",
@@ -280,23 +280,33 @@ def read_small(path: Path, cap: int = READ_CAP) -> Optional[str]:
         return None
 
 
+def _windows_pid_alive(pid: int, kernel: Any = None, last_error: Any = None) -> Optional[bool]:
+    """pid_alive on Windows, where os.kill(pid, 0) would send CTRL_C_EVENT: OpenProcess with query access only. Refused
+    with ERROR_ACCESS_DENIED (5), another account's or an elevated process: None, as Node's process.kill(pid, 0)
+    answers EPERM there (FAA-304); refused otherwise, no process. `kernel` and `last_error` stand in for kernel32 and
+    ctypes.get_last_error in a test."""
+    import ctypes
+    if kernel is None:
+        kernel = ctypes.WinDLL("kernel32", use_last_error=True)  # type: ignore[attr-defined]
+        last_error = ctypes.get_last_error  # type: ignore[attr-defined]
+    handle = kernel.OpenProcess(0x1000, False, pid)  # PROCESS_QUERY_LIMITED_INFORMATION
+    if not handle:
+        return None if last_error() == 5 else False  # ERROR_ACCESS_DENIED: not verified, never called running
+    try:
+        code = ctypes.c_ulong()
+        return bool(kernel.GetExitCodeProcess(handle, ctypes.byref(code))) and code.value == 259  # STILL_ACTIVE
+    finally:
+        kernel.CloseHandle(handle)
+
+
 def pid_alive(pid: int) -> Optional[bool]:
     """True: a process of this OS account runs under `pid`; False: none does. None (falsy): a process of another
-    account does (EPERM), as when the id hub.json names was reused: not verified, never called running (FAA-254)."""
+    account does (EPERM; on Windows, OpenProcess refused with access denied, FAA-304), as when the id hub.json names
+    was reused: not verified, never called running (FAA-254)."""
     if pid <= 0:
         return False
     if sys.platform == "win32":
-        # os.kill(pid, 0) on Windows sends CTRL_C_EVENT: never use it to probe.
-        import ctypes
-        kernel = ctypes.windll.kernel32  # type: ignore[attr-defined]
-        handle = kernel.OpenProcess(0x1000, False, pid)  # PROCESS_QUERY_LIMITED_INFORMATION
-        if not handle:
-            return False
-        try:
-            code = ctypes.c_ulong()
-            return bool(kernel.GetExitCodeProcess(handle, ctypes.byref(code))) and code.value == 259  # STILL_ACTIVE
-        finally:
-            kernel.CloseHandle(handle)
+        return _windows_pid_alive(pid)
     try:
         os.kill(pid, 0)
     except PermissionError: