flower-trellis 0.4.0-beta.5 → 0.4.1

package/enhancements/0.6/overrides/skills/trellis-finish-work.md

@@ -22,7 +22,7 @@ If no `release.md` exists:
 - High-confidence no release work exists after re-reading task files and git evidence: do not create `release.md`; mention in the final finish-work report that no release operations were identified.
 - Signals are uncertain but release risk exists: write `<task>/release.md` and mark the conclusion as `Needs human review`.
 
-Release-operation signals include SQL or migrations; configuration, environment variables, feature flags, permissions, secrets, or external endpoints; deployment scripts, one-off commands, data repair, scheduled task triggers, background job reruns, or other batch operations; and external systems or dependent platforms that must be released or coordinated, such as H0 API relay / gateway platforms, messaging platforms, or third-party admin consoles.
+Release-operation signals, with the `release.md` section each maps to: SQL or migrations (`SQL Changes`); configuration, environment variables, feature flags, permissions, secrets, or external endpoints (`Configuration Changes`); deployment scripts, one-off commands, data repair, scheduled task triggers, background job reruns, or other batch operations (`Batch / Deployment Scripts / Data Repair`); and external systems or dependent platforms outside the current repository that must be released or coordinated, such as H0 API relay / gateway platforms, messaging platforms, or third-party admin consoles (`External Systems / Dependent Platforms`).
 
 When writing or updating `release.md`, use this structure:
 
