wip v26

Author: geraldarthurdavis

BITCODE_SPEC_V26.md

@@ -882,11 +882,12 @@ The production architecture above is constrained by the following fifth-gate rul
 - active route persistence must store preprocess snapshots and completion metadata under semantic `assetPackWrittenAsset` / `need` / `assetPack` / `writtenAssetType` aliases, so the commercial infrastructure itself shapes the protocol meaning at route entry and persistence time rather than only at final reread;
 - telemetry, notifications, and email-subject copy must use AssetPack and Shippable event/template identifiers such as `asset_pack_*`; compatibility identifiers such as `deliverable_*` are not V26-active wrappers, and failure telemetry must keep AssetPack completion context available across success and catch paths so mid-run failures still emit Bitcode asset-pack metadata instead of losing source-to-shares context to route-local scoping;
 - email-template filenames and identifiers must be AssetPack-native. Promptpart identifiers may remain compatibility-only carriers only when their rendered copy and prompt content teach Bitcode asset-pack runs, AssetPack synthesis artifacts, stored evidence, and Delivering Shippables rather than centering `deliverable` as the primary Bitcode object;
-- raw promptparts and promptpart-generation scripts for this corridor should likewise describe discovery/implementation/validation/finish in asset-pack-run, need-satisfaction, written-asset, Shippable, and delivery-mechanism terms, even when compatibility filenames and identifiers still include old trace tokens; phase-purpose raw PromptParts are already current AssetPack owners and therefore use `phase_assetpack{setup,discovery,implementation,validation,finish}` filesystem/export names rather than phase-level old-world names; this includes deeper setup-comprehension, finish-finalization, Shippable-delivery evidence, implementation-divider, create-code-change, PR-packaging, create-pull-request, code-change-readiness, and code-change-review-readiness promptparts, which must no longer teach PR-first, deployment-ceremony-first, or pre-Bitcode semantics where Bitcode now requires need-first asset-pack synthesis plus delivery mechanisms; active setup prompt module paths must use `comprehend-need` carriers, `COMPREHENDNEED` base PromptPart constants, and AssetPack-native PromptPart names as they are recut, and the former task-named setup PromptPart family is no longer admitted after `ASSETPACKSETUPCOMPREHENDNEED` owns the semantic mirror;
-- generic tool prompt reservoirs must follow the same semantic-mirror rule before promotion or broader reuse: `packages/generic-tools/need-comprehension` is the canonical Bitcode generic-tool package boundary for Need-comprehension support, its tools must be individually defined (`AnalyzeNeedSemanticsTool`, `ExtractNeedRequirementsTool`, `IdentifyNeedConstraintsTool`, `GenerateNeedSatisfactionCriteriaTool`, `ValidateNeedComprehensionTool`, and `AnalyzeNeedSatisfactionImplementationComplexityTool`) and only collected by `NeedComprehensionToolset`, and its `DocCodeToolPrompt` metadata, raw PromptParts, docs, and primitives must teach Bitcode Need comprehension, written-asset expectations, AssetPack context, delivery-mechanism boundaries, source-to-shares service questions, commercial accountability evidence, proof/verification needs, TypeScript-only source discipline, and explicit compatibility boundaries rather than task-first, cognitive, transcendent, or experimental non-Bitcode semantics;
+- raw promptparts and promptpart-generation scripts for this corridor should likewise describe discovery/implementation/validation/finish in asset-pack-run, need-satisfaction, written-asset, Shippable, and delivery-mechanism terms, even when compatibility filenames and identifiers still include old trace tokens; phase-purpose raw PromptParts are already current AssetPack owners and therefore use `phase_assetpack{setup,discovery,implementation,validation,finish}` filesystem/export names rather than phase-level old-world names; pipeline-level raw PromptParts with semantic mirrors use `pipeline_assetpackrun_*` filesystem/export names, so `pipeline_deliverable_*` is a removed trace family rather than an active bounded identifier; old deliverable-type classifier PromptPart families are likewise removed once the canonical V26 owners are present (`writtenAssetType = need-satisfaction-asset-pack` and `deliveryMechanismTemplate = pull-request`); validation Ready-to-Finish prompt ownership is the single `assetpackvalidationreadytofinish_*` family, so pre-validation `readytofinish_*` and type-keyed code-change / code-change-review / design-document Ready-to-Finish raw families are removed rather than retained as compatibility aliases; this includes deeper setup-comprehension, finish-finalization, Shippable-delivery evidence, implementation-divider, create-code-change, PR-packaging, and create-pull-request promptparts, which must no longer teach PR-first, deployment-ceremony-first, or pre-Bitcode semantics where Bitcode now requires need-first asset-pack synthesis plus delivery mechanisms; active setup prompt module paths must use `comprehend-need` carriers, `COMPREHENDNEED` base PromptPart constants, and AssetPack-native PromptPart names as they are recut, and former `deliverablesetup*` setup PromptPart families are no longer admitted after equivalent AssetPack-native setup, codebase, attachment, and repository owners exist;
+- generic tool prompt reservoirs must follow the same semantic-mirror rule before promotion or broader reuse: `packages/generic-tools/need-comprehension` is the canonical Bitcode generic-tool package boundary for Need-comprehension support, its tools must be individually defined (`AnalyzeNeedSemanticsTool`, `ExtractNeedRequirementsTool`, `IdentifyNeedConstraintsTool`, `GenerateNeedSatisfactionCriteriaTool`, `ValidateNeedComprehensionTool`, and `AnalyzeNeedSatisfactionImplementationComplexityTool`) and only collected by `NeedComprehensionToolset`, noncanonical tool/prompt/primitive/schema/raw-PromptPart owners must be removed after need-first owners exist, and its `DocCodeToolPrompt` metadata, raw PromptParts, docs, and primitives must teach Bitcode Need comprehension, written-asset expectations, AssetPack context, delivery-mechanism boundaries, source-to-shares service questions, commercial accountability evidence, proof/verification needs, and TypeScript-only source discipline rather than task-first, cognitive, transcendent, or experimental non-Bitcode semantics;
 - generic agent and web-search prompt reservoirs must follow the same semantic-mirror rule before promotion or broader reuse: `packages/generic-agents/need-comprehension` is admitted as the setup/pre-danger-wall PTRR agent that registers and composes the individual Need-comprehension tools before risk admission, `packages/generic-agents/web-researcher` is admitted only as discovery-phase web research for Bitcode need synthesis, `packages/generic-agents/web-search` plus `packages/generic-tools/web-search` are admitted only as lower-level source-attributed web-search/content-retrieval support for that discovery-phase need-synthesis corridor, and `packages/generic-agents/danger-wall` is admitted only as Bitcode need/AssetPack risk admission for unsafe mutation, private-data exposure, proof/evidence gaps, likely pipeline failure, AssetPack scope fit, delivery-mechanism fit, and manual-review triggers; none of these corridors may teach old scraping, generic security, content-safety, monitoring-product, canonical-need, proof, mutation, delivery, or live product ownership semantics;
