Potpie Resource Manager 契约深度解析授权上下文租约Authorized Context Lease的边界、流程与实现【免费下载链接】potpieContext Graph for AI Native SDLC项目地址: https://gitcode.com/GitHub_Trending/po/potpie本文基于 potpie 仓库中的模块规格 spec/modules/potpie-resource-manager.mdrevision 2maturity: accepted展开结合 potpie/runtime/resource_manager.py、potpie/runtime/composition.py、potpie/runtime/coordinator.py 等源码与一致性记录 spec/conformance/potpie-resource-manager.md系统讲解 Potpie Resource Manager 的职责边界、39 条规范需求、获取/释放流程、类型化失败模型与源码实现细节。读完你将掌握Resource Manager 为什么被定义为逻辑子系统而非某个类、授权上下文租约Authorized Context Lease的构成与语义、一次操作从选择到租约释放的完整调用链以及它如何在不侵犯 Context Engine 领域语义的前提下保证认证、授权与资源生命周期安全。一、背景为什么需要独立的 Resource Manager在 ADR-0004spec/decisions/ADR-0004-potpie-resource-management-ownership.md记录的决策语境中Potpie 早期的引擎侧 host wiring 与 setup 编排把 pot 选择、凭据、资源供给、安装、守护进程生命周期和领域服务全部耦合在一起。如果再用一个万能门面把这些逻辑全部包起来只是换了个名字继续保留所有权问题。因此ADR-0004 的决策是Potpie 拥有一个聚焦的逻辑 Resource Manager它负责解析选择selection、应用授权authorization、获取宿主机管理的资源host-managed resources、构造或复用上下文绑定的引擎context-bound engine最终返回一个带有显式所有权与释放语义的授权上下文租约Authorized Context Lease。该决策同时明确了边界Resource Manager 不派发 Context Engine 操作、不返回领域或通用产品操作结果、不暴露服务图、不拥有上下文领域语义、不实现守护进程传输、不渲染展示层。类型化操作处理器typed operation handler通过租约直接调用显式的 Context Engine 操作。配套决策链还包括ADR-0003宿主必须显式供给 Context Engine 的上下文身份、依赖与资源所有权模式一个引擎实例在其整个生命周期内绑定且只绑定一个逻辑上下文身份。ADR-0005守护进程收敛为单一类型化边界CLI 独占展示层破坏性确认变成不可信的带类型断言由 Resource Manager 在认证与上下文解析之后校验。ADR-0010修正认证结果枚举将AuthenticationError显式纳入获取acquisition的结果联合并规定认证失败必须在授权/组合/引擎构造之前短路。二、定位与职责边界一个逻辑子系统规格开篇即强调Resource Manager 是逻辑子系统不强制要求存在同名的一个类、一个进程或一个包。它由职责而非代码形态定义。其拥有将产品选择product selection解析到唯一一个上下文身份在 Potpie 操作边界上认证调用方提供的材料对 actor、操作与已解析上下文执行授权策略供给、打开、校验与释放 Potpie 管理的资源构造带所有权模式的显式 Context Engine 依赖构造或兼容地复用一个上下文绑定的引擎签发与释放授权上下文租约从失败的租约获取与资源故障中恢复。同时它明确排除以下内容产品操作派发、Context Engine 方法镜像、上下文领域语义、任意服务查找、守护进程传输、终端展示。这一边界在源码层面有直接印证。potpie/runtime/resource_manager.py中的ContextResourceManager只做resolve → authenticate → authorize → compose → cache → lease而真正执行领域操作的是 potpie/runtime/local_engine.py 中持有引擎服务句柄的类型化处理器potpie/runtime/composition.py的LocalRuntimeComposition将产品服务组root与引擎服务组engine显式分离二者通过coordinator协调graph_metadata单独提供图元数据操作。范围与非目标当前 revision 定义的是逻辑责任与租约边界不冻结实现分解方式、缓存形态、驱逐策略、空闲超时、某个公开 Python 符号也不定义守护进程传输、CLI 提示方式或租约的精确表示。这意味着缓存如何做、租约长什么样属于实现选择由一致性记录与源码演进跟踪。三、角色与权限模型Actor交互Potpie 操作处理器operation handler提供调用方认证材料、类型化操作、选择请求以及需要时的意图intentResource Manager解析resolve、认证authenticate、授权authorize、获取acquire、租约lease、释放releaseContext Engine被租约持有由操作处理器直接调用资源适配器resource adapter打开或供给一个被显式选中的依赖注意第三个角色的设计意图操作处理器拿到租约后直接调用引擎而不是把操作请求转交给 Resource Manager 再转达。这正是 RM-022/RM-023 的落点——Resource Manager 与租约都不得调用/派发 Context Engine 操作也不得暴露通用操作派发、任意服务查找或镜像的引擎服务面。四、规范需求全景RM-001 至 RM-039当前 revision 共有 39 条行为编号其中RM-001 ~ RM-014、RM-017 ~ RM-039 处于 active 状态共 37 条RM-015 与 RM-016 已被 ADR-0010 明确退休retired仅作为历史谱系而非当前义务。下表完整罗列全部规范需求并标注其关联决策decision与关联行为 引用ID规范要求MUST关键决策 / 关联RM-001将上下文选择请求解析为恰好一个逻辑上下文身份否则返回SelectionErrorADR-0004RM-002选择解析必须与 CLI 提示、渲染、补救文案分离ADR-0004RM-001RM-003只有收到已认证 actor 并对其操作针对已解析上下文完成授权后才能签发授权上下文租约ADR-0004RM-001RM-004未知、歧义、不可用的选择结果必须是互不相同的SelectionError变体ADR-0004RM-001、SYS-007RM-005为破坏性操作签发租约前必须针对已认证 actor、请求操作、选择请求与已解析上下文校验破坏性意图断言ADR-0005RM-003、SYS-020RM-006必须通过显式资源适配器打开、供给、校验、释放 Potpie 管理的资源ADR-0004RM-007必须构造传给 Context Engine 的显式兼容依赖集与所有权声明ADR-0004RM-006、CE-005RM-008必须返回一个包含永久绑定到已解析上下文身份的单个 Context Engine 的授权上下文租约ADR-0004RM-001、RM-007、CE-006RM-009不得将已有 Context Engine 实例重定向到不同上下文身份ADR-0003RM-008、CE-008RM-010复用资源或引擎时必须满足相同上下文身份 显式兼容的组合配置ADR-0004RM-008RM-011除非按 RM-027 显式转移所有权否则必须幂等地释放为租约获取的每个 Potpie 管理资源ADR-0004RM-006RM-012Potpie 进程内与守护进程托管的操作处理器必须使用相同的选择、授权、依赖组合与租约获取策略ADR-0004RM-007、RM-008RM-013必须在保持正确性的最窄上下文与资源范围上协调资源获取、释放与租约生命周期冲突ADR-0005RM-008RM-014不得通过进程级操作锁串行化无关上下文ADR-0005RM-013RM-015retired获取必须返回授权上下文租约或类型化错误被 RM-036 取代ADR-0004RM-016retired错误在边界上保持区分被 RM-037 取代ADR-0004RM-017不得实现或覆写 Context Engine 领域语义ADR-0004CE-011RM-018不得拥有终端展示ADR-0004RM-002RM-019已认证 actor 缺乏请求操作或已解析上下文范围时返回AuthorizationErrorADR-0004RM-003、SYS-007RM-020租约必须标明已解析上下文身份与 actor-操作-上下文授权范围ADR-0004RM-003、RM-008RM-021租约必须为其范围内的每个承载资源的依赖暴露显式所有权与生命周期元数据ADR-0003RM-007、RM-020RM-022Resource Manager 与租约不得调用/派发 Context Engine 操作或返回领域/通用产品操作结果ADR-0004RM-008、SYS-019RM-023不得暴露通用操作派发、任意服务查找或镜像的引擎服务面ADR-0004RM-022、CE-020RM-024不得拥有守护进程传输ADR-0004RM-018RM-025失败的租约获取尝试必须尝试释放该尝试打开的全部 Potpie 管理资源ADR-0004RM-006、RM-011、RM-036RM-026租约拥有引擎终结清理时释放必须先请求引擎自有资源清理再释放供给该引擎的宿主机管理资源ADR-0003RM-011、CE-024RM-027对借用borrowed的 Potpie 管理依赖Resource Manager必须保留清理所有权ADR-0003RM-007、CE-022RM-028日志与错误详情默认排除凭据与敏感上下文负载ADR-0004RM-029显式把依赖转移给 Context Engine 后不得保留重复清理所有权ADR-0003RM-027、CE-024RM-030每个签发的租约必须暴露幂等释放能力ADR-0004RM-011、RM-020RM-031引擎自有清理失败不得阻止对每个宿主机自有资源租约拥有终结清理的释放尝试ADR-0004RM-026、RM-030RM-032租约释放失败必须以ResourceLifecycleError表示且不得抹掉已产生的领域结果、DomainError、DependencyError或EngineLifecycleErrorADR-0004RM-030、SYS-007RM-033破坏性意图校验失败必须返回AuthorizationErrorADR-0005RM-005、RM-019RM-034获取失败后的清理不完整时ResourceLifecycleError必须同时保留获取失败与清理失败细节ADR-0004RM-025RM-035破坏性意图校验失败不得签发授权上下文租约ADR-0005RM-005、RM-033RM-036获取必须返回授权上下文租约或类型化SelectionError、AuthenticationError、AuthorizationError、ResourceLifecycleError之一ADR-0004、ADR-0010RM-003、SYS-007RM-037上述四种错误在 Resource Manager 边界上必须结构上互不相同ADR-0004、ADR-0010RM-036、SYS-007RM-038获取期间调用方认证失败必须返回AuthenticationErrorADR-0010RM-003、RM-036RM-039调用方认证失败必须在授权、资源组合、引擎构造、租约签发之前停止获取ADR-0010RM-003、RM-038其中 RM-015/RM-016 的退休过程值得单独说明见 spec/decisions/ADR-0010-resource-manager-authentication-outcomes.mdADR-0009 规定的执行顺序原本就要求选择 → 认证 → 授权 → 组合 → 引擎获取但其结果枚举遗漏了AuthenticationError。由于新增一个允许的失败类别会改变边界可观察行为按照变更协议不能当作编辑性修正而是退休 RM-015/RM-016、新增 RM-036~RM-039并将变更记录在 spec/changes/SPEC-CHANGE-0009-correct-resource-manager-authentication-outcomes.md。五、授权上下文租约模型与语义规格中租约的概念模型包含四要素一个已解析的上下文身份一个绑定到该身份的 Context Engine已认证的 actor-操作-上下文授权范围显式依赖所有权与一个释放能力。它不包含execute函数、方法转发、任意服务、领域结果、传输 DTO 或展示行为。这些陈述正是 RM-008 与 RM-020~RM-023 的汇总。源码实现里potpie/runtime/resource_manager.py 的AuthorizedContextLease精确对应此模型class AuthorizedContextLease: Request scope over one authorized, context-bound cached engine. def __init__(self, *, manager, cache_key, context, scope, engine, ownership): self._manager manager self._cache_key cache_key self.context context # 已解析上下文身份 self.scope scope # AuthorizationScopeactor_id operation context self.engine engine # 绑定该身份的 Context Engine self.ownership ownership # LeaseOwnership宿主资源/引擎资源/引擎生命周期 self._released False self._release_lock asyncio.Lock() property def is_released(self) - bool: return self._released async def __aenter__(self) - AuthorizedContextLease: if self._released: raise RuntimeError(a released AuthorizedContextLease cannot be re-entered) return self async def __aexit__(self, *_exc: object) - None: await self.release() async def release(self) - None: async with self._release_lock: if self._released: return # 幂等重复 release 直接返回 release_task asyncio.create_task(self._manager._release_lease(self._cache_key)) try: await asyncio.shield(release_task) except asyncio.CancelledError: await release_task # 取消安全等待内部任务完成再标记 self._released True raise self._released True三个实现细节值得注意幂等释放RM-030_released标志 _release_lock保证并发或重复调用release()只生效一次取消安全cancellation-safeasyncio.shield使外部任务取消不会中断内部_release_lease即使取消也会等待任务完成后标记已释放——这正是一致性记录中cancellation-safe lease accounting所指借出而非转发租约暴露engine供处理器直接调用但自身没有任何execute/ 方法转发面。LeaseOwnership数据类则落实 RM-021 的显式所有权与生命周期元数据dataclass(frozenTrue, slotsTrue) class LeaseOwnership: host_resources: tuple[str, ...] () engine_resources: tuple[EngineResource, ...] () engine_lifetime: Literal[resource_manager_shutdown] resource_manager_shutdown release_closes_engine: Literal[False] False注意engine_lifetime固定为resource_manager_shutdown、release_closes_engine固定为False单个租约的释放不会关闭引擎引擎生命周期由 Resource Manager 的shutdown()统一收尾见下文清理与关闭。六、获取与释放流程规格给出如下规范流程selection - resolved identity - authenticated actor - authorized operation scope - resources acquired - compatible engine obtained - authorized context lease issued - handler invokes engine directly - lease released失败获取按 RM-025 处理精确的复用、驱逐与空闲生命周期策略在规格中保持延后。源码中ContextResourceManager.acquire()与_acquire_started()完整实现并强化了这一顺序async def _acquire_started(self, request: AcquisitionRequest) - LeaseOutcome: selection await self._resolver.resolve(request.selector) # 1. 选择解析 if isinstance(selection, Failure): return selection # SelectionError context selection.value authentication await self._authenticator.authenticate(request.authentication) if isinstance(authentication, Failure): return authentication # AuthenticationErrorRM-038/039 短路 actor authentication.value authorization await self._authorizer.authorize(actor, request.operation, context) if isinstance(authorization, Failure): return authorization # AuthorizationError scope authorization.value if (scope.actor_id ! actor.actor_id or scope.operation ! request.operation or scope.context ! context): return Failure(AuthorizationError(codeauthorization_scope_invalid, ...)) # 范围与请求不符 intent_failure self._validate_destructive_intent(request, scope) # 破坏性意图RM-005 if intent_failure is not None: return Failure(intent_failure) fingerprint await self._composer.fingerprint(context) # 组合指纹 if isinstance(fingerprint, Failure): return fingerprint cache_key (context, fingerprint.value) # 缓存键 (上下文, 指纹) key_lock await self._lock_for(cache_key) async with key_lock: cached self._cache.get(cache_key) if cached is None: created await self._create_cached_engine(contextcontext, fingerprintfingerprint.value) if isinstance(created, Failure): return created cached created.value async with self._state: self._cache[cache_key] cached self._creation_order.append(cache_key) async with self._state: cached.active_leases 1 return Success(AuthorizedContextLease(...))要点解读顺序即契约选择 → 认证 → 授权 → 破坏性意图校验 → 指纹 → 组合/缓存 → 租约。认证失败在授权之前就返回落实 RM-039 的短路要求缓存键 ContextIdentity, CompositionFingerprintCacheKey: TypeAlias tuple[ContextIdentity, CompositionFingerprint]。这直接落实 RM-009不能把引擎重定向到别的身份与 RM-010复用必须同身份 兼容组合配置——只要身份或指纹不同就会新建引擎per-key 锁_lock_for(cache_key)只锁同一个缓存键上的并发获取不同上下文可以并行呼应 RM-014指纹防漂移组合完成后若composition.fingerprint ! fingerprint返回composition_fingerprint_changed错误retry_posturesafe防止组合期间配置漂移造成不一致。组合指纹与选择器ContextSelector定义三种选择形态构造时即做校验SelectorKind Literal[explicit, active, repository] dataclass(frozenTrue, slotsTrue) class ContextSelector: kind: SelectorKind value: str | None None def __post_init__(self) - None: if self.kind in {explicit, repository} and not (self.value and self.value.strip()): raise ValueError(f{self.kind} selectors require a non-empty value) if self.kind active and self.value is not None: raise ValueError(active selectors cannot carry a value)即explicit/repository必须携带非空值active当前活跃上下文不允许携带值。CompositionFingerprint同样拒绝空值保证缓存键的稳定性。七、类型化失败模型与失败总结规格的失败总结表如下它同时是边界契约RM-036/RM-037条件结果没有、有多个或不可用的匹配上下文SelectionError变体调用方认证材料被拒绝AuthenticationError已认证 actor 缺乏操作或上下文范围AuthorizationError授权边界上的破坏性意图无效AuthorizationError宿主资源无法获取或释放ResourceLifecycleError领域、依赖与引擎生命周期结果发生在类型化上下文领域处理器调用 Context Engine 之后因此不经过 Resource Manager租约释放失败是独立的类型化结果且保留已产生的操作结果RM-032。源码为四种错误定义了统一结构frozen dataclass便于跨边界传输与诊断dataclass(frozenTrue, slotsTrue) class SelectionError: code: str message: str details: Mapping[str, object] field(default_factorydict) recommended_next_action: str | None None retry_posture: RetryPosture not_applicable category: Literal[selection] selection # AuthenticationError / AuthorizationError / ResourceLifecycleError 结构相同 # category 分别为 authentication / authorization / resource_lifecycleResourceLifecycleError.retry_posture默认为unknown其余为not_applicable除SelectionError等另有赋值处如resource_manager_draining用safeResourceManagerError: TypeAlias SelectionError | AuthenticationError | AuthorizationError | ResourceLifecycleErrorLeaseOutcome则表示为Success[AuthorizedContextLease] | Failure[ResourceManagerError]——即只能返回授权租约或自己的类型化失败。失败获取后的清理RM-025 / RM-034_create_cached_engine中任何失败点组合指纹变化、所有权校验失败、engine_factory抛异常或返回Failure都会调用_with_failed_acquisition_cleanup合并结果staticmethod def _with_failed_acquisition_cleanup(*, acquisition_error, cleanup_failures, source_errorNone): source source_error or acquisition_error details dict(acquisition_error.details) details[acquisition_failure] { category: str(getattr(source, category, resource_lifecycle)), code: str(getattr(source, code, acquisition_error.code)), retry_posture: str(getattr(source, retry_posture, acquisition_error.retry_posture)), } if cleanup_failures: details[cleanup_failures] cleanup_failures ...即 RM-034 要求清理不完整时返回的ResourceLifecycleError必须同时携带acquisition_failure原始获取失败类别/代码/重试姿态与cleanup_failures逐资源释放失败明细且_release_resources逆序逐资源释放、单个失败不阻断其余资源RM-031 的每个资源仍会得到一次尝试。八、破坏性操作意图校验RM-005 / RM-033 / RM-035ADR-0005 把人类确认下沉为不可信的带类型断言CLI 只负责渲染确认流程最终校验在 Resource Manager 完成。DestructiveIntent携带确认所需的最小绑定信息dataclass(frozenTrue, slotsTrue) class DestructiveIntent: confirmed: bool operation: str selector: ContextSelector request_id: str_validate_destructive_intent只有在该操作标记destructiveTrue时才校验且要求全部字段逐一对齐任一不符即返回destructive_intent_invalidstaticmethod def _validate_destructive_intent(request: AcquisitionRequest, scope: AuthorizationScope): if not request.destructive: return None intent request.destructive_intent if (intent is None or not intent.confirmed or intent.operation ! request.operation or intent.selector ! request.selector or intent.request_id ! request.request_id or scope.operation ! request.operation): return AuthorizationError(codedestructive_intent_invalid, messagedestructive intent does not match the authorized request) return None这保证意图断言必须与本次请求的操作、选择器、请求 ID 以及已授权的操作范围绑定一致杜绝复制粘贴确认跨请求复用校验失败返回AuthorizationErrorRM-033且不签发租约RM-035。一致性记录中destructive intent remains request-bound即指此设计。九、资源所有权与清理顺序RM-006 / RM-011 / RM-026 / RM-027 / RM-029所有权模型的核心是HostResource的ownership字段dataclass(frozenTrue, slotsTrue) class HostResource: Resource opened by Potpie and either retained or explicitly transferred. name: str release: Callable[[], Awaitable[None]] ownership: Literal[retained, transferred] retainedretained保留Resource Manager 继续持有清理所有权RM-027 的借用语义transferred转移所有权显式转移给 Context EngineRM-029Resource Manager 不得再重复清理。_validate_composition_ownership对组合做三重一致性校验对应 RM-029 与 RM-021 的显式所有权声明宿主资源名、引擎资源名各自不得重复宿主侧transferred资源集合必须与引擎侧transferred资源集合完全一致host-to-engine 转移声明必须配对宿主侧retained资源不得与引擎侧transferred资源重名转移给引擎的资源不能再保留宿主清理权。清理顺序与优雅关闭租约释放单次_release_lease只递减active_leases并通知等待者不关闭引擎引擎生命周期归resource_manager_shutdown引擎终结清理RM-026shutdown()逆序遍历_creation_order先对每个缓存引擎调用engine.close()引擎自有资源清理再逆序释放每个宿主retained资源——保证引擎清理先于宿主清理引擎清理失败会被记录但不跳过宿主资源释放RM-031幂等与重试shutdown()幂等_shutdown_complete保护未释放成功的资源留在cached.resources中以便后续重试任一项失败返回resource_manager_shutdown_failedretry_posturesafe。一致性记录特别提到 revision 2 验证了 retryable shutdown cleanup 与 construction-failure cleanup正是对应shutdown()的失败收集与_with_failed_acquisition_cleanup。十、并发协调最窄范围锁RM-013 / RM-014RM-013/RM-014 要求协调必须发生在最窄的上下文与资源范围且禁止用进程级锁串行化无关上下文。实现位于 potpie/runtime/coordinator.py 的OperationCoordinatorConflictKey区分三类冲突域context按上下文身份、resource按资源类型 归一化身份、daemon进程生命周期每个ConflictKey对应一个_ReadWriteLock读-写锁操作按其类型化安全类别SafetyClass见 potpie/runtime/operations.py请求read或write模式SHARED_CONTEXT_READ→ 上下文键readEXCLUSIVE_CONTEXT_MUTATION→ 上下文键writeEXCLUSIVE_RESOURCE_MUTATION/SHARED_CONTEXT_READ_EXCLUSIVE_RESOURCE_WRITE→ 上下文键 资源键组合资源键恒为write资源身份会做归一化例如快照目标先Path(value).expanduser().resolve(strictFalse)再拼键避免~/x与绝对路径被视为不同资源同一操作按需同时持有多把锁AsyncExitStack依次进入键按排序保证加锁顺序稳定。由于锁的粒度是上下文/资源两个不同上下文的读操作天然并行——这从实现层面兑现了 RM-014。RM-013 的协调资源获取、释放与租约生命周期冲突则由 Resource Manager 的_key_locks缓存键级锁与_state条件变量active_leases、_inflight_acquisitions记账共同承担。十一、进程内与守护进程的统一策略RM-012RM-012 要求进程内与守护进程托管的操作处理器共享同一套选择、授权、组合与租约获取策略。源码的组织方式印证了这一点potpie/runtime/composition.py 的build_local_runtime()显式组合LocalRuntimeCompositionroot 产品服务 engine 引擎服务 coordinator graph_metadata并通过default_host_mode()读取CONTEXT_ENGINE_HOST_MODEdaemon/in_process决定守护进程是否以进程内模式运行ContextResourceManager被注入到进程内处理器potpie/runtime/clients.py 中LocalEngineOperationHandler/DaemonEngineOperationHandler均通过它获取租约后再_dispatch显式引擎操作因此两端走的是同一个类、同一套acquire()策略守护进程侧 potpie/runtime/server.py 的RuntimeServer持有 bearer token 认证、OperationCoordinator、RuntimeOwnershipLockpotpie/runtime/ownership.py基于fcntl/msvcrt的 OS 级互斥锁保证同一时刻只有一个守护进程 boot但传输本身属于守护进程边界与 Resource Manager 解耦RM-024。一致性记录 RM2-E2 中的local and daemon paths share acquisition policy正是指向该设计。十二、一致性验证37 条行为的可复现证据一致性记录 spec/conformance/potpie-resource-manager.mdrecord_status: finalresult: passed确认 revision 2 的全部 37 条 active 行为RM-001~RM-014、RM-017~RM-039均有完整实现声明并通过验证并给出四类可复现证据RM2-E1 — 固定源码审查Resource Manager、ownership、local engine、typed clients、coordinator、runtime composition 在实现引用点上的逐条比对RM2-E2 — 完整根测试通道uv run pytest tests -m not premerge_journey -q结果1447 passed, 4 skipped, 1 deselectedRM2-E3 — 永久架构门禁完整特征化测试通道31 passed覆盖服务组分离与唯一具体运行时装配RM2-E4 — lint 与格式根 Ruff 策略通过格式检查774 files already formatted。与 Resource Manager 直接相关的单元测试集中在 tests/unit/test_context_resource_manager.py含选择解析、认证/授权失败短路、破坏性意图不匹配、组合所有权校验、失败获取清理、并发获取、取消安全释放、shutdown排空等用例另有 tests/unit/test_runtime_ownership.py、tests/unit/test_daemon_lifecycle_runtime.py、tests/unit/test_runtime_clients.py 与集成侧 tests/integration/test_canonical_daemon_runtime.py 佐证。十三、验收标准与实现说明规格给出了六条可验证的验收标准可作为评估任何 Resource Manager 实现是否合规的 checklist子系统只能返回授权租约或自己的类型化失败任何租约或 Resource Manager 表面都不能派发引擎操作依赖所有权与终结清理顺序必须显式选择、认证、授权必须先于受保护的引擎访问复用不能重定向引擎资源与租约协调不能串行化无关上下文子系统既不拥有领域语义、传输也不拥有展示。在实现说明中规格明确确切的模块布局、缓存形态、租约表示与服务分解仍是实现选择当前 setup 与 host-wiring 路径仅作为迁移证据。换言之这份契约约束的是行为不变式什么必须发生、什么绝不允许而非代码形态——读者在阅读或改造 potpie/runtime 目录下的实现时应以本契约的行为编号RM-xxx为验收锚点而非以某个类名是否存在为锚点。【免费下载链接】potpieContext Graph for AI Native SDLC项目地址: https://gitcode.com/GitHub_Trending/po/potpie创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考