Load Profile

Load Profile Skill

职责

在 IntentSeedV1 形成后，独立确定目标项目 <project>，再按 ContextReadPlanV2（兼容读取 ContextReadPlanV1）加载最小充分的项目配置（profile）。计划确定后的只读 Profile 与记忆查询可按并发策略执行。

必要来源形成 ContextReadReceiptV2（V1 兼容）后，必须把 Profile 结果交给“项目现实扩展”步骤，作为最终意图路由、产物落点和验证方式的输入。

如何确定 <project>

🔴 多项目工作区扫描禁令（v1.9.8+）：当 cwd 是 monorepo 根目录且未明确 <project> 时，AI 侧与 Hook 侧同步阐断扫描。豁免词：workspace / monorepo / 全工作区 / all projects / 所有项目。详见 lifecycle.cjs isMultiProjectWorkspace。

工作区目录映射

Profile 路径约定

默认兼容路径：

<项目根>/.devcodex/profile/

当 <工作区根>/.devcodex/layout.json 启用 workspace-namespace 时：

• config.json：<工作区根>/.devcodex/workspace/profile/config.json 作为 base，<工作区根>/.devcodex/<project>/profile/config.json 作为 overlay；Auto 精确别名全局默认 @rocky，可用 extensions.devcodex.autoAliases 替换全局默认别名（省略表示沿用默认，空数组表示关闭默认别名），也可在 extensions.devcodex.concurrency 配置 ConcurrencyPolicy
• extensions.devcodex.concurrency 缺省为 mode=auto：只读准备与隔离验证可按通道上限并行；mode=serial 表示全串行；项目只能追加 locks.additionalSingleWriterScopes，不得删除核心单写者域或开启并行 mutation
• extensions.devcodex.git 缺省投影为 collaborationMode=unverified / branchPolicy=no-auto-branch / worktreePolicy=explicit-only / crossBranchIntegration=unverified / sharedActionsRequireExplicitAuthorization=true；项目 overlay 可用证据收窄为 solo/team，但不得把共享动作显式授权降为 false
• Profile config 的对象层必须递归合并；project extensions.devcodex.git 只覆盖声明字段，不能因浅合并丢失 workspace 的授权边界、worktree policy 或其他 sibling 配置
• config.local.json：与 config.json 使用相同的 workspace base + project overlay 路径模型，可作为用户 / 项目指定的本地 overlay（长期连接、本地明文连接信息、env / secretRef 引用、extensions.<namespace>）；脚本、测试、数据库 / SSH / MongoDB / 数据操作只有在用户或项目明确指定时才以它作为连接配置入口
• README.md、01-项目信息.md、02-架构约束.md、03-代码风格.md：项目命名空间文件优先，缺失回退到 workspace/profile/
• <project> 未确定时，禁止猜测项目命名空间

ProfileReadChainGate / ServiceNormCoverageGate

<!-- devcodex:include shared/profile/profile-read-chain.md -->

