用途：帮助运维人员追踪 API 未触达目标开发者受众的原因，覆盖从托管 API 存在、Catalog 就绪到门户发布的完整链路。使用 inspect、trace、publish、validate、approve 等工作流语言，专注发布链诊断，而非通用 Portal 文档、Catalog 编写或开发者应用认证设计。
主要能力：先做只读检查，再在明确缺失环节后变更。优先使用共享的 kong-konnect MCP 服务器实时检查托管 API、Catalog 和门户状态；用 kongctl-query 做只读检查。需要变更发布资源时，保留仓库既定的声明式工具链：kongctl YAML 用 kongctl-declarative，HCL 管理的 Konnect 资源用 terraform-konnect，仅当缺失环节位于目标控制平面内的 Gateway 实体配置时才用 deck-gateway。
使用方式：按检查顺序推进。先明确“未发布”的具体含义与预期查看者，区分托管清单缺失、规格或版本缺失、Catalog 条目缺失或过期、门户发布缺失、页面可见但注册或访问失败、内部存在但未就绪等情形。再证明托管 API 与版本已具备发布条件，追踪门户发布目标，区分可见性与消费者访问，最后返回链中第一个断点。按分支加载 references/publication-chain.md、references/portal-visibility-vs-access.md、references/downstream-auth-handoffs.md。
适用场景：API 应可见但缺失环节在 Catalog 就绪、门户发布或受众可见性时。若真正问题是 API 对象建模、版本、规格质量或包就绪，转交 konnect-api-catalog；若发布已确认而问题在开发者注册、审批、凭证或认证策略，转交 konnect-app-auth；需要以代码创建或更新资源时用 kongctl-declarative 或 terraform-konnect；调用方看不到或无法管理 API 时用 konnect-access-scope。
限制：若实时 Konnect 状态重要但 kong-konnect MCP 未连接，应尽早说明并改用 CLI 或用户提供的工件。运行时存在不自动等于 Catalog 或门户发布；发布与访问相互独立。具体命令语法、配置细节与完整示例暂未提供。