# R2.7.6 任务报告

## 结果

已在 `/root/superapi` 实现并启动独立的 description-only 企业虚拟 skill 上游加载器。当前链路为：

```text
Codex -> https://superapi.hwpod.com/v1/responses
      -> SuperAPI 按 Bearer API Key 匹配 profile
      -> 追加 Company Skills name + description
      -> https://api.pikapython.com/v1/responses
```

Sub2API 源码、版本、账号池和 runtime 配置均未修改。

## 规格与归属

- 按 Key catalog 主责归入 `PJ2026-010502 APIKey`。
- Codex-compatible 透传关联 `PJ2026-010204 后端Profile`。
- 域名、TLS 和 Caddy 关联 `PJ2026-010604 公开入口`。
- 新增 `PJ2026-01050205 APIKey Skill Catalog` 规格。
- UniDesk PR：<https://github.com/pikasTech/unidesk/pull/2522>。
- merge commit：`8eb62cfbd4ec24f7d42423d6a53646bc3dcfbd46`。

## 实现

本地仓库：`/root/superapi`。

本地 commit：`29db775 feat: add per-key skill upstream loader`。

主要能力：

- `config/superapi.yaml` 是唯一配置真相：
  - native bind、port 和 probe；
  - 上游 base URL 与允许路径；
  - public URL、DNS、Caddy config 与 upstream；
  - API Key `sourceRef/sourceKey`；
  - 每个 Key profile 的 skill `name + description`。
- API Key 从 `/root/.codex/auth.json.pika#OPENAI_API_KEY` 读取：
  - 仓库、CLI、状态和日志均不保存或输出完整 Key；
  - 正确 Key 使用恒定时间比较命中 profile；
  - 未配置 Key 在进入上游前返回 401。
- `/v1/responses` 和 `/v1/responses/compact`：
  - 保留原字符串 instructions；
  - 追加稳定的 `Company Skills` catalog；
  - 请求与上游流式响应透明透传。
- health 和日志只披露 profile、skill 数量、request id、状态和脱敏指标。
- 项目 CLI 提供：
  - `config validate`；
  - `l0 probe`；
  - `native start|status|logs|stop`；
  - `public plan|apply|status`。

## L0 验证

执行：

```bash
bun scripts/superapi-cli.ts l0 probe
```

结果：

- `RESULT=PASS`；
- `KEY_MATCH=true`；
- `INVALID_REJECT=true`；
- `PRESERVED_EXISTING=true`；
- profile 为 `pika`；
- skill 数量为 1；
- `VALUES_PRINTED=false`。

`bun run check` 使用只编译不执行的 Bun build 入口并通过。首次使用 `bun --check` 时发现该版本会实际执行入口，已改为构建到被忽略的 `.state/check`，没有保留误启动进程。

## L1 与公网验证

native 服务由项目 CLI 启动：

- 状态：`ready`；
- bind：`127.0.0.1:18159`；
- health：HTTP 200。

公网入口由 owning YAML 渲染的独占 Caddy managed block提供：

- URL：<https://superapi.hwpod.com>；
- DNS：`152.53.229.148`，与 YAML `expectedA` 一致；
- Caddy 完整配置 validate 通过；
- public health：HTTP 200；
- public status：`ready`。

错误 Key 的公网 `/v1/responses` 请求返回 401，没有进入上游。

## 真实 Codex 验证

Codex 使用隔离的 `CODEX_HOME`：

- `auth.json` 软链接到现有 `/root/.codex/auth.json.pika`；
- 不含密钥的 smoke config 指向 `https://superapi.hwpod.com/v1`；
- model 为 `gpt-5.5`，wire API 为 Responses。

首次请求使用域名根作为 base URL，Codex 实际请求 `/responses`，被 allowlist 正确拒绝为 404。将 smoke base URL 修正为 `https://superapi.hwpod.com/v1` 后成功。

最终真实流式请求证据：

- path：`/v1/responses`；
- status：200；
- profile：`pika`；
- skillCount：1；
- upstreamErrors：0；
- 模型最终只返回 `SUPERAPI_SKILL_LOADED`。

这证明 Codex 实际收到注入的 `pika-company-dev` catalog，而不只是代理本地函数返回成功。

## 边界

- 这是虚拟 skill catalog，不会注册到 Codex 客户端 `/skills`。
- 当前只保存并注入 `name + description`，不保存完整 skill 文件或脚本。
- description 引导 Agent 从公司内网 skill registry 获取后续资料，但网络权限、内网认证和资源版本仍由公司内网负责。
- 当前是用户要求的 L1 native 服务：
  - 进程由项目 CLI 管理；
  - 未配置 systemd 或容器级重启自恢复；
  - host 重启后需执行 `native start` 和 `public status`。
- `/root/superapi` 当前是本地 Git 仓库，没有远端，因此只有本地 commit，没有 push 或 PR。
- 公网开放后观察到常规扫描请求，全部被 allowedPaths 拒绝；业务 Key、description 和上游响应内容未进入日志。