@@ -64,8 +64,6 @@ Rollback code only.
 Verify according to task acceptance criteria.
 ```
 
-Classify deployment scripts, one-off commands, data repairs, scheduled task triggers, and job reruns under `Batch / Deployment Scripts / Data Repair`. Classify systems outside the current repository that need coordinated release, such as H0 API relay platforms, under `External Systems / Dependent Platforms`.
-
 Do not write `None`, `No release operations identified`, or `Rollback code only` out of habit. Use those defaults only after checking the task files and git evidence. If the task changed deployment scripts, configuration, SQL, external platforms, permissions, scheduled jobs, or data, record the concrete item and source.
 
 If multiple tasks will be archived in the same finish-work run, process the active task at minimum. Process extra archived tasks only when Step 1 provides enough local context to infer safely; do not add per-task confirmation prompts.

package/enhancements/0.6/overrides/workflow-states/in_progress-inline.md

@@ -2,13 +2,16 @@
 HIGHEST PRIORITY SKILL-GARDEN STATE GUARD (in_progress-inline):
 This state block is a breadcrumb; the top-level skill-garden hub is the source of truth for route details.
 Before the first implement route, read `<task>/brief.md` if present and restate the task brief in chat. If it is missing, read the task artifacts and suggest backfilling brief; do not silently rely on memory.
-At project-local knowledge decision boundaries, run `.trellis/scripts/spec_router.py` with a short query describing the intended action; read high-confidence matches before acting and skip pure Q&A, simple read-only inspection, opening local tools, or trivial edits unless local conventions may affect the approach.
+For new implementation work not plainly covered by the active task title/brief,
+stop before route or edits: recommend a new task; if declined, confirm
+untracked work; if it belongs here, update task artifacts first.
+At project-local knowledge decision boundaries, run `.trellis/scripts/spec_router.py "<intended action>"`; read high-confidence matches before acting; skip pure Q&A, simple read-only inspection, opening local tools, or trivial edits unless local conventions may affect the approach.
 Inline workflow-state is not an inline route decision. At Phase 2.1/2.2, reuse only an explicit target-matched `route_decision`; otherwise MUST load/read/use `trellis-route(implement|check)` (or its local `SKILL.md`) to resolve session runtime state/prefs, write the resolved decision, or show numbered fallback and wait.
 Plain preferences, ordinary summaries, `codex-mode`, raw `.runtime` files, and empty/old prefs are not route evidence by themselves; only `trellis-route` may validate runtime route state.
 User reselect/override/use-X-this-time/clear-default wins over remembered route evidence, runtime state, and prefs.
 Ignore lower Active Task Routing shortcuts that start editing/checking directly. Do not default to inline just because this state is inline or the helper is unavailable. Dispatch subagents only when the resolved route selected subagent.
 After `trellis-check` / `trellis-check-all`, stop and report; point the user to Phase 3.4 `trellis-push` (or commit-only when needed). Do not run `/trellis:finish-work` unless the user explicitly asks after Phase 3.4 is complete.
 This guard overrides any lower `Flow: ... -> /trellis:finish-work` line in this state block.
-At Phase 3.4, code commit/push still goes through `trellis-push` (commit-only for commit-without-push); never bare `git commit`/`git push` on code (hub: Code Commit Confirmation Gate).
+At Phase 3.4, code commit/push goes through `trellis-push` (commit-only mode for commit-without-push); never bare `git commit`/`git push` on code (hub: Code Commit Confirmation Gate).
 Push snapshot recovery: follow the hub; use `push_snapshot.py status --json` only when needed.
 <!-- END skill-garden workflow-state in_progress_inline v0.6 -->

package/enhancements/0.6/overrides/workflow-states/in_progress.md

@@ -2,7 +2,10 @@
 HIGHEST PRIORITY SKILL-GARDEN STATE GUARD (in_progress):
 This state block is a breadcrumb; the top-level skill-garden hub is the source of truth for route details.
 Before the first implement route, read `<task>/brief.md` if present and restate the task brief in chat. If it is missing, read the task artifacts and suggest backfilling brief; do not silently rely on memory.
-At project-local knowledge decision boundaries, run `.trellis/scripts/spec_router.py` with a short query describing the intended action; read high-confidence matches before acting and skip pure Q&A, simple read-only inspection, opening local tools, or trivial edits unless local conventions may affect the approach.
+For new implementation work not plainly covered by the active task title/brief,
+stop before route or edits: recommend a new task; if declined, confirm
+untracked work; if it belongs here, update task artifacts first.
+At project-local knowledge decision boundaries, run `.trellis/scripts/spec_router.py "<intended action>"`; read high-confidence matches before acting; skip pure Q&A, simple read-only inspection, opening local tools, or trivial edits unless local conventions may affect the approach.
 At Phase 2.1/2.2, reuse only an explicit target-matched `route_decision`; otherwise MUST load/read/use `trellis-route(implement|check)` (or its local `SKILL.md`) to resolve session runtime state/prefs, write the resolved decision, or show numbered fallback and wait.
 Plain preferences, ordinary summaries, `codex-mode`, raw `.runtime` files, and empty/old prefs are not route evidence by themselves; only `trellis-route` may validate runtime route state.
 User reselect/override/use-X-this-time/clear-default wins over remembered route evidence, runtime state, and prefs.

package/enhancements/0.6/overrides/workflow-states/no_task.md

@@ -3,7 +3,7 @@ HIGHEST PRIORITY SKILL-GARDEN STATE GUARD (no_task):
 Creating or resuming a task is not implementation permission.
 After PRD is ready and the task is started, the next implementation action is Phase 2.1 `trellis-route(implement)` unless a valid current-task implement route decision already exists.
 If no active task exists, use `push_snapshot.py status --json` once per session; if it returns candidates, relay them and suggest rebinding before resuming.
-At project-local knowledge decision boundaries, run `.trellis/scripts/spec_router.py` with a short query describing the intended action; read high-confidence matches before acting and skip pure Q&A, simple read-only inspection, opening local tools, or trivial edits unless local conventions may affect the approach.
+At project-local knowledge decision boundaries, run `.trellis/scripts/spec_router.py "<intended action>"`; read high-confidence matches before acting; skip pure Q&A, simple read-only inspection, opening local tools, or trivial edits unless local conventions may affect the approach.
 Do NOT call the harness built-in plan mode (`EnterPlanMode` / `ExitPlanMode`) for Trellis planning. It is not a substitute for Trellis task-creation consent, Trellis planning, or the route gate. For complex work, classify the turn, ask for task-creation consent, then use `trellis-brainstorm`.
 If the turn is a meta edit to Trellis itself and Trellis tracking would be overkill, say so and ask to skip Trellis; never silently swap built-in plan mode in for the consent gate.
 <!-- END skill-garden workflow-state no_task v0.6 -->

package/enhancements/0.6/overrides/workflow-states/planning-inline.md

@@ -4,6 +4,6 @@ Planning is not implementation permission.
 Complete prd.md + required context first.
 If the active workflow later routes to sub-agent execution, required context includes real curated entries in both `implement.jsonl` and `check.jsonl`; the seed `_example` row alone is not ready.
 Before `task.py start`, use `trellis-task-brief` to refresh `brief.md` from the latest task artifacts and display it in chat for review.
-At project-local knowledge decision boundaries, run `.trellis/scripts/spec_router.py` with a short query describing the intended action; read high-confidence matches before acting and skip pure Q&A, simple read-only inspection, opening local tools, or trivial edits unless local conventions may affect the approach.
+At project-local knowledge decision boundaries, run `.trellis/scripts/spec_router.py "<intended action>"`; read high-confidence matches before acting; skip pure Q&A, simple read-only inspection, opening local tools, or trivial edits unless local conventions may affect the approach.
 After status becomes in_progress, next action = `trellis-route(implement)`, not direct edits.
 <!-- END skill-garden workflow-state planning_inline v0.6 -->

package/enhancements/0.6/overrides/workflow-states/planning.md

@@ -4,6 +4,6 @@ Planning is not implementation permission.
 Complete prd.md + required context first.
 For sub-agent-dispatch platforms, required context includes real curated entries in both `implement.jsonl` and `check.jsonl`; the seed `_example` row alone is not ready.
 Before `task.py start`, use `trellis-task-brief` to refresh `brief.md` from the latest task artifacts and display it in chat for review.
-At project-local knowledge decision boundaries, run `.trellis/scripts/spec_router.py` with a short query describing the intended action; read high-confidence matches before acting and skip pure Q&A, simple read-only inspection, opening local tools, or trivial edits unless local conventions may affect the approach.
+At project-local knowledge decision boundaries, run `.trellis/scripts/spec_router.py "<intended action>"`; read high-confidence matches before acting; skip pure Q&A, simple read-only inspection, opening local tools, or trivial edits unless local conventions may affect the approach.
 After status becomes in_progress, next action = `trellis-route(implement)`, not direct edits.
 <!-- END skill-garden workflow-state planning v0.6 -->

package/enhancements/0.6/overrides/workflow.md

@@ -6,17 +6,17 @@
 
 **Priority**: This hub overrides any conflicting Trellis workflow, skill, or command text for the scoped behaviors below.
 
-**Scope**: project knowledge discovery at project-local knowledge decision boundaries, Phase 1.4 task brief handoff, Phase 2.1 implement routing, Phase 2.2 check/check-all routing, current-task route reuse, post-check stop, auto-loop commit-only preauthorization, Phase 3.4 trellis-push, explicit Phase 3.5 finish-work bookkeeping, and push-progress recovery. State blocks should keep one short skill-garden sentinel; long-form rules live here.
+**Scope**: the behaviors covered by the sections below. State blocks should keep one short skill-garden sentinel; long-form rules live here.
 
 **Mechanical rule**: use this hub as the source of truth. Do not add separate top-level skill-garden override sections or multiple skill-garden sentinels inside the same `workflow-state:*` block.
 
 #### Project Knowledge Discovery
 
 Before choosing an approach for non-trivial project work, run project knowledge
-discovery when project-local SOPs, package conventions, workflow rules,
-config/state contracts, release/publish/deploy steps, git history actions,
-data changes, cross-layer design, generated artifacts, install/sync pipelines,
-or destructive operations may affect the correct approach:
+discovery when project-local SOPs, package conventions, workflow rules (CI, hooks),
+config/state contracts, release/publish/deploy/rollback steps, git history actions,
+data changes or fixes (including migrations), cross-layer design, generated artifacts,
+install/sync pipelines, or destructive operations may affect the correct approach:
 
 ```bash
 python3 ./.trellis/scripts/spec_router.py "<short query describing the intended action>"
