Composition · Adoption · Provisioning · Upgrade
让 AI 知道项目采用什么、怎样安全建立基础设施，以及何时必须把决定交还给人。
Starter 不是第四套方法论，也不是第二套 Cloudflare 控制平面。它负责组合、采用和 Provisioning 编排：把 AHICP、PPF 与 Vault Interface 接到具体项目中，记录项目实际采用状态，并把经过授权的新项目基础设施工作交给固定版本的 PPF Provisioner。
Starter 解决的不是“内容怎么写”，而是“项目到底采用了什么”
组合
决定一个项目需要完整 AHICP、完整 PPF、Vault Interface，还是经过明确选择的精简组合。
采用
记录项目实际接受了哪个上游版本，而不是假设“模板更新了，所以项目也自动同意了”。
升级
比较上游的新版本和项目当前状态，区分可以自动更新的内容、需要合并的内容，以及必须保留的项目自有内容。
Provision
默认允许每项目一次短人工 GitHub → Cloudflare 配置；AI 负责其余可自动完成的工作，并验证后续 push 不再需要重复授权。
交接
把采用与 Provisioning 状态写成机器可读信息，使新的 AI 能恢复组件关系、授权边界、版本和下一步，而不是重新猜测。
为什么它不是第四套规范
AHICP
自己定义探究、证据、决定、项目记忆和 AI 协作规则。
PPF
自己定义源内容、构建、发布、版本和归档的生命周期。
Vault Interface
自己定义可以公开的项目元数据结构和验证规则。
Starter
只记录“这个项目怎样组合并采用上面这些组件”，不复制它们的规范，也不成为第二个权威来源。
这样设计的好处是：每个组件可以独立发展，而具体项目仍能清楚知道自己采用了什么。升级时也不会因为 Starter 变动，就把 AHICP、PPF 或项目自己的规则悄悄改掉。
升级为什么可以保持可解释
Starter 把三个容易混淆的事实分开记录：
template_source_commit这次组合或升级所依据的上游模板版本。它回答：“我们拿哪一版上游来比较？”
↓ 不等于
project_adopted_commit项目真正已经采用的语义版本。它回答：“项目实际上接受了哪一版规则？”
↓ 再结合
adoption_state组件目前是 active、deferred 还是 not-applicable。它回答：“这个组件现在是否实际生效？”
升级时，AI 还要读取每个上游组件在固定版本中的 ownership/manifest 信息，区分：
可以由上游维护
框架自己拥有的规范、模板或验证规则，可以根据升级计划更新。
必须保护项目自己的内容
项目原创内容、已经确认的决定、发布授权、私有状态和 provider actual state 不能因为套用模板而被覆盖。
新项目的默认配置
新项目默认采用 完整 AHICP + 完整 PPF + Vault Interface。只有使用者明确选择时，AI 才使用精简配置。项目“看起来简单”不是自动删掉某个组件的理由。
原创或未发布源内容默认保持 private（私有）；未正式公开的网页默认 restricted + authenticated（受限并需要认证）。是否公开网页和是否公开源仓库是两个不同决定。
普通新项目基础设施首选 workers-builds-native + private-project-quota-saver：在个人 ChongLiuPhil GitHub 账号下保持 private repository，每项目完成一次 Cloudflare Git connection，并默认使用 Worker-scoped Access。Content-only 改动不启动 GitHub Actions，只有目标分支为 main 的配置 PR 自动运行一个轻量 contract check，main 的自动 Web build 只由 Cloudflare Workers Builds 执行，重型 GitHub workflow 手动运行；自动成功 run 不上传 artifact，手动 publication artifact 默认保留 1 天。Preview 在独立保护验收前保持 disabled。高级 agent-provisioned-external-ci + external-ci-required 继续保留为可选方案；public framework 使用 full-validation full CI。
每项目一次配置，之后自动部署
1 · Private Repository项目默认创建在个人 ChongLiuPhil 账号下并保持 private；可以由使用者先手动创建。
↓
2 · 一次 Git / Cloudflare 连接把当前 repository 连接到 Workers Builds；GitHub 提示时，只为目标 repository 授权 Cloudflare Git integration。
↓
3 · 私人网页保护默认给目标 Worker 启用 Worker-scoped Access，并保持 Preview disabled；如果已有 verified account-wide Access，也可复用。
↓
4 · 第一次 + 第二次 Push 验证第一次确认 restricted deployment 与匿名拒绝；然后做第二次 push（content-only），确认 Workers Builds 自动部署、无需重新授权，并且没有启动重复的 GitHub Actions production Web build。
默认目标不是账户级零人工，而是：每项目一次配置，随后普通 source push 自动部署，同时用 private-project-quota-saver 避免浪费 private Actions 分钟。Public release、repository 公开、reader 扩大、domain/DNS、Provider 扩权，以及开启付费 Actions / billing 变化继续由人决定。
一个现有 GitHub 项目怎样升级
1 · 先审查识别项目现在的结构、内容、发布状态和已经存在的类似能力，不急着复制模板。
↓
2 · 建立映射把现有文件映射到 AHICP / PPF / Vault / Starter 的功能角色，优先复用已经可靠工作的结构。
↓
3 · 补齐缺口只增加真正缺失的状态、配置、验证和交接机制。
↓
4 · 验证并写回运行检查，记录采用版本、未解决问题、隐私与发布状态，让下一位 AI 可以继续。
Composition · Adoption · Provisioning · Upgrade
Tell an AI what the project adopts, how to provision it safely, and which decisions must remain human.
Starter is not a fourth methodology and not a second Cloudflare control plane. It owns composition, adoption, and provisioning orchestration: it connects AHICP, PPF, and Vault Interface to a real project, records adopted state, and hands authorized new-project infrastructure execution to the pinned PPF provisioner.
If you simply want to start a project
Begin with the AHICP introduction to understand the stack. When you are ready to begin, give its bootstrap instruction to an AI; the AI should enter Starter’s machine landing page and read the configuration and upgrade contracts.
Machine / Agent Entry
Starter answers “what has this project adopted?”
Compose
Choose full AHICP, full PPF, Vault Interface, or an explicitly selected reduced composition.
Adopt
Record the upstream version the project actually accepted instead of assuming that every template update is automatically adopted.
Upgrade
Compare newer upstream versions with the project’s current state and distinguish automatic updates, merge-managed changes, and project-owned work.
Provision
Allow one short human GitHub → Cloudflare bootstrap per project, automate everything else that is safe, and verify later pushes no longer need repeated authorization.
Handoff
Keep adoption and provisioning state machine-readable so a new AI can reconstruct component roles, authorization boundaries, versions, and the next safe action.
Why Starter is not a fourth framework
AHICP
Defines its own rules for inquiry, evidence, decisions, project memory, and AI collaboration.
PPF
Defines its own source, build, publication, release, and archive lifecycle.
Vault Interface
Defines its own public metadata schemas and validation rules.
Starter
Records how a project composes and adopts those systems. It does not copy their specifications or become a second source of truth.
Independent upstream authority lets each component evolve on its own while a project still knows exactly what it adopted. A Starter update therefore does not silently rewrite AHICP, PPF, or project-owned rules.
Why upgrades remain explainable
Starter records three facts that are easy to conflate:
template_source_commitThe pinned upstream template revision used for composition or upgrade mechanics: “Which upstream version are we comparing against?”
↓ is not the same as
project_adopted_commitThe semantic framework revision the project has actually adopted: “Which rules has this project accepted?”
↓ combined with
adoption_stateWhether the component is active, deferred, or not applicable: “Is this component currently in force?”
During an upgrade, the AI also reads the pinned upstream ownership manifest so it can distinguish:
Upstream-managed material
Specifications, templates, or validators owned by the framework can move forward according to the upgrade plan.
Project-owned material
Original content, accepted project decisions, publication authorization, private state, and provider actual state must not be overwritten merely because a template changed.
Default for new projects
New projects default to full AHICP + full PPF + Vault Interface. An AI uses a reduced profile only after explicit user selection; a project that looks simple is not permission to silently drop a component.
Original or unpublished source remains private by default. Unreleased web output remains restricted and authenticated by default. Public website access and public source-code access are separate decisions.
The preferred ordinary new-project infrastructure profile is workers-builds-native + private-project-quota-saver: keep the repository private under the personal ChongLiuPhil account, complete one project-level Cloudflare Git connection, and use Worker-scoped Access by default. Content-only changes do not start GitHub Actions, configuration PRs targeting main use one lightweight contract check, Cloudflare Workers Builds owns the automatic main-branch Web build, and heavy GitHub workflows are manual; automatic success artifacts stay off and manual publication artifacts retain for one day. Previews stay disabled until separately accepted as protected. agent-provisioned-external-ci + external-ci-required remains an optional advanced profile; public frameworks use full-validation full CI.
Configure each project once; automate later pushes
1 · Private repositoryDefault to the personal ChongLiuPhil account and keep the repository private. The user may create it manually first.
↓
2 · One Git / Cloudflare connectionConnect the target repository to Workers Builds; if GitHub prompts, authorize the Cloudflare Git integration for that repository.
↓
3 · Protect the private WebUse Worker-scoped Access by default and keep previews disabled; reuse verified account-wide Access only when it already exists.
↓
4 · Verify first and second pushesVerify the first restricted deployment and anonymous denial, then make a second content-only push and confirm automatic Cloudflare deployment without renewed authorization or a duplicate GitHub Actions production Web build.
The default goal is not account-wide zero-touch provisioning. It is one short project setup followed by automatic deployment for ordinary source pushes, while private-project-quota-saver avoids wasting private Actions minutes. Public release, repository publication, reader expansion, domain/DNS changes, provider-scope expansion, and enabling paid Actions/billing remain human decisions.
How an existing GitHub project is upgraded
1 · Inspect firstUnderstand the existing structure, content, publication state, and capabilities before modifying anything.
↓
2 · Map what already existsMap reliable existing files to AHICP / PPF / Vault / Starter roles instead of creating a duplicate source of truth.
↓
3 · Fill real gapsAdd only the missing state, configuration, validation, and handoff mechanisms.
↓
4 · Validate and persistRun checks and record adopted versions, unresolved issues, privacy state, and publication state so another AI can continue.