补回旧工作区中仅存于本地的 Backstage OIDC、DNS 与 agent 说明

清理 chore/recover-old-workspace 时发现以下内容已在线上使用，却只存在于未提交的工作区：

- Authelia `backstage` OIDC client（与 helm 现网 values 逐键比对一致；仅含 pbkdf2 哈希，
  与既有 client 写法相同）。
- `backstage.ad.ddupan.top` A 记录（现网已解析到 192.168.10.127）。
- CLAUDE.md：VyOS `cli-shell-api showConfig` 尾随节点名不会过滤、会输出含密钥的完整配置。
- .agents/skills/homelab-knowledge：让 agent 查询与维护 homelab-wiki 的技能说明。

Co-Authored-By: Claude Opus 5.5 <[email protected]>

.agents/skills/homelab-knowledge/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: homelab-knowledge
+description: Query and maintain the shared homelab-wiki when working on homelab services, infrastructure, architecture, operations, or current service status. Use it to gather existing context before work and to keep durable knowledge synchronized after relevant changes; do not use it for unrelated software work or as a substitute for commit and PR history.
+---
+
+# Homelab Knowledge
+
+Use `homelab-wiki` as the shared long-lived knowledge base for people and agents. Search it directly with `rg`; do not introduce a search index, vector database, or generated copy of the wiki.
+
+## Locate the wiki
+
+Resolve the checkout in this order:
+
+1. `$HOMELAB_WIKI_PATH`, when set.
+2. A sibling directory named `homelab-wiki` next to the current repository.
+3. `/home/panxiao81/homelab-wiki` when it exists.
+
+If no checkout is available, report that constraint. Do not silently skip the knowledge step, clone a repository, or create a replacement wiki without the user's authorization.
+
+Before using the wiki, read its `AGENTS.md` completely. For edits, also read `README.md` and `CONTRIBUTING.md` completely and follow any more specific instructions associated with the target page.
+
+## Gather context
+
+At the beginning of a homelab task:
+
+1. Derive search terms from the component name, service aliases, hostnames, Kubernetes resources, configuration keys, error text, and task intent.
+2. Use `rg -n -i` in the wiki to find candidate pages. Prefer several precise searches over reading the whole repository.
+3. Follow the wiki's task index, service index, architecture constraints, source records, and verification conflicts when they are relevant.
+4. Read the closest authoritative pages and their material links before making decisions. Also read the corresponding source repository README or runbook when changing an implementation.
+5. Distinguish documented design, declared configuration, deployment history, live verification, and work currently in progress. Do not present one as another.
+
+For questions about current project or service status, first obtain the maintainer's current-work and ticket context as required by the wiki, unless the conversation already provides that authorization and scope. Reading documentation does not authorize live-system inspection.
+
+Answer read-only questions from the evidence found. Include paths or links that let the user verify important claims, and state when evidence may be stale or conflicting.
+
+## Maintain knowledge after changes
+
+For any code, configuration, infrastructure, or operational change, perform a documentation-impact check before declaring the task complete.
+
+Update the wiki in the same task when the change affects durable knowledge such as:
+
+- service purpose, lifecycle, entry point, authentication, permissions, dependencies, or first-use path;
+- architecture boundaries or accepted constraints;
+- deployment ownership or persistent operating behavior;
+- troubleshooting, recovery, verification, or maintenance procedures;
+- the addition, replacement, or retirement of a service.
+
+Keep one-time progress, implementation narration, and release-by-release history in commits, PRs, or tickets. Do not copy them into the wiki unless they change a durable stage summary. Implementation-specific parameters may remain in the source repository README or runbook when the wiki convention says to link rather than duplicate them.
+
+When editing:
+
+1. Inspect both the source-repository diff and the wiki working tree before writing. Preserve unrelated user changes in both repositories.
+2. Update the page closest to the fact first, then only the navigation, indexes, constraints, or verification records that the wiki rules require.
+3. Preserve evidence metadata. Never advance `last_verified` without performing the stated live verification; ordinary review may update only fields permitted by the wiki.
+4. Link related source commits, PRs, or paths when available. Clearly mark uncommitted sources and unfinished cross-repository synchronization.
+5. Record conflicts rather than resolving them by assumption. Ask before live inspection or before choosing among materially conflicting current-state claims.
+6. Keep credentials, tokens, private keys, Terraform state, secret values, and sensitive command output out of documentation. Never read or copy known sensitive files merely to improve the wiki.
+
+Wiki edits are a separate repository change. Do not commit, push, open a PR, or modify a live system unless the user has authorized that action.
+
+## Verify and report
+
+After editing the wiki, run from its root:
+
+```bash
+python3 scripts/check_docs.py
+git diff --check
+```
+
+If the checker itself changed, also run:
+
+```bash
+python3 -m unittest discover -s tests -v
+```
+
+In the final response, report source-repository changes and wiki changes separately, including validation performed and anything still awaiting verification or cross-repository linkage. If no wiki update was needed, state the concrete reason; do not merely say that documentation was unaffected.

CLAUDE.md

@@ -50,6 +50,9 @@ netboot.xyz appliance — i.e. the single point of failure for most of the lab.
 - Network devices (VyOS) use `ansible.netcommon.network_cli`, not ssh/python — they have no
   Python interpreter. Prefer `vyos_config` with explicit `set` lines over the collection's
   resource modules, which lag upstream syntax.
