fix(copilot): route responses-only models (grok-4.x, gpt-5.x) to /responses API

.github/FUNDING.yml

@@ -0,0 +1 @@
+github: [1jehuang]

.github/workflows/ci.yml

@@ -1,8 +1,5 @@
 name: CI
 
-env:
-  JCODE_CI: "1"
-
 on:
   push:
     branches: [main, master]
@@ -14,6 +11,7 @@ concurrency:
   cancel-in-progress: true
 
 env:
+  JCODE_CI: "1"
   CARGO_TERM_COLOR: always
   SCCACHE_GHA_ENABLED: "true"
 
@@ -42,13 +40,6 @@ jobs:
           key: quality-ubuntu
           cache-all-crates: "true"
 
-      - name: Install system dependencies
-        # jcode-desktop2 pulls yeslogic-fontconfig-sys, whose build script hard
-        # fails without fontconfig.pc. Without this the "Enforce desktop2 frame
-        # budget" step cannot even build, and `cargo check --all-targets
-        # --all-features` above is affected the same way.
-        run: sudo apt-get update && sudo apt-get install -y -qq libfontconfig1-dev
-
       - name: Check module declarations resolve
         # A `mod x;` with no file makes rustfmt fail with "Error writing files:
         # failed to resolve mod", which reads like a formatting problem and hides
@@ -105,22 +96,6 @@ jobs:
         shell: bash
         run: python3 scripts/check_wildcard_reexport_budget.py
 
-      # Frame-cost gate for desktop2. `build_scene` is a pure function of its
-      # model and `states::NODES` enumerates the app's visual states, so frame
-      # cost is something CI can evaluate rather than something a person has to
-      # notice by using the app and reporting that it feels slow.
-      #
-      # The decisive assertion is about work, not time: an unchanged frame must
-      # not lay the transcript out again. That is exact, so it fires on a
-      # contended CI runner exactly as it does locally, unlike a wall-clock
-      # budget which has to carry enough slack to hide real regressions.
-      #
-      # Runs on the default profile so it reuses this job's existing build
-      # artifacts rather than compiling a second dependency tree.
-      - name: Enforce desktop2 frame budget
-        shell: bash
-        run: "cargo test -p jcode-desktop2 profile:: -- --test-threads=1"
-
       - name: Enforce no unused dependencies
         shell: bash
         run: |
@@ -392,8 +367,10 @@ jobs:
         run: |
           ./scripts/check_powershell_syntax.ps1
 
-      - name: Enforce warning budget (Linux)
-        if: runner.os == 'Linux'
+      # Linux and macOS. Windows still has its own cfg-gated surface and is
+      # not yet warning-clean, so it stays out of the gate (#1177).
+      - name: Enforce warning budget (Linux, macOS)
+        if: runner.os == 'Linux' || runner.os == 'macOS'
         shell: bash
         run: |
           scripts/check_warning_budget.sh

.github/workflows/discord-release.yml

@@ -25,6 +25,11 @@ permissions:
 
 jobs:
   announce:
+    # Same rule as `release.yml`: announcing is an outbound side effect, so it
+    # belongs to the canonical repository. On a fork the webhook secret is
+    # absent and the step would fail rather than post, but the guard makes that
+    # independent of whether the fork happens to hold the secret.
+    if: github.repository == '1jehuang/jcode'
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v4

.github/workflows/freebsd-smoke.yml

@@ -26,6 +26,9 @@ on:
     # Weekly drift check so FreeBSD breakage is caught even without a push.
     - cron: '0 7 * * 1'
 
+permissions:
+  contents: read
+
 concurrency:
   group: freebsd-smoke-${{ github.ref }}
   cancel-in-progress: true

.github/workflows/ios-testflight.yml

@@ -1,8 +1,5 @@
 name: iOS TestFlight
 
-env:
-  JCODE_CI: "1"
-
 on:
   workflow_dispatch:
   push:
@@ -16,6 +13,7 @@ concurrency:
   cancel-in-progress: true
 
 env:
+  JCODE_CI: "1"
   BUNDLE_ID: com.jcode.mobile
   SCHEME: JCodeMobile
   TEAM_ID: TAS6ARKDN7

.github/workflows/label-pr.yml

