You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .agents/skills/gettokens-domain-engineering/SKILL.md
+11-2Lines changed: 11 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,7 +13,11 @@ This skill unifies the technical rules for building, styling, and debugging GetT
13
13
- Keep `provider` and `credentialSource` separate.
14
14
- Uniqueness is by asset (e.g., `auth-file:<name>`).
15
15
-`codex api key` records must prefer a persisted stable local id over a derived config fingerprint. Editing `apiKey / baseUrl / prefix` must not change the record id used by frontend selection, modal state, disable state, or rotation ordering.
16
-
- Duplicate detection for `codex api key` still uses the normalized config identity (`apiKey + baseUrl + prefix`), even when the persisted record id is stable.
16
+
- User-created or copied `codex api key` records may share the same normalized config identity (`apiKey + baseUrl + prefix`). Treat each persisted `local-id` as a separate editable account asset; store files should be keyed by `local-id` so duplicates do not overwrite each other.
17
+
- Legacy sidecar mirror data without `local-id` may still be deduplicated against a stored local record with the same normalized config identity to avoid reintroducing the historical double-card bug.
18
+
- Account-card copy/import must copy a structured account payload, not just a display name. The payload should round-trip all supported asset classes: `auth-file`, `codex-api-key`, and `openai-compatible`.
19
+
- Account-card clipboard writes must tolerate browser preview and Wails permission differences. Prefer a shared clipboard helper with DOM copy, Web Clipboard, Wails runtime, and app-local fallback paths instead of calling `navigator.clipboard.writeText` directly from card components.
20
+
- Copied account imports create a new editable asset even when the underlying config is identical. When the imported title/provider/file name already exists, append user-facing numeric suffixes from ` #2` onward; do not use `-copy` style suffixes. For auth-file imports, preserve `.json` after the numbered title, such as `codex-auth #2.json`.
17
21
- Do not fetch accounts until sidecar is `ready`.
18
22
- Reload from Wails after create/delete instead of hand-merging state.
19
23
-`codex api key` lives in local storage under `~/.config/gettokens-data/codex-api-keys/`, not in `auth-dir`.
@@ -120,7 +124,7 @@ This skill unifies the technical rules for building, styling, and debugging GetT
120
124
121
125
## 3.2 Codex Workspace & Local Config Surfaces
122
126
-**Codex Binary**: For Codex CLI binary version/source management, use the dedicated `gettokens-codex-binary-management` skill. Keep it as an independent binary-management business; do not merge it into account pool, local apply, usage, session, or routing flows.
123
-
-**Codex Account List / Channel Routing**: For Codex account request order, route probing, OAuth/auth-file model aliasing, openai-compatible model mappings, channel route mode, project bindings, and `#frame=codex&workspace=account-list`, use the dedicated `gettokens-codex-account-list` skill. In the Account Routing Engine rollout, Codex account list is the Codex Channel Routing workspace: channel order, route mode, channel group state, project bindings, dry-run/explain, and probe are Codex-owned channel config, not global account inventory priority.
127
+
-**Codex Account List / Channel Routing**: For Codex account request order, route probing, OAuth/auth-file model aliasing, openai-compatible model mappings, channel route mode, project bindings, and `#frame=codex&workspace=account-list`, use the dedicated `gettokens-codex-account-list` skill. In the Account Routing Engine rollout, Codex account list is the Codex Channel Routing workspace: channel order, route mode, channel group state, project bindings, dry-run/explain, and probe are Codex-owned channel config, not global account inventory priority. Current channel route mode is two-mode only: `sequential / balanced`; `project` is historical compatibility/scoping data, not a configurable mode.
124
128
-**Channel Routing Source of Truth**: For Codex / Claude runtime routing, `~/.config/gettokens-data/channel-routing/config.json` is the main decision source. Treat sidecar `routing.strategy` in `~/.config/gettokens/config.yaml` as legacy relay/config compatibility only; it must not drive Codex / Claude candidate ordering once channel routing is configured. The CLIProxyAPI fork should install GetTokens channel routing as a pool-scope route policy before legacy selectors, and balanced mode should read active-session counts from the live-session tracker instead of a display snapshot.
125
129
-**Codex Extensions**: For Codex Skills / MCP Servers, `[[skills.config]]`, `tk://github.com` / `tk://gitlab.com` skill sources, and `#frame=codex&workspace=skills|mcp-servers`, use the dedicated `gettokens-codex-extensions-management` skill. Keep source-accurate parsing, modal/list UI semantics, and cleanup split rules in that skill instead of expanding this general domain skill.
126
130
-**Claude Code Workspace Parity**: When Claude Code adds a capability that corresponds to existing Codex workspace entries, keep the workspace granularity aligned with Codex unless Claude semantics clearly require a different information architecture.
@@ -164,6 +168,7 @@ This skill unifies the technical rules for building, styling, and debugging GetT
164
168
- Trend chart x positions should read as request sequence, not timestamp spacing. Keep request records sorted by `startedAt`, then render the visible slice as dense equal-step bars with `#sequence` as the x-axis label; do not stretch sparse requests across real elapsed gaps.
165
169
- Trend chart data window is a fixed count cap, not a fixed time window. Keep only the latest capped request points for the chart model, so new requests push the sequence labels forward (`#50` -> `#51` -> `#52`) while the visible data volume remains bounded.
166
170
- Trend chart viewport should be a fixed, non-scrollable audio waveform chart. The visible request count is width-driven: wider surfaces show more recent request bars, narrower surfaces show fewer, and the latest request stays anchored near the right edge. Do not reintroduce horizontal panning or auto-scroll follow logic.
171
+
- The timing metric picker below the chart summarizes the same trend window. Show average values for `total / TTFT / first token / stream / queue / auth select / connect / gaps / rates` rather than echoing the latest single request; keep latest-request values in the timeline rows and chart footer.
167
172
- Keep the live-session chart visually inside the page section, not as a nested card. Use the existing Swiss-industrial chart tokens, footer summaries below the graph, and live markers such as dashed strokes/rings for in-flight samples.
168
173
- Request timing trend visuals should read like a forward-moving audio waveform, not a finance line, ECG trace, or candlestick chart. Render exactly one centered vertical amplitude bar per request for the selected timing metric; longer durations produce taller bars, and live rings distinguish in-flight samples.
169
174
- Timing trend motion should not redraw the full waveform on every live refresh. Keep bars steady; use a short opacity settle only when switching metrics and a subtle breathing ring on the live sample to indicate activity.
@@ -290,6 +295,10 @@ This skill unifies the technical rules for building, styling, and debugging GetT
290
295
- keep locators/debug metadata available, but visually subordinate to the main decision path
291
296
-**Action Selects**: For `select + right-side actions` patterns, use the project-level `frontend/src/components/ui/ActionSelect.tsx` instead of hand-rolling label/select/button grids. Keep `+` and optional delete actions inside the select frame so field widths align across sibling rows.
292
297
-**Status Local CLI Config**: In `StatusApplyLocalSection`, Codex and Claude Code tabs must share field components for equivalent concepts such as Relay API key, endpoint/base URL, provider, and model. Do not maintain parallel JSX just because one tab has fewer fields.
298
+
- Provider and model controls must preserve source casing and source identity. Do not force uppercase through shared controls, labels, badges, or status hints.
299
+
- The Codex provider picker displays the `model_provider` id only. Do not concatenate display name and id with `/` or maintain a separate display-name input for new local provider options unless a later requirement introduces that distinction explicitly.
300
+
- Initial Codex provider/model selection should prefer explicit values from `config.toml`; UI localStorage is secondary. If Codex has no explicit root `model_provider`, the Status page may default to the GetTokens relay provider; if Codex has no explicit root `model`, fall back to `RELAY_CODEX_DEFAULT_MODEL`.
301
+
- Legacy UI-only model fallbacks such as `GT` must be treated as migration inputs, not as active defaults. Filter them from stored model option lists and lock the migration with focused local-state tests.
293
302
-**Codex Feature Config UI**: The local Codex `[features]` bool editor is a config list, not a data table. Each feature is one row with feature key as the title, stage as a compact tag before the subtitle, localized description as the subtitle, and the switch as the only bool value expression. Do not add duplicate `default/local/on/off` value labels when the switch already communicates the state. Do not force feature keys or descriptions to uppercase; preserve source and localization casing.
294
303
-**Account Cards**: Account cards should support whole-card detail entry, but clicks originating from nested interactive controls (`button`, `input`, etc.) must not trigger the card-level detail action.
0 commit comments