chore(monad): merge upstream main 36ee06f7b (before OTLP OCSF export)

.agents/skills/apply-triage-action/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: apply-triage-action
+description: Apply, reject, or defer exactly one issue or CI recommendation from a local triage queue report. Use when the on-duty engineer explicitly supplies an item ID.
+metadata:
+  internal: true
+---
+
+# Apply Triage Action
+
+Process exactly one item ID from a queue-review report. Do not accept a natural-language approval without an ID. PRs are informational in v1.
+
+## Locate and validate
+
+1. Read the checkpoint and action records under `.agents/triage-duty/`; reconcile dispositions using the [local-state rules](../review-triage-queue/SKILL.md#local-state).
+2. Use the named report, or the latest report containing the ID. Read the recommendation and current disposition. Material changes to a previously selected recommendation require fresh review and selection.
+3. Reject missing, superseded, already-final, or ambiguous recommendations without making a write. Never substitute another item.
+4. Append every explicit disposition or attempted action to a dated local action record. Record repository, target, source report, ID, timestamp, disposition, reason, confirmed payload, and outcome; update the checkpoint afterward. Keep sensitive content out of the record; use `private reason withheld` for private reasons.
+
+## Reject or defer
+
+For **reject** or **defer**, require the engineer to give a reason. Record the local disposition.
+
+- **Reject** is terminal locally. Do not recommend the item again unless material new evidence changes the case.
+- **Defer** is non-terminal. Preserve its original priority and carry it into the next review's carried **Needs your decision** section.
+
+For shareable deferrals, draft a GitHub issue comment with reason, public links, and next step, or link existing waiting context. Use the confirmation rule below; declined posting leaves a local-only deferral. Keep private reasons out of external payloads and committable files. For missing reporter evidence, also propose the awaiting-information assessment state using `triage-issue`; unrelated dependency waits do not change lifecycle labels.
+
+## Apply
+
+Before any external write, re-read the target and determine whether it materially changed. Follow [Label Discovery](../../../CONTRIBUTING.md#label-discovery), retrieving all pages of current definitions before proposing a label change; use [`triage-issue`](../triage-issue/SKILL.md) for assessment states and maintainer authority.
+
+- If the action is already complete or would be a harmless no-op, make no external write and record the reason.
+- If new information makes the action unsafe or substantially different, stop and request a fresh review/selection.
+
+You MUST ALWAYS preview the exact payload, item ID, source report, and canonical target, then receive explicit confirmation for each individual external write. Selecting or deferring an item is not confirmation; comments, label changes, and closures require separate confirmations. Revalidate immediately before execution; changed payloads require a new preview and confirmation. Never reuse confirmation for a later invocation.
+
+After confirmation, perform only the approved action and record its outcome and public URL; mark applied only after success.
+
+Supported v1 actions:
+
+- Add the discovered triage-queue label to an open substantive community issue; recheck the [intake eligibility rules](../review-triage-queue/SKILL.md#gather-intake) and exclude duplicates, spam, and security disclosures.
+- Create one GitHub issue using [`create-github-issue`](../create-github-issue/SKILL.md).
+- Post one public issue comment, including waiting context or a duplicate explanation.
+- Change an issue's assessment state to awaiting information.
+- Close one issue with an evidenced reason; identify the canonical issue for duplicates.
+
+Never create a public GitHub issue for a security finding. Follow [SECURITY.md](../../../SECURITY.md).

.agents/skills/build-from-issue/SKILL.md

@@ -27,7 +27,7 @@ Use a single issue comment beginning with `> **🏗️ build-plan**` when a plan
 1. Check the current branch and working tree. Preserve unrelated work. Create an issue-specific branch or worktree as needed, following Branch Names in `CONTRIBUTING.md`.
 2. Implement the smallest coherent change that fulfills the acceptance criteria. Update relevant skills when behavior or commands change. Keep published documentation minimal: explain exactly what users need, avoid duplication across pages, and omit internal details with no user impact.
 3. Add meaningful tests for changed behavior and follow the verification guidance in `CONTRIBUTING.md`. Select format, lint, compile or type checks, and tests for affected components and their dependencies. Run the relevant E2E lane for infrastructure, sandbox, or policy changes. Guidance and template edits need applicable Markdown, YAML, link, and consistency checks. Do not require full Rust, SDK, or repository CI solely because a commit or PR is being created; broaden checks only for a concrete remaining risk or failed check.
-4. Review the diff, use a signed-off Conventional Commit, and prepare a PR following `create-github-pr`.
+4. Before pushing, apply the contributor access and issue acceptance check in `create-github-pr`. If blocked, preserve local work and report the reason. Review the diff, use a signed-off Conventional Commit, and prepare the PR.
 
 Every PR from this issue-backed workflow must have its own existing issue and use `Closes #<id>` in its Related Issue section. For work needing multiple PRs, split the scope into a closable issue per PR. A high-level issue may track those issues but should not be closed by an incomplete PR. Report the implementation, verification, and any remaining limitation in the PR description, rather than copying earlier issue diagnostics.
 

.agents/skills/build-openshell-mxc-windows/SKILL.md

@@ -21,6 +21,18 @@ Windows MSVC for the supported deliverables:
 It intentionally does not make Windows a Docker, Kubernetes, Podman, or VM
 runtime host.
 
+The supervisor and supervisor-process libraries participate in native Windows
+checks and tests. Their gateway session, boundary attachment, and TCP readiness
+are portable; only the optional Unix SSH/readiness socket adapters are gated.
+This is compile and control-plane coverage, not Windows isolation qualification.
+Preserve readiness gating on authenticated gateway acceptance and reconnection.
+The supervisor process-access multiplexer consumes boundary-provided streams;
+do not restore local PID, PTY, or process-group operations there. Native process
+mechanics belong to the sandbox or isolation backend. Keep the optional Unix
+SSH access adapter separate from portable session orchestration.
+Shared Sandbox Protocol audit validation defaults to strict Linux evidence;
+concrete platform validators must be selected by the implementing backend.
+
 ## Current Repository Shape
 
 The Windows build lane is implemented by these tracked files:

.agents/skills/build-openshell-mxc-windows/reference.md

@@ -111,8 +111,6 @@ top-level workspace targets for check/test:
 --exclude openshell-driver-vault
 --exclude openshell-driver-vm
 --exclude openshell-sandbox
---exclude openshell-supervisor
---exclude openshell-supervisor-process
 --exclude openshell-vfio
 ```
 
@@ -124,6 +122,10 @@ egress proxy. The Kubernetes Secrets and Vault libraries still compile as
 gateway dependencies; only their standalone Unix-socket binaries and
 package-level tests are excluded as top-level targets.
 
+The supervisor and supervisor-process packages now participate as top-level
+native check/test targets. Their portable session, attachment, and TCP readiness
+coverage does not enable a Windows isolation runtime.
+
 ## Common Errors
 
 ### Unix imports leak into Windows builds

.agents/skills/create-github-pr/SKILL.md

@@ -17,6 +17,26 @@ Create pull requests on GitHub using the `gh` CLI.
 
 ## Before Creating a PR
 
+### Verify Contributor Access and Issue Acceptance
+
+Before pushing or creating a PR (including a draft), verify the author's access
+to the target repository, not their fork. For the authenticated `gh` user:
+
+```bash
+gh repo view OWNER/REPO --json nameWithOwner,viewerPermission
+gh issue view ISSUE_NUMBER --repo OWNER/REPO --json number,url,labels
+```
+
+Authors with verified `WRITE`, `MAINTAIN`, or `ADMIN` access may proceed without
+`state:accepted`; keep the issue link and note the missing label. Everyone else
+must link at least one target-repository issue and have `state:accepted` on each.
+Otherwise, preserve local work and report which issue needs acceptance. A direct
+request, roadmap placement, other labels, or vouch status does not bypass this gate.
+
+When acting for another author, verify their permissions. Resolve failed lookups
+before proceeding; retry sandbox network failures outside the sandbox before
+reporting an authentication problem. Vouch requirements still apply separately.
+
 ### Check Config Documentation
 
 If the branch changes gateway TOML parsing, `[openshell.gateway]` fields,
@@ -220,6 +240,9 @@ EOF
 
 The command outputs the PR URL and number.
 
+Rerun `PR Issue Acceptance` after linked issue labels change; it does not refresh
+automatically on issue-label events.
+
 **Display the URL using markdown link syntax** so it's easily clickable:
 
 ```

.agents/skills/release-openshell/SKILL.md

@@ -0,0 +1,20 @@
+---
+name: release-openshell
+description: Pick the latest qualified OpenShell prerelease and tag its commit as stable. Create and qualify a prerelease first when none exists.
+metadata:
+  internal: true
+---
+
+# Release OpenShell
+
+For the intended release version, pick the latest prerelease whose Release
+Qualification job passed. Confirm that its qualification summary matches the
+tag and commit. Present the candidate and changes since the previous stable
+release to the maintainer; once approved, tag that exact commit as `vX.Y.Z`.
+
+If no prerelease exists, agree on the version and source commit, then create and
+push `vX.Y.Z-pre.1`. Wait for qualification to pass before promoting it.
+
+Both prerelease and stable tag pushes start Release Tag. Release Auto-Tag uses
+an explicit dispatch because its `GITHUB_TOKEN` pushes do not trigger workflows.
+Watch the stable release run and report its result.

.agents/skills/review-github-pr/SKILL.md

@@ -39,11 +39,28 @@ gh pr list --head "<branch>" --state open
 Retrieve the PR metadata:
 
 ```bash
-gh pr view <number> --json title,body,state,headRefName,baseRefName,labels,author
+gh pr view <number> --json title,body,state,headRefName,baseRefName,labels,author,closingIssuesReferences
 ```
 
 Record the **title**, **body**, **headRefName**, and **baseRefName** for use in later steps.
 
+### Check Issue Acceptance
+
+Inspect every closing issue reference (paginate as needed) and fetch its current
+repository and labels. Verify the PR author's permission in the target repository:
+
+```bash
+gh api repos/OWNER/REPO/collaborators/AUTHOR/permission --jq .permission
+```
+
+Call out each linked issue missing `state:accepted`, with an issue link. Verified
+`write`, `maintain`, or `admin` access permits the exception; report it as context,
+not a blocking concern. Other authors need at least one target-repository issue,
+and every linked issue must be accepted; report violations under **Potential
+Concerns**. PR body text such as `No issue required` does not bypass this gate.
+Report failed lookups as unverified and continue the code review. For a branch
+without a PR, note that issue acceptance was not verified.
+
 ## Step 3: Generate the Diff
 
 ### Primary: gh pr diff

.agents/skills/review-triage-queue/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: review-triage-queue
+description: Create a read-only, local triage queue report from OpenShell GitHub intake. Use to review the triage queue, scan incoming issues and community PRs, check main-branch CI failures, or resume a triage pass.
+metadata:
+  internal: true
+---
+
+# Review Triage Queue
+
+Create a decision-focused, local Markdown report. Do not write to GitHub.
+
+## Local state
+
+Use these ignored local paths under `.agents/triage-duty/`:
+
+- Checkpoint: `state.local.yml`
+- Reports: `reports/<UTC timestamp>.md`
+- Action records: `actions/<UTC timestamp>.md`
+- Inbox: `inbox.md`
+
+Record first-run coverage. Update cursors only after a complete report; partial reads must not skip unread items. Search with overlap and deduplicate source items.
+
+Keep the checkpoint minimal: repository, last successful scan, source and backlog cursors, explicit dispositions, and next triage issue. Action records are authoritative; reconcile the checkpoint from them before proceeding. Reports are immutable. Never store credentials, personal data, private reasons, or vulnerability details; never stage duty files.
+
+Read unchecked inbox entries at the start of every review. Treat them as local follow-up prompts, not as independent evidence or authorization for an external action. When an entry materially informs the review, include it in the report's **Local inbox follow-up** section. After the dated report is written, mark that entry complete in the inbox with the report filename. Leave entries unchecked when they were not yet actionable or were not considered.
+
+## Gather intake
+
+Follow [Label Discovery](../../../CONTRIBUTING.md#label-discovery), retrieving all pages of current label definitions. Identify the triage queue by its description. Read all pages of each source:
+
+- All open GitHub issues in the triage queue, ordered by most recently updated.
+- Newly opened community issues with **no `state:*` label**; exclude maintainer/core-contributor issues and already-routed work from label recommendations. This includes stale lifecycle labels.
+- Older open community issues meeting the same eligibility rule: measure first; audit all when there are at most 20, otherwise inspect the five oldest remaining candidates per run. Use a separate `(created_at, number)` backlog cursor, advanced only after inspection and reporting; wrap at the end. Advancing it must not drop pending recommendations. Age sets ordering only and never justifies closure.
+- Open non-draft Dependabot pull requests. Surface these explicitly so they do not age out or go stale while waiting for maintainer attention.
+- Newly opened non-draft community pull requests.
+- Failed CI runs on `main`.
+- Published repository documentation for applicable public answers.
+
+Do not scan GitHub Discussions or a dedicated security-reporting source in v1. Route suspected vulnerabilities through [SECURITY.md](../../../SECURITY.md).
+
+Treat an unlabelled issue as already routed when it has roadmap placement, a milestone, a Project item, or an explicit maintainer comment that assigns, schedules, or otherwise intentionally removes it from triage. Report that signal as context; never recommend adding the triage-queue label to it. If authorship or routing is uncertain, report the uncertainty instead of recommending a label.
+
+## Analyze and rank
+
+Use repository-scoped object IDs: `I<number>` for issues, `P<number>` for PRs, and `C<run_id>` for GitHub Actions runs. Link each ID to its canonical source; attempts share the run ID. PRs are informational in v1.
+
+Detect related signals across sources. Preserve each source as linked provenance. Group similar evidence into one recommendation; do not count a global fixed number of occurrences as the only evidence of repetition.
+
+Recommend work for repeated questions, defects, documentation/support gaps, requested product changes, or likely duplicates. Treat documentation and support improvements as bug-fix or feature work when they address a demonstrated user need.
+
+Classify recommendations as bug, feature, documentation/support improvement, duplicate, intake-gap routing, release blocker, or security finding. The agent may infer a release blocker only with concrete evidence, source links, and confidence. Keep `critical` for security findings and release blockers; use `high`, `normal`, or `low` for all other items. Set confidence to `high`, `medium`, or `low`, and explain uncertainty unless it is high.
+
+Give new and carried pending/deferred recommendations separate five-item budgets. Preserve carried priorities and recheck live sources outside scan windows. Keep excess findings in overflow; only security findings and release blockers may exceed either cap. Never mark recommendations processed merely because they were reviewed; carry pending/deferred items until applied or rejected through `apply-triage-action`.
+
+## Resume an in-progress triage pass
+
+When the on-duty engineer asks for the “next issue” without asking for a new queue review, resume from the latest local report's **Triage queue** order. Select the first item that has not been explicitly dispositioned in local duty state. Do not query live GitHub data to silently reorder an in-progress pass: newly opened or newly updated issues belong in the next queue review. Use `triage-issue` for assessment.
+
+An engineer can explicitly request a refresh or the newest live issue; either request supersedes the continuation order. If the report has no remaining listed candidate, say so and offer a fresh queue review rather than choosing an item from an older overflow list.
+
+## Write the report
+
+Create a dated immutable report using [the report template](references/report-template.md). Use links and short paraphrases only. Record its first listed triage issue as `next_triage_issue` in the checkpoint.

.agents/skills/review-triage-queue/references/report-template.md

@@ -0,0 +1,31 @@
+# Triage queue report
+
+Include repository, generation time, source/checkpoint coverage, scan limitations, and `next_triage_issue`. Retain empty sections with `None`.
+
+## Needs your decision — new
+
+Each entry has an object ID, canonical source link, priority, classification, concise proposed action, confidence, linked evidence, applicable public-doc links or `none found`, and disposition at generation.
+
+## Needs your decision — carried
+
+Use the same fields; include the shareable deferral reason or `private reason withheld`, action-record link, and existing public waiting-context link when available.
+
+## Triage queue
+
+State total and unlisted queue counts. Show up to five recently updated items with ID, title, updated time, and a concise summary of context and material changes. Put the rest in overflow. Do not assess these issues; direct the engineer to `triage-issue`.
+
+## Dependabot pull requests
+
+List open non-draft Dependabot PRs needing maintainer action, with ID, package/update, checks, current test-authorization requirement, and link. Use the current repository workflow.
+
+## Community pull requests
+
+List up to five new non-draft community PRs with ID, title, author, checks, and link. Exclude Dependabot entries; put the rest in overflow.
+
+## Deferred and overflow findings
+
+Preserve lower-priority and capacity-limited findings with the recommendation fields above. Include informational CI findings with ID, canonical run link, attempt, workflow, commit, and conclusion.
+
+## Local inbox follow-up
+
+List each incorporated inbox entry, its outcome, and any resulting recommendation ID or finding. Do not copy the whole inbox.

.agents/skills/sync-agent-infra/SKILL.md

@@ -17,7 +17,7 @@ Run after adding, removing, or renaming a skill or crate; changing issue or PR c
 
 | Change | Skills to inspect |
 |---|---|
-| Issues, triage, labels, or feature proposals | `create-github-issue`, `triage-issue`, `create-spike`, `build-from-issue` |
+| Issues, triage, labels, or feature proposals | `create-github-issue`, `triage-issue`, `review-triage-queue`, `apply-triage-action`, `create-spike`, `build-from-issue` |
 | PR template, vouch behavior, or review conventions | `create-github-pr`, `review-github-pr`, `build-from-issue` |
 | Security assessment or remediation | `review-security-issue`, `fix-security-issue` |
 | Published docs workflow | `update-docs-from-commits` |

.agents/skills/watch-github-actions/SKILL.md

@@ -125,6 +125,10 @@ gh run list --json databaseId,status,headBranch,url --jq '.[] | {id: .databaseId
 
 ## View Job Logs
 
+`Release Tag` temporarily omits Codex Security from its `Security Scan` job.
+Other scanners and qualification gates still run. Use the standalone
+`Codex Security Release Qualification` workflow for manual investigation.
+
 For `Codex Security`, an exit code of 2 with partial coverage is an incomplete
 scan, not a HIGH/CRITICAL threshold failure. Check the execution diagnostics in
 the job summary and the `codex-security-diagnostics-<run>-<attempt>` artifact on