@@ -0,0 +1,43 @@
+name: Semantic PR labels
+on:
+  workflow_dispatch:
+    inputs:
+      pull-request:
+        description: Existing open PR number (waits for a completed Greptile review)
+        required: true
+        type: string
+  check_run:
+    types: [completed]
+  check_suite:
+    types: [completed]
+permissions:
+  contents: read
+  checks: read
+  pull-requests: write
+  issues: write
+jobs:
+  label:
+    if: >-
+      github.event_name == 'workflow_dispatch' ||
+      (github.event.check_run.app.id == 867647 &&
+       github.event.check_run.name == 'Greptile Review') ||
+      (github.event_name == 'check_suite' && github.event.check_suite.app.id == 867647)
+    # Apply the trusted-app condition before acquiring a concurrency slot.
+    # Other apps' checks must never displace a pending Greptile completion.
+    concurrency:
+      group: jev-labels-${{ github.repository }}-${{ github.event.check_run.app.id || github.event.check_suite.app.id || 'manual' }}-${{ github.event.check_run.head_sha || github.event.check_suite.head_sha || inputs.pull-request }}
+      cancel-in-progress: false
+    runs-on: ubuntu-latest
+    timeout-minutes: 5
+    steps:
+      # Reviewed action code, pinned to an immutable revision.
+      # No PR checkout or PR-controlled executable code.
+      - uses: 1jehuang/jev-pr-labeler@267b789247298b06e04fcf3cac01730694c9dcb5
+        with:
+          github-token: ${{ secrets.GITHUB_TOKEN }}
+          openrouter-api-key: ${{ secrets.OPENROUTER_API_KEY }}
+          repository: ${{ github.repository }}
+          pull-request: ${{ inputs.pull-request }}
+          check-sha: ${{ github.event.check_run.head_sha || github.event.check_suite.head_sha }}
+          require-greptile: 'true'
+          apply: 'true'

.github/workflows/release.yml

@@ -21,6 +21,14 @@ permissions:
 jobs:
   create-release:
     name: Create release
+    # Publish only from the canonical repository. A fork that runs this
+    # workflow on a `v*` tag would otherwise create a release carrying that
+    # upstream version number with binaries built from the fork, which is the
+    # same class of accidental-publication path as a fork pushing a package.
+    # Every other job in this workflow needs `create-release`, directly or
+    # transitively, so gating this one job skips the whole workflow: a skipped
+    # dependency skips its dependents.
+    if: github.repository == '1jehuang/jcode'
     runs-on: ubuntu-latest
     timeout-minutes: 10
     steps:

.github/workflows/windows-smoke.yml

@@ -1,8 +1,5 @@
 name: Windows Smoke
 
-env:
-  JCODE_CI: "1"
-
 on:
   workflow_dispatch:
     inputs:
@@ -21,6 +18,7 @@ concurrency:
   cancel-in-progress: true
 
 env:
+  JCODE_CI: "1"
   CARGO_TERM_COLOR: always
   SCCACHE_GHA_ENABLED: "true"
 

.gitignore

@@ -12,8 +12,7 @@ ios_simulator_screenshot.png
 target-ttest/
 target-ttest*/
 
-# Offscreen frames written by `jcode-desktop2 --capture`. These are review
-# artefacts for a single change, not committed baselines.
+# Local capture artefacts are not committed baselines.
 captures/
 
 # Stray experiment/debug artifacts at the repo root. Real assets live under

.jcode/semantic-todo-migration-spec.md

@@ -133,5 +133,5 @@ block persisting.
   `cargo test -p jcode-app-core todo`, `cargo test -p jcode-tui todo`,
   `cargo check -p jcode-tui -p jcode-telemetry-core`.
 
-Do NOT touch unrelated dirty files (desktop2, render-core, etc). Commit nothing;
+Do NOT touch unrelated dirty files. Commit nothing;
 the coordinator commits.

AGENTS.md

@@ -1,12 +1,24 @@
 # Repository Guidelines
 
+## Repository Scope
+
+- Jcode Desktop is in a separate repository.
+
 ## Development Workflow
 
-- **Stay on your own branch** - Do not take, cherry-pick, merge, or copy code from other
-  people's or other agents' branches unless the source branch belongs to a repository
-  maintainer and the user explicitly asks you to integrate it. Only work from your branch
-  and its base (e.g. `main`) otherwise. Never integrate branches owned by non-maintainers
-  or other agents yourself; tell the user and let them decide how to proceed.
+- **Use the user's Git identity** - Create commits with the configured
+  `user.name` and `user.email`. Do not override them with `Jcode`, `Jcode agent`,
+  or a fabricated agent email. Preserve existing contributor attribution when
+  integrating work. If no identity is configured, ask rather than inventing one.
+- **Welcome pull requests from everyone** - Review contributions on their merits,
+  regardless of whether the author is a maintainer, an existing contributor, a
+  first-time contributor, or an agent. Good PRs can be merged directly after review
+  and validation. Do not require a maintainer-authored rewrite merely because of
+  who submitted the change. See `CONTRIBUTING.md` for the contribution policy.
+- **Keep work scoped** - Work on your own branch and preserve unrelated work. When
+  the user asks you to review or integrate a PR or branch, you may inspect, test,
+  and integrate that contribution regardless of author status. Do not pull in
+  unrelated branches or merge a PR without user authorization.
 
 ## Install Notes
 - `~/.local/bin/jcode` is the launcher symlink used from `PATH`.