• 调用 profile_context_plan，以 canonical intent、changeTypes、risk、confidence 和明确 selector 生成 ContextReadPlanV2（V1 reader 保留）；计划必须列出 baseline / selected / excluded / unclassified、base/project fallback 和实际 active-root。
• ProfilePlanNoHiddenFullReadProbe 必须证明计划阶段只返回 README/index、effective non-local config 与顶层 metadata inventory，没有预读 01~09-*、config.local.json 或其他 selected 正文。
• selected 正文通过 profile_load({ project, files }) 定向读取；只有 contextEpoch / invocation planId / planContentId / activeRoot / source 精确关联且 PostToolUse 观察成功的 ContextReadReceiptV2（V1 兼容）才能证明加载完成。
• ContextReadBindingGate（PF-149）：profile_load / profile_skill_plan 与 memory query 应携带与当前 ContextReadPlanV2 一致的 ContextReadBindingV1（contextEpoch / planId / planContentId / activeRoot / project）。bindingStatus=request-bound 才可把相关源推进 relevant-complete；legacy-unbound 只能降级为 partial/unverified，不得宣称 Context Acquisition 已完整完成；CONTEXT_BINDING_INVALID / CONTEXT_BINDING_MISMATCH fail-closed。机器分类见 scripts/lib/validate-context-read-controls.js（classifyContextReadBindingSample）。
• ContentIdentityReuseGate：computation reuse 可跨进程复用有界解析/索引元数据，但仍须读取并返回当前任务需要的正文；delivery reuse 仅在同 host session、同 contextEpoch、同 planContentId、同 source identity 且当前模型的成功 body observation 可证时成立。cache hit 不能单独满足 receipt，旧 epoch receipt 只能作为 reuseFrom，不得改写成当前完成态。
• 硬预算（ABS-06 / PF-133）：profile_load 禁止无参默认真全量。省略 files 时必须 explicitFull=true + 非空 fullReadReason；否则返回 PROFILE_LOAD_BUDGET 错误与 inventory。定向 load 默认 maxBytes=32768（可调）；explicitFull 默认更高字节上限仍可能 truncated。不得把无参全量成功当作 Context Acquisition 完成证据。
• ProfileSectionSelectionGate：文件已进入 plan.selected 后，可调用 profile_load({ files, sectionSelectors }) 按完整 Markdown section 读取。selector 必须给出 file / headingQueries / requiredQueries，并显式选择 includePreamble / includeDescendants / maxBytes；多个标题必须分别定位、按源文件顺序拼接并对父子或重复范围去重，禁止按字符中途截断。
• ProfileSectionLoadReceiptV1 必须记录 full/selected bytes、source digest、matched/missing/ambiguous/deferred、completion 与 fallbackReason。普通显式 selector 在 required query 缺失或歧义、低置信、parser 不支持、required section 超预算时可兼容 fallback-full；ProfileRouteLoadRecipeV2 必须携带 boundedOnly=true，任何缺标题、歧义或预算不足都只能 fail closed 为 partial 并返回 ProfileSectionRecoveryRecipeV1 / ProfileRouteRecoveryRecipeV1，不得退化为整文件。调用方补读 deferred 或完成分段恢复前，不得把 Context receipt 推进到 relevant-complete。
• ContextReadPlanV2 必须把 effective config 的优化模式封装为身份绑定的 ExecutionOptimizationPlanBindingV1，profile_load / profile_skill_plan 直接消费该绑定，禁止另读 config.json。绑定缺失、损坏或未知时 fail-closed 到 full-only，分别走完整 Profile 文件与 full-skill-read；这类 fallback 不能标记为渐进加载命中。
• 绑定只证明 config mode，不替代 feature lifecycle。Context computation、Profile section 与 Skill bundle 在消费绑定后还必须读取同一 active-root 的 ExecutionOptimizationStateV2 并形成 ExecutionOptimizationFeatureDecisionV1；对应 feature 为 off / shadow / rolled-back / sunset 或状态无效时，分别 bypass computation cache、清空 section selector、返回 fallback-full / full-skill-read，不得只在诊断输出里显示回滚。
• 全量升级必须记录 fullReadReason，仅限用户/项目明确要求、audit/migration、低置信或必要来源缺失；config.local.json 还须用户/项目明确指定，不能因文件存在自动读取。
• 覆盖 .devcodex/<project>/profile 读取链、.devcodex/workspace/profile 回退链和 sticky activeProject 生效边界；实质 identity / scope / action / risk / digest 漂移或 compact/resume 时重新规划。
• 复审服务 / 框架规范时列出全部服务集合、docs 自维护链、导航、版本、构建、报告和记忆消费者。
• 从单服务抽公共规范时同步执行 StrongestProfileSourceGate / ServiceSpecificResidueSweep，以最强 Profile 为基线并清扫服务化残留。

