Fulling
AI 全栈工程师代理，为每个用户提供 Kubernetes 凭据隔离的持久化工作空间。
证据显示：README 明确说明 kubeconfig 以明文存储于 PostgreSQL，并列出验证拒绝的插件、代理等，表明对敏感数据有基本处理。但缺少用户确认机制（如执行敏感操作前的确认），外部影响（如 SSRF 边界）虽有说明但未提供实现细节。依赖安全有 npm audit 脚本，但未提供审计结果。回滚仅提及部署重置文档，未提供具体回滚机制。来源归属仅依赖 README 和 package.json 的作者字段，未验证。因此扣分：用户确认、外部影响、回滚、来源归属证据不足。
证据显示：README 与 package.json 的脚本和依赖一致，CI 配置包含 lint、test、build，表明一定自洽性。依赖版本固定或使用 ^，但未提供锁文件或完整性校验。失败消息方面，README 未提供常见错误处理指南。因此扣分：失败消息证据不足。
证据显示：README 明确目标用户为 AI 全栈工程师，并说明使用场景（开发、部署）。能力边界通过 Credential Boundary 部分说明，但触发精度（如命令触发条件）未详细说明。环境适配方面，支持 Node.js 24 和 Vercel 部署，但未说明其他环境。因此扣分：触发精度证据不足。
证据显示：README 提供架构文档链接、安装步骤、命令列表，信息架构清晰。安装说明包含本地开发和 Vercel 部署。命名稳定性方面，版本为 3.0.0，但未提供变更日志。示例和 FAQ 缺失。已知限制在 README 中提及（如 SSRF 边界）。许可证为 MIT。维护责任未明确。因此扣分：命名稳定性、示例和 FAQ、维护责任证据不足。
证据显示：README 描述产品价值，但未提供实际输出示例或用户反馈。边际价值未量化。成本效益未讨论。因此扣分：输出可用性、边际价值、成本效益证据不足。
证据显示：README 中的声明（如安全边界）未提供测试或验证结果。跨来源佐证不足，仅依赖单一仓库。事实与推断未明确区分。因此扣分：声明可追溯性、跨来源佐证、事实推断分离证据不足。
- kubeconfig 以明文存储，数据库泄露将导致 Kubernetes 凭据泄露。
- README 明确允许用户配置任意 HTTPS API 服务器，存在 SSRF 风险。
- 未提供用户确认机制，敏感操作可能自动执行。
- 依赖安全审计脚本存在，但未提供审计结果，无法确认无已知漏洞。
这个 Agent 能做什么，适合哪些场景？
Fulling 是一个 AI 驱动的全栈工程师代理，其 v3 架构提供基于身份的 Kubernetes 凭据边界。当前基础包括仅 GitHub 登录（通过 Better Auth）、PostgreSQL 存储的用户与会话，以及一个受保护的应用工作空间入口。每个用户存储一个明文 kubeconfig，并通过 Kubernetes SelfSubjectReview 验证，从而建立用户范围的 Kubernetes 客户端边界。项目使用 Next.js、Claude、shadcn/ui 和 PostgreSQL 构建，并以 Kubernetes 作为基础设施。该版本不兼容此前 v2 数据模型，需全新数据库部署。
Fulling 提供以下核心操作：通过 GitHub OAuth（Better Auth）实现用户认证；使用 Prisma 在 PostgreSQL 中管理用户、provider 账户和会话；为每个用户存储并验证 kubeconfig（通过 Kubernetes SelfSubjectReview）；提供用户范围的 Kubernetes 客户端边界；公开应用无需数据库或 OAuth 即可运行，而遗留认证工作空间需要 PostgreSQL 和 GitHub OAuth。验证过程中会拒绝不安全配置，如可执行插件、代理、本地文件凭据等。
- 希望在隔离 Kubernetes 凭据下运行 AI 编码代理的开发者。
- 需要为多个用户管理独立 K8s 访问权限的团队。
- 希望快速搭建基于 Next.js 和 PostgreSQL 的认证工作空间的开发者。
- 需要验证 kubeconfig 安全配置的 DevOps 工程师。
- 对 AI 代理工作空间资源清理（如 v2 遗留）有需求的运维人员。
这个 Agent 有哪些优点和局限？
- 独立的 Kubernetes 凭据边界，每个用户有单独的 kubeconfig。
- 通过 Kubernetes SelfSubjectReview 进行强化的 kubeconfig 验证，拒绝不安全配置。
- 使用现代技术栈（Next.js、Prisma、shadcn/ui）易于扩展。
- 提供清晰的架构文档和部署说明。
- 仅支持 GitHub 登录，无法使用其他身份提供商。
- kubeconfig 以明文存储，数据库泄露风险高。
- 不支持 v2 数据迁移，需要全新部署。
- 需要 Kubernetes 和 PostgreSQL 才能使用完整工作空间功能。
如何安装或部署这个 Agent？
克隆仓库，安装 Node.js 24，运行 npm ci。公开应用无需 PostgreSQL 或 OAuth，可直接运行 npm run dev。若需使用认证工作空间，复制 .env.template 为 .env.local，填写数据库、Better Auth 和 GitHub OAuth 配置，然后运行 npm run prisma:migrate 和 npm run dev。
如何使用这个 Agent？
启动开发服务器后，公开应用立即可用。若要登录，需配置 GitHub OAuth 回调为 ${BETTER_AUTH_URL}/api/auth/callback/github，并设置环境变量。对于部署，可遵循 Vercel 部署指南，零配置即可构建和启动。