+  ⚠ `cli-shell-api showConfig --show-active-only --show-cfg1 load-balancing` 在现场并未
+  限定为 LB 子树，而是输出完整配置（含密钥）。不要把尾随节点名当作过滤条件；
+  先在路由器端严格提取所需配置段，再返回输出，不将完整配置送入工具日志。
   ⚠ A set-lines-only role **cannot change a multi-value node** — `set` appends. Changing
   e.g. `option wins-server` or `name-server` leaves the old value live *and* saved to
   `config.boot`; the diff only shows the addition, so it reads as a clean replace. Grep the

apps/authelia/values.yaml

@@ -201,6 +201,22 @@ configMap:
             # additionalSecrets entry lands at /secrets/<its own name>.
             path: '/secrets/authelia-oidc-jwks/main.pem'
       clients:
+        - client_id: 'backstage'
+          client_name: 'Backstage'
+          client_secret: '$pbkdf2-sha512$310000$gddaWiXG/xDzda/oRqCibw$MVYwCrDBKi1S4K0/l/O1lNPcH14WmQEb1dIJ48Rs2lrfk9m9dp22s9dFjBelVTzKEyzMwBA2t3eAUmMiu.TiFg'
+          public: false
+          authorization_policy: 'two_factor'
+          claims_policy: 'gitea'
+          require_pkce: false
+          token_endpoint_auth_method: 'client_secret_basic'
+          redirect_uris:
+            - 'https://backstage.ad.ddupan.top/api/auth/oidc/handler/frame'
+          scopes:
+            - 'openid'
+            - 'profile'
+            - 'email'
+            - 'groups'
+          userinfo_signed_response_alg: 'none'
         - client_id: 'gitea'
           client_name: 'Gitea'
           # pbkdf2-sha512 hash of the plaintext secret Gitea holds (gitea-keycloak-secret).

apps/backstage/deployment.yaml

@@ -27,7 +27,7 @@ spec:
           type: RuntimeDefault
       containers:
         - name: backstage
-          image: zot.ad.ddupan.top/panxiao81/backstage:latest@sha256:476b40ea5cdf7301edb4f5dab5a012686a0009d1b0f1fce21fab34b969543ebb # {"$imagepolicy": "flux-system:backstage"}
+          image: zot.ad.ddupan.top/panxiao81/backstage:latest@sha256:da55be5c2f5c8b33de2d87ee0ef02edeacf52a349c8b19a5fac9be4152b2723d # {"$imagepolicy": "flux-system:backstage"}
           imagePullPolicy: IfNotPresent
           env:
             - name: BACKSTAGE_BASE_URL

apps/hydra/README.md

@@ -27,10 +27,9 @@ Hydra 回调为 `/oauth2/start`、`/oauth2/consent`、`/oauth2/logout`；默认
 
 ### 客户端管理 `/console`
 
-iam-login 的客户端管理 API 是普通 resource server：只接受 Hydra 签发、`aud` 含 `iam-login`
-且 `groups` 含管理组的 access token。`/console` 是调用该 API 的前端，在 Hydra 中登记为普通
-**public** 客户端 `iam-admin-ui`；只有它被允许申请 audience `iam-login`（Hydra 按客户端登记的
-audience 白名单执行），所以其他应用拿到的管理员 token 不能调用该 API。
+iam-login 的客户端管理 API 只接受 Hydra 签发、带 `iam.clients.manage` scope 的 access token；
+`/console` 是调用该 API 的前端，在 Hydra 中登记为普通 **public** 客户端 `iam-admin-ui`。
+该 scope 只在 consent 时发给 `iam-admin-ui` 且直接属于管理组的用户，规则在 iam-login。
 
 浏览器直接向 Hydra 换取 token，因此 `hydra.yaml` 为 public 端口开启 CORS，只允许开发实例
 origin；不放行 cookie 凭据。Gitea 等服务端客户端不受影响。
@@ -43,11 +42,11 @@ curl -fsS -X POST http://127.0.0.1:18445/admin/clients -H 'Content-Type: applica
   "client_id": "iam-admin-ui", "client_name": "IAM 管理",
   "redirect_uris": ["https://laptop.tail7e769.ts.net:18082/console/callback"],
   "grant_types": ["authorization_code"], "response_types": ["code"],
-  "scope": "openid groups", "audience": ["iam-login"], "token_endpoint_auth_method": "none",
+  "scope": "openid iam.clients.manage", "token_endpoint_auth_method": "none",
   "subject_type": "public", "metadata": {"iam_login_enabled": true}}'
 ```
 
-开发实例另需 `iam.clients.admin-ui-client-id=iam-admin-ui` 与 `iam.clients.admin-groups`（组名）；未配置时 `/console` 不提供，API
+开发实例另需 `iam.clients.admin-ui-client-id=iam-admin-ui`；未配置时 `/console` 不提供，API
 无法获得可用 token（fail closed）。
 
 从 Gitea `/user/oauth2/hydra` 发起，应进入新密码/Passkey 页，确认授权后返回原账号，核对

infrastructure/dns/records.yml

@@ -27,6 +27,7 @@ homelab_dns:
       - { zone: ad.ddupan.top, name: zot, type: A, values: [192.168.10.127] }
       - { zone: ad.ddupan.top, name: zot-push, type: A, values: [192.168.10.127] }
 
+      - { zone: ad.ddupan.top, name: backstage, type: A, values: [192.168.10.127] }
       - { zone: ad.ddupan.top, name: pg-prod, type: A, values: [192.168.10.2] }
       - { zone: ad.ddupan.top, name: pg-dev, type: A, values: [192.168.10.127] }