ProfileTruthReconciliationGate

Profile 加载只证明“声明已读取”，不能证明声明仍为当前真相。项目级 analyze / audit 在形成结论前必须执行分级真相对账：

加载后先把 profileTrustState 标为 unreconciled；对账完成后只能进入 aligned、drift-detected 或 partially-unverifiable。每条相关声明写入 ProfileTruthMatrix：

Profile 可以约束目标态和项目政策，但不得覆盖已验证的当前实现事实。analyze/audit 保持只读：发现漂移时立即矫正本轮结论并记录交接，不得直接修改 Profile 源文件；后续源文件修订必须进入独立 dev/fix/self-fix 与 ProfileImpactCheck。

ProfileReleaseTruthAuthorityMatrixGate

DevCodex 自维护、Profile 生成/复审、workspace base 同步和发布事实变更必须区分发布权威、当前消费者与历史证据：

加载时把每条明确 current claim 写入 authority matrix；版本不一致时 profileTrustState=drift-detected，validator 至少返回 warning/non-zero，不得把“文件存在”视为通过。只读工作流报告漂移并采用 release authority 修正结论；获授权的 dev/fix/self-fix 才同步 Profile。普通项目的自身版本不得错误对比 DevCodex package 版本。

MemoryCannotSatisfyBootstrapGate

Codex / 宿主内置 Memories、模型长期偏好、上一轮摘要或用户口头记忆只能作为导航提示，不能满足 DevCodex bootstrap、Profile 加载、Context Rehydration、CP 确认、报告结论或验证证据。

• 新线程、resume、summary 恢复、compact 后继续、跨项目切换或用户提到“你应该记得”时，仍必须重新建立当前 active namespace 的计划并取得必要文件真相源回执；使用 bounded Profile plan、memory status/query（有限投影覆盖 Agent SUMMARY / daily tasks）与 handoff 指向的精确 report / review checklist / source，禁止固定全读 Profile、SUMMARY、今日/昨日 tasks。
• 完整 继续<任务名>任务 / 继续 <任务名> 先通过 TaskResolutionV1 exact 定位 active project，再为该项目形成 ContextReadPlan；resolver 只可读取有界 task metadata，不得为了识别项目预读 Profile 正文。定位失败、歧义、完成、stale CP 或 scale-blocked 时不得创建错误项目计划。
• 若内置 Memories 与文件真相源冲突，以文件真相源为准；报告或 PC 块说明冲突和采用依据。
• 若无法完成文件真相源读取，只能标记阻塞或降级，不能把 Memories / 模型回忆写成 verified、loaded、passed 或 CP / release 证据。
• 当用户询问是否启用宿主 Memories 时，结论必须同时说明本门禁：开启也不降低文件读取门槛；无法保证该门禁时默认不建议作为正式 DevCodex 运行模式。

FeatureInventoryProfileGate

公开包、SDK、CLI、多模块仓库、文档站、public API、可配置 runtime 或跨项目规范维护任务需要稳定功能清单时，必须执行 FeatureInventoryProfileGate：

• Profile 中应有可追踪 feature inventory 或精确说明其当前 Markdown 来源；关键词命中、临时清单或不存在的路径不能证明来源有效。
• profile-closed-loop 使用 06-功能清单.md 作为规范真相源；新生成/当前维护内容符合 FeatureInventorySchemaV2：V1 十字段基础上增加生命周期状态、证据状态、证据日期和证据引用。validator 兼容读取 V1，但 V1 投影不得宣称已验证或已发布。01-项目信息.md 只能保留摘要和链接，不得复制完整规范表。
• feature inventory 不能由复审清单临时拼接；复审清单只记录本轮验证状态，Profile 或正式文档记录稳定能力面。
• 功能增删、默认行为变化、公开 API 或文档站能力变化时，报告需写 ProfileRuntimeContractSyncGate 与 ProfileImpactCheck 是否同步。