@@ -24,8 +24,7 @@ python3 ./.trellis/scripts/spec_router.py "<short query describing the intended
 
 Build the query from the current user request plus relevant immediate context:
 the intended action, commands about to run, files or systems involved, package/layer,
-and domain words such as release, publish, deploy, migration, config, CI, workflow,
-hooks, rollback, data fix, generated artifact, install/sync pipeline, or destructive command.
+and domain words matching the trigger list above.
 
 Read high-confidence matches before acting. For medium-confidence matches, read only
 when the path, heading, index description, or reason clearly fits the intended change.
@@ -43,6 +42,16 @@ Before Phase 1.4 `task.py start`, use `trellis-task-brief` to refresh `<task>/br
 
 Before the first implement route, restate existing `<task>/brief.md` in chat. If missing, read task artifacts and suggest backfilling brief; do not invent one from memory.
 
+#### Active Task Scope Guard
+
+When a session already has an active task, do not treat unrelated new implementation
+requests as permission to implement under that task. If the work is not plainly
+covered by the active task title/brief, recommend creating a new Trellis task
+and stop before `trellis-route` or file edits. If the user explicitly declines
+task tracking, confirm untracked work first and do not use active-task artifacts
+or progress for that work. If the user says it belongs to the active task,
+update that task's artifacts before implementation.
+
 #### Routing Gate
 
 Phase 2.1 implement and Phase 2.2 check/check-all require route evidence before execution.
@@ -50,11 +59,10 @@ Phase 2.1 implement and Phase 2.2 check/check-all require route evidence before
 At each route boundary:
 
 1. Reuse only an explicit, target-matched `route_decision` already present in the current context.
-2. Otherwise you MUST load/read/use `trellis-route(target=implement|check)` before deciding. `trellis-route` owns session runtime recovery, `.route-prefs.tmp`, fallback choices, runtime-state writes, and dispatch mapping.
-3. If the platform cannot invoke skills directly, open the local `trellis-route/SKILL.md` copy first, then follow its numbered fallback choices in normal chat and wait.
-4. If the route helper cannot ask through `AskUserQuestion` / `request_user_input`, ask the same numbered choices from `trellis-route` in normal chat and wait.
+2. Otherwise you MUST invoke `trellis-route(target=implement|check)` before deciding; if the platform cannot invoke skills directly, read the local `trellis-route/SKILL.md` copy and follow its numbered fallback choices in normal chat and wait. `trellis-route` owns session runtime recovery, `.route-prefs.tmp`, fallback choices, runtime-state writes, and dispatch mapping.
+3. If the route helper cannot ask through `AskUserQuestion` / `request_user_input`, ask the same numbered choices from `trellis-route` in normal chat and wait.
 
-Plain user preference, ordinary compact/SessionStart summary, ordinary summary, replacement history, historical bare numeric replies, `codex-mode`, empty/old prefs, and raw `.trellis/.runtime/sessions/*` `route_decisions` content that has not been validated by `trellis-route` are not route evidence by themselves; numbered fallback validity is governed by `trellis-route`.
+Plain user preference, ordinary summaries (compact/SessionStart or otherwise), replacement history, historical bare numeric replies, `codex-mode`, empty/old prefs, and raw `.trellis/.runtime/sessions/*` `route_decisions` content that has not been validated by `trellis-route` are not route evidence by themselves; numbered fallback validity is governed by `trellis-route`.
 
 User reselect/override/use-X-this-time/clear-default wins over remembered route evidence, runtime state, and personal prefs.
 
@@ -62,9 +70,7 @@ At Phase 2.1/2.2, this gate overrides lower "Active Task Routing" rows that say
 
 #### Post-Check Stop Gate
 
-After `trellis-check` or `trellis-check-all` finishes, stop and report the result; point the user to Phase 3.4 `trellis-push` (or commit-only when needed). Do not run `/trellis:finish-work`, do not archive the task, and do not imply the task is ready to wrap up solely because checks passed.
-
-If checks pass, the next allowed workflow steps are Phase 3.3 `trellis-update-spec` and Phase 3.4 `trellis-push`/commit confirmation. `/trellis:finish-work` is explicit-only: run it only after Phase 3.4 is complete and the user asks to wrap up, archive, or finish the task.
+After `trellis-check` or `trellis-check-all` finishes, stop and report the result. If checks pass, the next allowed workflow steps are Phase 3.3 `trellis-update-spec` and Phase 3.4 `trellis-push`/commit confirmation (commit-only when needed); do not archive the task or imply it is ready to wrap up solely because checks passed. `/trellis:finish-work` is explicit-only: run it only after Phase 3.4 is complete and the user asks to wrap up, archive, or finish the task.
 
 During a running `trellis-auto-loop`, the runner's `record` + `next` replaces the post-check stop gate: after a check pass, record the result, then continue to spec update / commit-only according to `.trellis/scripts/auto_loop.py`. Outside auto-loop, keep the normal stop gate.
 
@@ -84,7 +90,7 @@ This exception does not apply to ordinary `trellis-push`. If the plan contains u
 
 #### Bookkeeping Auto-commit Scope
 
-`session_auto_commit` only governs the bookkeeping commits `task.py archive` / `add_session.py` make for their own `.trellis/tasks/**` and `.trellis/workspace/**` files — never code (gated above). When `false`, those archive/journal writes stay disk-only (no compensating `git commit`).
+`session_auto_commit` only governs the bookkeeping commits `task.py archive` / `add_session.py` make for their own `.trellis/tasks/**` and `.trellis/workspace/**` files. When `false`, those archive/journal writes stay disk-only (no compensating `git commit`).
 
 #### Push Progress Recovery / Snapshot
 

package/enhancements/MANIFEST.json

@@ -1,14 +1,13 @@
 {
-  "syncedAt": "2026-07-02T01:39:38.800Z",
+  "syncedAt": "2026-07-06T15:58:44.168Z",
   "syncedFrom": "vendor/skill-garden",
-  "sourceCommit": "39a09335cc3e2878c1e1121137dd55524882b13f",
+  "sourceCommit": "5fdebe60e923c91ba912461b99413b5c8e11a38c",
   "common": {
     "codexSkills": [
       "craft-rpa",
       "craft-slides",
       "humanize-writing",
       "open-idea",
-      "sub2api-account-json-fix",
       "torrent-analyze"
     ],
     "claudeSkills": [
@@ -16,7 +15,6 @@
       "craft-slides",
       "humanize-writing",
       "open-idea",
-      "sub2api-account-json-fix",
       "torrent-analyze"
     ]
   },

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "flower-trellis",
-  "version": "0.4.0-beta.5",
+  "version": "0.4.1",
   "description": "一键安装/升级 Trellis 并自动融合 skill-garden 强化包(默认 Claude + agents)",
   "type": "module",
   "bin": {

package/src/lib/skill-catalog.js

@@ -40,7 +40,6 @@ const SKILL_DESCRIPTION_OVERRIDES = {
   "plan-version": "规划版本任务、波次和分工",
   push: "提交、推送并同步任务进度",
   "re-implement": "需求变更后重新实现",
-  "sub2api-account-json-fix": "批量补全并推送 sub2api 账号 JSON",
   "sync-prd": "根据代码或需求变化同步 PRD",
   "torrent-analyze": "解析磁链或种子 hash 并整理信息",
   "trellis-analyze-task": "深度分析并细化任务",

package/enhancements/common/.common/.claude/skills/sub2api-account-json-fix/SKILL.md

@@ -1,47 +0,0 @@
----
-name: sub2api-account-json-fix
-description: 修正当前项目里的 sub2api 账号导出 JSON，并把这些账号直接推送到 sub2api admin 接口。用于批量推送 `sub2api-account-*.json` 到远端 sub2api，尤其适合先同步模板里的 `model_mapping`、`allow_overages`，再按指定 group_ids 创建账号。
-argument-hint: <template-json> [target-json...]
-disable-model-invocation: true
----
-
-# Sub2API 账号推送
-
-先确认模板账号，再运行项目内的推送脚本。
-
-## 规则
-
-- 先用模板账号补齐目标账号的 `credentials.model_mapping`。
-- 确保目标账号包含 `extra.allow_overages`。
-- 把 `name` 改成 `credentials.email`。
-- 然后把代理推送到 sub2api，再逐个创建账号。
-- 创建账号后默认立刻关闭调度。
-- 如果账号带有 `refresh_token`，创建后默认立刻调用一次 refresh，确保远端拿到最新 access token。
-- 如果 `.claude/skills/sub2api-account-json-fix/env/push.env` 不存在，继续检查系统环境变量。
-- 如果地址或 token 仍未配置，或者 token 还是 `admin-xxxx` 这种示例值，先向用户索要真实值，不要直接推送。
-
-## 技能目录配置
-
-优先读取：
-
-- `.claude/skills/sub2api-account-json-fix/env/push.env`
-
-支持这些键：
-
-- `SUB2API_ACCOUNT_JSON_FIX_PUSH_ADMIN_BASE_URL`
-- `SUB2API_ACCOUNT_JSON_FIX_PUSH_TOKEN`
-- `SUB2API_ACCOUNT_JSON_FIX_PUSH_GROUP_IDS`
-- `SUB2API_ACCOUNT_JSON_FIX_PUSH_SCHEDULABLE`
-- `SUB2API_ACCOUNT_JSON_FIX_PUSH_REFRESH_AFTER_CREATE`
-
-## 执行方式
-
-如果用户给了参数，按“第一个参数是模板文件，后续参数是目标文件”的规则执行；否则先向用户确认模板文件。
-
-运行：
-
-```bash
-bash .claude/skills/sub2api-account-json-fix/scripts/run.sh $ARGUMENTS
-```
-
-如果用户没有显式要求写回本地文件，就不要自动加 `--write`；先预览或直接推送内存中的规范化结果即可。

package/enhancements/common/.common/.claude/skills/sub2api-account-json-fix/env/push.env.example

@@ -1,8 +0,0 @@
-# Claude Code 项目技能的本地配置示例。
-# 把本文件复制为同目录下的 push.env 后再填写真实值。
-
-SUB2API_ACCOUNT_JSON_FIX_PUSH_ADMIN_BASE_URL=http://127.0.0.1:8080/api/v1/admin
-SUB2API_ACCOUNT_JSON_FIX_PUSH_TOKEN=admin-xxxx
-SUB2API_ACCOUNT_JSON_FIX_PUSH_GROUP_IDS=3,7
-SUB2API_ACCOUNT_JSON_FIX_PUSH_SCHEDULABLE=false
-SUB2API_ACCOUNT_JSON_FIX_PUSH_REFRESH_AFTER_CREATE=true

package/enhancements/common/.common/.claude/skills/sub2api-account-json-fix/scripts/run.sh

@@ -1,27 +0,0 @@
-#!/usr/bin/env bash
-set -euo pipefail
-
-SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd -P)"
-CLAUDE_SKILL_DIR="$(cd "$SCRIPT_DIR/.." && pwd)"
-SKILL_GARDEN_ROOT="$(cd "$CLAUDE_SKILL_DIR/../../.." && pwd -P)"
-MAIN_SCRIPT="$SKILL_GARDEN_ROOT/.codex/skills/sub2api-account-json-fix/scripts/fix_exported_account_json.py"
-LOCAL_ENV_FILE="$CLAUDE_SKILL_DIR/env/push.env"
-
-export SUB2API_ACCOUNT_JSON_FIX_ENV_FILE="$LOCAL_ENV_FILE"
-
-if [[ -f "$LOCAL_ENV_FILE" ]]; then
-  set -a
-  # shellcheck disable=SC1090
-  source "$LOCAL_ENV_FILE"
-  set +a
-fi
-
-if [[ $# -lt 1 ]]; then
-  echo "用法: run.sh <template-json> [target-json...]" >&2
-  exit 2
-fi
-
-TEMPLATE_FILE="$1"
-shift
-
-python "$MAIN_SCRIPT" --template "$TEMPLATE_FILE" "$@" --push

package/enhancements/common/.common/.codex/skills/sub2api-account-json-fix/SKILL.md

@@ -1,126 +0,0 @@
----
-name: sub2api-account-json-fix
-description: 按模板批量补全 sub2api 账号导出 JSON，修复 `accounts[].name` 与 `credentials.email` 不一致、缺失 `credentials.model_mapping`、缺失 `extra.allow_overages` 等问题，并把这些账号直接推送到 sub2api admin 创建接口。用于处理 `sub2api-account-*.json` 这类导出文件，尤其适合“先规范化 JSON，再批量推送到 sub2api 指定分组”的场景。
----
-
-# Sub2API 账号 JSON 补全
-
-## 概览
-
-先确认模板 JSON，再用脚本批量修复目标文件。默认修复三件事：
-
-- 把每个账号的 `credentials.model_mapping` 同步成模板账号的值
-- 确保每个账号都包含 `extra.allow_overages`
-- 把 `name` 改成该账号 `credentials.email`
-
-脚本只改这些字段，不会删除其他 `credentials`、`extra`、代理、并发、优先级或 token 字段。
-
-## 工作流
-
-1. 读取模板文件，默认使用模板中的第一个账号。
-2. 确认模板账号里已经有正确的 `credentials.model_mapping` 和 `extra.allow_overages`。
-3. 先用预览模式检查哪些文件会被修改。
-4. 确认预览结果后，再用 `--write` 真正写回文件。
-5. 如果要直推到 sub2api，先检查技能目录里的 `env/push.env`；没有再看系统环境变量；还没有才向用户询问直推地址、token 和目标分组 IDs。
-6. 如果 `env/push.env` 里还是示例值
-   `SUB2API_ACCOUNT_JSON_FIX_PUSH_ADMIN_BASE_URL=http://127.0.0.1:8080/api/v1/admin`
-   和 `SUB2API_ACCOUNT_JSON_FIX_PUSH_TOKEN=admin-xxxx`，把它视为“未配置”，不要直接直推，先向用户索要真实值。
-7. 创建账号后，默认立刻关闭调度；如果账号带有 `refresh_token`，默认立刻调用一次 refresh。
-
-## 快速命令
-
-先预览：
-
-```bash
-python sub2api-account-json-fix/scripts/fix_exported_account_json.py \
-  --template sub2api-account-20260316021320.json
-```
-
-真正写回：
-
-```bash
-python sub2api-account-json-fix/scripts/fix_exported_account_json.py \
-  --template sub2api-account-20260316021320.json \
-  --write
-```
-
-只检查是否还有待修复项，并用退出码表示结果：
-
-```bash
-python sub2api-account-json-fix/scripts/fix_exported_account_json.py \
-  --template sub2api-account-20260316021320.json \
-  --check
-```
-
-把规范化后的账号直接推送到 `sub2api`：
-
-```bash
-python sub2api-account-json-fix/scripts/fix_exported_account_json.py \
-  --template sub2api-account-20260316021320.json \
-  --push \
-  --push-admin-base-url http://127.0.0.1:8080/api/v1/admin \
-  --push-token 'admin-xxxx' \
-  --push-group-id 3 \
-  --push-group-id 7
-```
-
-也可以预先设置环境变量，调用时不再重复传参：
-
-```bash
-export SUB2API_ACCOUNT_JSON_FIX_PUSH_ADMIN_BASE_URL='http://127.0.0.1:8080/api/v1/admin'
-export SUB2API_ACCOUNT_JSON_FIX_PUSH_TOKEN='admin-xxxx'
-export SUB2API_ACCOUNT_JSON_FIX_PUSH_SCHEDULABLE='false'
-export SUB2API_ACCOUNT_JSON_FIX_PUSH_REFRESH_AFTER_CREATE='true'
-python sub2api-account-json-fix/scripts/fix_exported_account_json.py \
-  --template sub2api-account-20260316021320.json \
-  --push
-```
-
-更推荐把配置放在技能目录里：
-
-```bash
-cat > sub2api-account-json-fix/env/push.env <<'EOF'
-SUB2API_ACCOUNT_JSON_FIX_PUSH_ADMIN_BASE_URL=http://127.0.0.1:8080/api/v1/admin
-SUB2API_ACCOUNT_JSON_FIX_PUSH_TOKEN=admin-xxxx
-SUB2API_ACCOUNT_JSON_FIX_PUSH_GROUP_IDS=3,7
-SUB2API_ACCOUNT_JSON_FIX_PUSH_SCHEDULABLE=false
-SUB2API_ACCOUNT_JSON_FIX_PUSH_REFRESH_AFTER_CREATE=true
-EOF
-```
-
-指定部分文件：
-
-```bash
-python sub2api-account-json-fix/scripts/fix_exported_account_json.py \
-  --template sub2api-account-20260316021320.json \
-  sub2api-account-20260316015827.json \
-  sub2api-account-20260316020213.json \
-  --write
-```
-
-## 规则
-
-- 把模板账号 `credentials.model_mapping` 原样复制到目标账号。
-- 只补齐 `extra.allow_overages`，不要覆盖目标账号 `extra` 里的其他键。
-- 只有当 `credentials.email` 是非空字符串时，才把 `name` 改成邮箱。
-- 默认处理当前工作目录里匹配 `sub2api-account-*.json` 的文件，并自动跳过模板自身。
-- 脚本支持一个文件里有多个 `accounts`，会逐个账号处理。
-
-## 直推 sub2api
-
-- 直推固定走 `POST /api/v1/admin/proxies` 和 `POST /api/v1/admin/accounts`。
-- 脚本会先确保 JSON 里的代理存在，再按账号逐个创建到 sub2api。
-- 如果配置了 `group_ids`，会在创建账号时直接带上 `group_ids`。
-- 创建账号后默认会再调用一次 `POST /api/v1/admin/accounts/:id/schedulable`，把调度显式设为关闭。
-- 如果账号带有 `refresh_token`，创建账号后默认会再调用一次 `POST /api/v1/admin/accounts/:id/refresh`。
-- 直推参数优先级是：命令行参数 > 技能目录 `env/push.env` > 系统环境变量。
-- 技能目录配置文件路径固定是 `sub2api-account-json-fix/env/push.env`。
-- 支持的键有 `SUB2API_ACCOUNT_JSON_FIX_PUSH_ADMIN_BASE_URL`、`SUB2API_ACCOUNT_JSON_FIX_PUSH_TOKEN`、`SUB2API_ACCOUNT_JSON_FIX_PUSH_GROUP_IDS`、`SUB2API_ACCOUNT_JSON_FIX_PUSH_SCHEDULABLE`、`SUB2API_ACCOUNT_JSON_FIX_PUSH_REFRESH_AFTER_CREATE`。
-- 如果 `push.env` 仍然保留示例值 `admin-xxxx`，脚本会拒绝直推，并要求先替换为真实配置。
-- 如果要直推但命令行、技能目录配置和系统环境变量都没给地址或 token，调用这个技能的代理应先询问用户，再决定是否执行 `--push`。
-- `group_ids` 为空时，是否触发 sub2api 默认分组绑定，取决于 sub2api 当前创建接口的行为。
-
-## 资源
-
-- `scripts/fix_exported_account_json.py`：批量补全 JSON 的主脚本。
-- `env/push.env`：可选的技能目录本地配置文件；不存在时不会报错。

package/enhancements/common/.common/.codex/skills/sub2api-account-json-fix/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Sub2API 账号 JSON 补全"
-  short_description: "按模板批量补全 sub2api 账号导出 JSON 字段"
-  default_prompt: "使用 $sub2api-account-json-fix 按模板批量补全当前目录里的 sub2api 账号导出 JSON。"

package/enhancements/common/.common/.codex/skills/sub2api-account-json-fix/env/push.env.example

@@ -1,8 +0,0 @@
-# 把本文件复制为同目录下的 push.env 后再填写真实值。
-# 如果仍保留 admin-xxxx 这样的示例值，脚本会把它视为未配置并拒绝直推。
-
-SUB2API_ACCOUNT_JSON_FIX_PUSH_ADMIN_BASE_URL=http://127.0.0.1:8080/api/v1/admin
-SUB2API_ACCOUNT_JSON_FIX_PUSH_TOKEN=admin-xxxx
-SUB2API_ACCOUNT_JSON_FIX_PUSH_GROUP_IDS=3,7
-SUB2API_ACCOUNT_JSON_FIX_PUSH_SCHEDULABLE=false
-SUB2API_ACCOUNT_JSON_FIX_PUSH_REFRESH_AFTER_CREATE=true