CLAUDE.md

@@ -0,0 +1,8 @@
+# Repository Instructions
+
+@AGENTS.md
+
+Follow `AGENTS.md` for the development workflow and `CONTRIBUTING.md` for the
+contribution policy. Pull requests from everyone are welcome for direct review
+and merging, regardless of contributor or maintainer status. Preserve unrelated
+work and obtain user authorization before merging.

CONTRIBUTING.md

@@ -4,28 +4,28 @@ Thanks for contributing.
 
 ## Issues vs pull requests
 
-If the problem is easy for me to reproduce, please prefer opening a GitHub issue. A clear issue with reproduction steps, expected behavior, actual behavior, logs, screenshots, or traces is usually the fastest path to a fix.
+Both issues and pull requests are welcome. Open an issue to report a bug or discuss an idea, or send a focused PR if you have a fix or improvement ready. For large changes, discuss the approach in an issue first to avoid spending time on work that may not fit the project.
 
-Pull requests are more useful when the problem depends on an environment I may not have, such as macOS-specific behavior, Windows-specific behavior, unusual shells, terminal emulators, filesystems, GPU/display setups, provider accounts, or other local configuration. In those cases, a PR can be a useful reference because it captures the behavior in the environment where the problem actually occurs.
+A clear issue or PR includes reproduction steps, expected behavior, actual behavior, and relevant logs, screenshots, or traces. Environment-specific fixes are especially helpful when they cover systems the maintainers may not have, such as macOS, Windows, unusual shells, terminal emulators, filesystems, GPU/display setups, or provider accounts.
+
+Every PR must link to an existing GitHub issue in this repository. If there is no issue yet, open one and reference it in the PR description, for example with `Closes #123`.
 
 ## Pull request policy
 
-Pull requests are welcome and encouraged.
+Pull requests from everyone are welcome and encouraged, including first-time contributors and people who are not maintainers or existing contributors.
 
-That said, most PRs should be treated as proposals or references, not as changes that are likely to be merged directly. This project is developed with heavy use of code generation, and generated code can be deceptively plausible: it may fix the visible problem while introducing subtle correctness, lifecycle, architecture, or maintenance issues.
+PRs are reviewed as changes that can be merged directly, not merely as proposals or references for a maintainer-authored rewrite. Review is based on correctness, tests, security, architecture, maintainability, and fit with the project, not the author's contributor status.
 
-Because of that, I will often use PRs to understand the bug, feature request, test case, design direction, or proposed implementation, then write my own version of the change. The submitted code may still be extremely valuable as a reference, reproduction, or proof of concept, even if the final committed code is different.
+AI-assisted and generated contributions are welcome and held to the same standards as handwritten code. Understand the changes you submit, explain their assumptions and tradeoffs, and validate them. This applies equally to maintainer and community contributions.
 
-This is not a judgment that maintainer-generated code is inherently better than contributor-generated code. It is a practical ownership rule: if I am going to maintain the resulting code, I need to understand its assumptions, tradeoffs, and failure modes.
+Maintainers may request revisions, help refine an implementation, or decline a change that does not fit the project. A rewrite is not required just because a PR comes from an outside contributor.
 
-The best PRs therefore include:
+The best PRs include:
 
 - a clear description of the problem being solved
 - a minimal reproduction or failing test when possible
 - notes about edge cases and tradeoffs
 - focused changes that are easy to review independently
 - any relevant logs, screenshots, traces, or benchmarks
 
-Large, generated, or highly invasive PRs may be closed even when the underlying idea is good. In those cases, the issue or PR may still be used as a reference for a maintainer-authored change.
-
-Handwritten by author: My clanker slop may or may not be better than your clanker slop. I know how to work with my clanker slop though.
+Keep changes focused and split large changes into independently reviewable pieces when possible. Passing checks does not guarantee a merge, but author status or use of code generation is not, by itself, a reason to reject a contribution.