-- all prompt, tool, agentic, pipeline, MCP, and execution-bearing systems must satisfy the V26 inference specification in `protocol-demonstration/V26_INFERENCE_SYSTEMS.md`: each active or admitted-support corridor must state its canonical need, prompt surface, tool contract, agentic role, execution carrier, asset-pack effect, boundary posture, and verification evidence before it can be treated as live Bitcode behavior; this includes an implementation-record posture for prompt primitives, tool prompt infrastructure, agent infrastructure, pipeline infrastructure, conversation inference, asset-pack synthesis compatibility, need-comprehension compatibility, and MCP/external ingress so no prompt or tool behavior is accepted only because old code happens to exist;
+- all prompt, tool, agentic, pipeline, MCP, and execution-bearing systems must satisfy the V26 inference specification in `protocol-demonstration/V26_INFERENCE_SYSTEMS.md`: each active or admitted-support corridor must state its canonical need, prompt surface, tool contract, agentic role, execution carrier, asset-pack effect, boundary posture, and verification evidence before it can be treated as live Bitcode behavior; this includes an implementation-record posture for prompt primitives, tool prompt infrastructure, agent infrastructure, pipeline infrastructure, conversation inference, asset-pack synthesis compatibility, need-comprehension reform, and MCP/external ingress so no prompt or tool behavior is accepted only because old code happens to exist;
 - prompt reservoir and AssetPack package-local build configs are part of the proof boundary: they must declare direct workspace dependencies, verify source-backed exact prompt/tool subpaths without emitting generated artifacts into `src/`, and avoid declaration-file path aliases or broad prompt-source catchalls that hide stale prompt ownership;
+- curated prompt-package root exports must name Bitcode-native prompt owners directly; repository-setup additions expose `PROMPTPART_SPECIFIC_TOOL_REPOSITORYSETUP_ASSETPACK_*` and must not retain `PROMPTPART_SPECIFIC_TOOL_REPOSITORYSETUP_DELIVERABLES_*` aliases after AssetPack mirrors exist;
 - the `packages/pipelines/asset-pack/*` corridor must hydrate a registry-bearing pipeline runtime at entry even when admitted callers still enter through a bare `Execution`, so phase/agent/prompt/tool proof does not depend on implicit `PipelineExecution` caller assumptions;
 - the `packages/pipelines/asset-pack/*` corridor must also hold an honest package-local typecheck boundary through the agent, MCP, VCS, prompt, and search support it still traverses, so fifth-gate no longer relies on runtime proof alone while the asset-pack written-asset corridor hides missing dependency links or loose cross-package typing; design/digest/validation PTRR agents that remain on this corridor must use local Bitcode `Prompt` / `PromptPart` composition with concrete plan/try/refine/retry Prompt registries, preserving compatibility registry IDs only as identifiers rather than as underspecified behavior;
 - broad old-world reform in V26 must follow the generic strategy fixed in `protocol-demonstration/V26_REFORM_STRATEGY.md`: classify the corridor first, add semantic mirrors before destructive rename, harden public package boundaries before wider consumer rollout, and add focused proof witnesses for each kept, repurposed, or cut corridor;
@@ -904,7 +905,7 @@ These are the complete planning units for fifth-gate.
 1. `Bitcode Terminal read closure`
    - close activity-ledger search/filter/pagination/selection/detail stability
    - prove selected-detail persistence and projected-live fallback
-   - prove authenticated `/api/activity` and `/api/executions/history{,/[:runId]}` reread against persisted execution rows, notifications, `final_work_summary`, repo snapshots, processing stats, and execution events rather than relying on mock-mode or unauthenticated fallback alone
+   - prove authenticated `/api/activity` and `/api/executions/history{,/[:runId]}` reread against persisted execution rows, notifications, Finish `assetPackCompletion` payloads, repo snapshots, processing stats, and execution events rather than relying on mock-mode or unauthenticated fallback alone
 2. `Bitcode Terminal write closure`
    - close give/need/fit/deposit/branch/closure write-through
    - prove immediate reread into the same ledger