Back to Details

github-delivery

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

GitHub Delivery

GitHub Delivery

Layer: Operating Model + Practice
このSkillはcurrent release-driven profileのGitHub materializationを定義する。Issue / PR / branch / PR state lifecycleそのものはConstitutionではない。
重要なのは、durable implementation identity、reviewable evidence、canonical consistency、authority boundary、organizational continuityを維持すること。将来別platform/topologyがこれらを同等以上に満たす場合は置換できる。
层级：Operating Model + Practice
本 Skill 定义 current release-driven profile 的 GitHub 落地方式。Issue / PR / branch / PR state 生命周期本身不属于 Constitution。
关键在于维持 durable implementation identity、reviewable evidence、canonical consistency、authority boundary 和 organizational continuity。未来如果其他 platform/topology 能同等或更充分地满足这些条件，则可以替换。

Source of Truth

事实来源

  • released source state: 
    main
  • active sprint/release integration state: 
    release-x-y-z
  • durable implementation work state: GitHub Issues
  • dependency state: GitHub Issue dependency metadata
  • release planning / health / portfolio state: Linear Projects / Initiatives
  • ticket review/integration: Pull Requests
  • transient execution state: Supervisor
main
はリリース済み・統合済みの安定状態を表す。 通常のticket PRを直接 
main
へ向けない。
  • released source state：
    main
  • active sprint/release integration state：
    release-x-y-z
  • durable implementation work state：GitHub Issues
  • dependency state：GitHub Issue dependency metadata
  • release planning / health / portfolio state：Linear Projects / Initiatives
  • ticket review/integration：Pull Requests
  • transient execution state：Supervisor
main
表示已发布且已集成的稳定状态。 不要将常规 ticket PR 直接指向 
main
。

Landing authority boundary

Landing 权限边界

PR landing前にcurrent PRを再取得し、actual head/baseから ticket-class / release-class を分類する。
在 landing 前重新获取 current PR，并根据 actual head/base 将其分类为 ticket-class / release-class。

Ticket-class

Ticket-class

  • base != main
  • current ticket/release integration topologyに属する
  • 通常はticket branch -> target 
    release-*
    、またはdependent ticket -> immediate predecessor ticket branch
ticket-class PRはper-PR user merge authorizationを要求しない。acceptance criteria、current-SHA validation、blocking review/conversation、staleness等のapplicable readiness/quality gateを満たしreal blockerがなければ、Agent/Coordinatorはready-to-mergeで停止せずlandingまで進める。ただしrelease candidate freeze中は同じrelease trunkへの候補外ticketの自律landingを保留し、実装・reviewは継続できる（ADR-0032）。
standaloneではAgent / subagent / Coordinator / Supervisorがticket landingを実行できる。parallel-orchestration下でshared durable integration stateへのordered landingが必要な場合はCoordinator / Supervisorがlandingを実行し、worker/subagentはvalidated candidateをhandoffする。
  • base != main
  • 属于 current ticket/release integration topology
  • 通常为 ticket branch -> target 
    release-*
    ，或 dependent ticket -> immediate predecessor ticket branch
ticket-class PR 不要求 per-PR user merge authorization。满足 acceptance criteria、current-SHA validation、blocking review/conversation、staleness 等适用的 readiness/quality gate，且不存在 real blocker 时，Agent/Coordinator 不应停在 ready-to-merge，而应继续推进至 landing。不过在 release candidate freeze 期间，应暂缓同一 release trunk 上候选外 ticket 的自主 landing，同时可继续实现和 review（ADR-0032）。
在 standalone 模式下，Agent / subagent / Coordinator / Supervisor 均可执行 ticket landing。在 parallel-orchestration 下，如需向 shared durable integration state 进行 ordered landing，则由 Coordinator / Supervisor 执行 landing，worker/subagent 负责 handoff validated candidate。

Release-class

Release-class

  • base == main
  • head == current release-*
release-class PRだけはexplicit user authorizationを必要とする。Ready/mergeable、green validation、approval、ticket PRへのstanding autonomous landing authority、genericな 
readyなPRをmerge
/ 
cleanup
/ 
最後まで進めて
等からrelease authorizationを推定しない。
release PRはbulk/autonomous ticket landingとauto-mergeから常に除外する。userがcurrent interactionで対象release PRまたは明確なrelease actionをexplicitにauthorizeした場合だけmergeできる。authorization後もcurrent head/base/SHAを再取得し、materialにcandidateが変化していればauthorization applicabilityを再確認する。
base == main
かつheadがcurrent release branchでないPRはinvalid integration pathとしてlandingを拒否する。
quality gateは「candidateがlanding可能な品質か」を判定する。ticket-classではその成功後に自律landingへ進み、release-classでは別途explicit authorization gateを要求する。ticket authorityをrelease authorityへ伝播させない。
  • base == main
  • head == current release-*
只有 release-class PR 才需要 explicit user authorization。不得根据 Ready/mergeable、green validation、approval、ticket PR 所具备的 standing autonomous landing authority，或 
合并已就绪的 PR
/ 
cleanup
/ 
执行到底
等泛化指令，推断 release authorization。
release PR 始终排除在 bulk/autonomous ticket landing 和 auto-merge 之外。只有当 user 在 current interaction 中明确授权目标 release PR 或明确的 release action 时，才能 merge。授权后仍须重新获取 current head/base/SHA；如果 material 中的 candidate 已发生变化，则重新确认 authorization 是否仍然适用。
base == main
且 head 不是 current release branch 的 PR，应作为 invalid integration path 拒绝 landing。
quality gate 用于判定 candidate 是否具备可 landing 的质量。ticket-class 在成功后进入自主 landing；release-class 则另行要求 explicit authorization gate。不得将 ticket authority 传播为 release authority。

Pull Request merge method

Pull Request merge 方法

current release-driven profileでは、GitHub PR landingは merge commit (
merge
) のみ（ADR-0018）。repository settingsは 
allow_merge_commit=true
/ 
allow_squash_merge=false
/ 
allow_rebase_merge=false
へreconcileし、権限不足なら差分をblocker/limitationとして報告する。Agent / automationはmerge APIでmethodを暗黙選択せず 
merge
を明示する。
squash merge / rebase mergeは使用しない。branch-local 
git rebase
はstack maintenance / conflict解消のbranch mechanicsとして許可する。stack landingがmerge commit semanticsを保証できない場合はordered merge-commit landingへfallbackする。method固定からauthorizationを導出しない。
在 current release-driven profile 中，GitHub PR landing 仅允许 merge commit（
merge
）（ADR-0018）。应将 repository settings 调整为 
allow_merge_commit=true
/ 
allow_squash_merge=false
/ 
allow_rebase_merge=false
；如果权限不足，则将差异作为 blocker/limitation 报告。Agent / automation 调用 merge API 时必须显式指定 
merge
，不得让 API 隐式选择。
不使用 squash merge / rebase merge。允许将 branch-local 
git rebase
用作 stack maintenance / 冲突解决的 branch mechanics。若 stack landing 无法保证 merge commit semantics，则回退到 ordered merge-commit landing。不得根据固定 method 推导 authorization。

Orchestrated workflow landing boundary

编排工作流 landing 边界

parallel-orchestration
の execution model 下では、Agent / subagent / worker は target release integration branch (
release-x-y-z
) や 
main
への shared durable integration state への ordered landing を直接実行しない。landing は Coordinator / Supervisor が durable integration の責務として行う。
  • ticket-class candidateはreadiness/quality gate通過後、追加authorizationなしでCoordinator / Supervisorへlanding handoffする。
  • release-class candidateはexplicit user authorization scopeもhandoff artifactへ含め、Coordinator / Supervisorはcurrent refs/SHAとauthorization applicabilityを再検証してからlandingする。
  • standaloneでrelease PRを扱うAgentは、explicit release authorizationがある場合に限り直接landingできる。
この境界を越えてworker/subagentがshared durable integration stateへlandingした場合、resultはstale candidateとして扱いreconciliationする。
在 
parallel-orchestration
execution model 下，Agent / subagent / worker 不直接向 target release integration branch（
release-x-y-z
）或 
main
这一 shared durable integration state 执行 ordered landing。landing 由 Coordinator / Supervisor 作为 durable integration 的职责执行。
  • ticket-class candidate 在通过 readiness/quality gate 后，无需额外 authorization，即可 handoff 给 Coordinator / Supervisor landing。
  • release-class candidate 的 handoff artifact 还需包含 explicit user authorization scope；Coordinator / Supervisor 必须重新验证 current refs/SHA 和 authorization applicability 后再 landing。
  • 在 standalone 模式下处理 release PR 的 Agent，只有在获得 explicit release authorization 时才能直接 landing。
如果 worker/subagent 越过此边界，将 landing 写入 shared durable integration state，则其结果应视为 stale candidate 并进行 reconciliation。

Main protection / release-only integration

main
保护 / 仅 Release 集成

GitHub上で保護機能を利用できるrepositoryでは、
main
をbranch protection / rulesetで保護する。
標準baseline:
  • main
    変更にはPull Requestを必須とする
  • required approving review countは 0 とし、個人開発で自己approvalを要求しない
  • conversation resolutionを必須とし、未解決review conversationを残したままmergeしない
  • required status checksは 既定で設定しない。存在しないCI/check名を推測・固定してmergeを停止させない
  • CIが存在する場合はquality evidenceとして確認するが、branch protectionの固定required checkとは分離する
  • direct push / direct web edit / force push / deletionを通常運用で許可しない
  • normal actor/adminが保護を日常的にbypassする運用を作らない
  • main
    への正規delivery pathは current 
    release-x-y-z -> main
    release PRだけとする
  • ticket branch / arbitrary branchから
    main
    へ向いたPRはmerge対象にしない
GitHubの標準branch protection/rulesetではPR head branch patternを直接制約できないため、存在しないrequired status checkを捏造して補わない。source branch制約はproject policy / release automation / merge executorで検証し、
base == main
かつ 
head == current release-*
でないPRのmergeを拒否する。既にrepository固有の信頼できるguardが存在する場合は利用できるが、そのcheck名を他projectへ固定継承しない。
readiness reportでは 
ruleset enforced
と 
merge-executor policy enforced
を区別する。外部guardがない場合、GitHub UIで任意headからのPR mergeを完全に禁止できるとは報告しない。Agentがmerge APIを呼ぶ直前には必ずbase/headを再取得してpreflightする。
初期化時にrepositoryのmain protection/rulesetを実際に確認する。設定変更権限がある場合は上記baselineへ作成・修復し、権限がない場合は差分をblockerとして報告する。
对于能够在 GitHub 上使用保护功能的 repository，应通过 branch protection / ruleset 保护 
main
。
标准 baseline：
  • 修改 
    main
    必须使用 Pull Request
  • required approving review count 设为 0，个人开发时不要求 self-approval
  • 必须解决 conversation，存在未解决的 review conversation 时不得 merge
  • required status checks 默认不配置。不得猜测或固定不存在的 CI/check 名称并因此阻止 merge
  • 如果存在 CI，应将其作为 quality evidence 验证，但要与 branch protection 中固定的 required check 分开处理
  • 常规运营中不允许 direct push / direct web edit / force push / deletion
  • 不应建立由 normal actor/admin 在日常运营中绕过 protection 的机制
  • 通往 
    main
    的正规 delivery path 仅允许 current 
    release-x-y-z -> main
    release PR
  • 不以 ticket branch / arbitrary branch 指向 
    main
    的 PR 为 merge 对象
GitHub 的标准 branch protection/ruleset 无法直接约束 PR head branch pattern，因此不得通过捏造不存在的 required status check 来补足。source branch 约束应由 project policy / release automation / merge executor 验证，并拒绝 merge 
base == main
且 
head != current release-*
的 PR。若 repository 已有自身特有的可靠 guard，可以使用，但不得把其 check 名固定继承到其他 project。
readiness report 中应区分 
ruleset enforced
与 
merge-executor policy enforced
。不存在外部 guard 时，不得声称 GitHub UI 能完全禁止从任意 head merge PR。Agent 调用 merge API 前必须重新获取 base/head 并执行 preflight。
初始化时实际检查 repository 的 main protection/ruleset。如有设置权限，则按上述 baseline 创建或修复；如无权限，则将差异报告为 blocker。

Weekly planning / adaptive release batching

周度规划 / 自适应 Release 批处理

週次はplanning checkpointであり公開日ではない。1 release train = 1 target version = 1 release branchを維持し、週内の早期release・複数週への持ち越しを許容する（ADR-0032）。
versionは変更の意味・互換性・user指定に従う。major/minor/patchは公開意図から選び、週次境界だけでbumpしない。
canonical format:
release-<major>-<minor>-<patch>
release train開始時に
main
からbranchを切る。緊急patchもrelease PRを経由する。候補はscope・公開価値・滞留・変更リスク・release-only実測コストで判定し、PR数だけで決めない。freezeとcarry-overは adaptive-release-batching.md に従う。
周度是 planning checkpoint，而非 publication date。维持 1 release train = 1 target version = 1 release branch，同时允许周内提前 release 或跨多个周 carry-over（ADR-0032）。
version 依据变更含义、兼容性和用户指定确定。major/minor/patch 应根据公开意图选择，不能仅因到达周度边界就 bump。
canonical format：
release-<major>-<minor>-<patch>
release train 开始时从 
main
创建 branch。紧急 patch 也必须经由 release PR。候选应根据 scope、公开价值、滞留程度、变更风险以及 release-only 实测成本判定，不能只按 PR 数量决定。freeze 和 carry-over 遵循 adaptive-release-batching.md。

Delivery forecast / capacity

交付预测 / 产能

1週間はplanning cadenceであり、選んだscopeが必ず1週間で完了するというestimateではない。
release / roadmap / milestoneの完了時期、release date、capacity、carry-over、agent数変更による短縮効果を判断する場合は 
agent-delivery-estimation
Skillを使用する。
  • IssueのSizeをcalendar durationとして扱わない
  • AI自身の「数日・数ヶ月」という主観的estimateをrelease dateの根拠にしない
  • dependency graph、Work Unit、observed throughput、human review capacity、CI/external wait、usage limitを使う
  • material unknownがある場合は 
    complete / conditional / unavailable
    を維持し、日付を捏造してfieldを埋めない
  • sprintごとの実績を次のforecast calibrationへ戻す
1 周是 planning cadence，不代表所选 scope 必定在 1 周内完成。
判断 release / roadmap / milestone 的完成时间、release date、capacity、carry-over，以及 Agent 数量变化带来的缩短效果时，使用 
agent-delivery-estimation
Skill。
  • 不将 Issue 的 Size 当作 calendar duration
  • 不将 AI 自身关于「数天」「数月」的主观 estimate 作为 release date 的依据
  • 使用 dependency graph、Work Unit、observed throughput、human review capacity、CI/external wait 和 usage limit
  • 存在实质性未知项时，保持 
    complete / conditional / unavailable
    ，不得捏造日期来填充字段
  • 将每个 sprint 的实际结果反馈到下一次 forecast calibration

Issue

Issue

durable planning unitは原則GitHub Issueにする。
Issueのtitle/bodyは日本語を標準とする。
最低限、該当するものを明示する:
  • 目的 / user-visible outcome
  • acceptance criteria
  • scope / non-scope
  • dependency / blocked-by
  • priority
  • size
  • area/component
  • target version
  • release date
  • accountable assignee
短命なresearch/worker subtaskまでIssue化する必要はない。
Issue dependency graphはcanonical dependency SoTであり、Git branch topologyだけでdependencyを表現しない。
durable planning unit 原则上应为 GitHub Issue。
Issue 的 title/body 以日语为标准。
至少明确以下适用项目：
  • 目的 / user-visible outcome
  • acceptance criteria
  • scope / non-scope
  • dependency / blocked-by
  • priority
  • size
  • area/component
  • target version
  • release date
  • accountable assignee
无需将短命的 research/worker subtask 也 Issue 化。
Issue dependency graph 是 canonical dependency SoT，不应只使用 Git branch topology 表达 dependency。

Linear planning control plane

Linear 规划控制平面

release planning / health / portfolio はLinearへ統一する。GitHub Projectsは標準運用では作成・要求・同期しない。
  • GitHub Issues: implementation scope / acceptance criteria / dependency の durable SoT
  • GitHub PR: review / integration / validation evidence
  • Linear Project / Initiative: release goal / target date / health / portfolio
  • Linear Issue: cross-repository blockerやexternal dependencyなどrelease-level coordinationに限定
GitHub IssueをLinear Issueへ全面mirrorしない。詳細は 
linear-release-control
Skillに従う。
Dependency execution上は必要に応じて 
blocked
/ 
stack-ready
/ 
integrated
を区別するが、GitHub ProjectsのStatus fieldを前提にしない。
release planning / health / portfolio 统一放到 Linear。标准运营中不创建、不要求、也不同步 GitHub Projects。
  • GitHub Issues：implementation scope / acceptance criteria / dependency 的 durable SoT
  • GitHub PR：review / integration / validation evidence
  • Linear Project / Initiative：release goal / target date / health / portfolio
  • Linear Issue：仅用于 release-level coordination，例如 cross-repository blocker 或 external dependency
不要将 GitHub Issue 全面 mirror 到 Linear Issue。详情遵循 
linear-release-control
Skill。
在 dependency execution 中，可按需区分 
blocked
/ 
stack-ready
/ 
integrated
，但不以 GitHub Projects 的 Status field 为前提。

Sprint / release cycle

Sprint / Release 周期

  1. 週次planning windowを置き、release intent / scopeとtarget versionを決める。release dateは 
    agent-delivery-estimation
    のevidence-backed forecastまたは外部deadlineと区別する。週次終了自体はpublication triggerにしない。
  2. 新しいrelease trainの開始時に 
    release-x-y-z
    branchを 
    main
    から作成する。
  3. sprint goalを定義する。
  4. Ready ticketを選択する。
  5. dependency / stack候補 / capacityを確認する。中長期capacity判断では 
    agent-delivery-estimation
    のcurrent evidence / bottleneck / forecast statusを参照する。
  6. ticketごとにnumber-only branchを作る。
  7. 最初のmeaningful commitをremoteへpublishし、remote head SHA一致を確認した直後にPRを必ず作成し、metadataとstateを設定する。active/incompleteならDraft、readiness条件を満たしていればReady for reviewとする。
  8. isolated workerをdependency/WIP制約内で並行起動する。
  9. independent ticketまたはstacked ticketをreviewし、current landing candidateを検証する。
  10. ticket/stackをReady + landing可能状態へ持っていく。
  11. ticket-class PRをdependency順にmerge commitで自律landingし、target release trunkへの到達を確認する。
  12. target release trunkへlandしたticketのlinked Issueを明示的にcloseし、dependent PRをreconcileしたうえでsafeならlanded ticket branchを削除する。
  13. repository stateをsweepし、PRなしticket branch / Ready未landing ticket PR / land済みopen Issue / merged後残存ticket branchを修復する。
  14. 週次またはproject-local triggerでrelease review（hold/candidate/blocked）。candidateならscope/SHAをfreeze、候補外landingを保留し、current SHAでrelease gateを実行する。候補変更時は再検証し、Linearをreconcileする。
  15. explicit release-merge authorizationがなければrelease merge前で停止する。authorizationがある場合だけrelease PRを 
    merge
    methodで 
    main
    へmergeし、merge commit / resulting 
    main
    SHAを確認する。
  16. project-local release contractに従い、version tag / GitHub Release / package / deploy / store artifact等のpublication処理を実行する。release PR mergeだけでrelease completeとしない。
  17. publication artifactをprovider/APIから再取得し、expected version・expected release SHA・draft/prerelease state・artifact availabilityを検証する。publicationが欠落・stale・別SHAならrelease blockerとして閉じるまで継続する。
  18. publication/post-release verification完了後、safeならmerged release branchを削除する。
  19. 候補外の未完了ticket/stackは次releaseへ明示的にretarget/rebaseし、dependencyとvalidationをreconcileする。release後はpublication済み 
    main
    を基準に次のrelease trainを開始する。
  1. 设置周度 planning window，确定 release intent / scope 和 target version。release date 应与 
    agent-delivery-estimation
    的 evidence-backed forecast 或外部 deadline 区分开来。周度结束本身不构成 publication trigger。
  2. 新 release train 开始时，从 
    main
    创建 
    release-x-y-z
    branch。
  3. 定义 sprint goal。
  4. 选择 Ready ticket。
  5. 检查 dependency / stack 候选 / capacity。中长期 capacity 判断应参考 
    agent-delivery-estimation
    的 current evidence / bottleneck / forecast status。
  6. 为每个 ticket 创建仅含编号的 branch。
  7. 立即将首个 meaningful commit 发布到 remote，确认 remote head SHA 与已发布 commit SHA 一致后，立即创建 PR 并设置 metadata 和 state。active/incomplete 时设为 Draft；满足 readiness 条件时设为 Ready for review。
  8. 在 dependency/WIP 约束内并行启动 isolated worker。
  9. review independent ticket 或 stacked ticket，并验证 current landing candidate。
  10. 将 ticket/stack 推进至 Ready 且可 landing 的状态。
  11. 按 dependency 顺序，以 merge commit 自主 landing ticket-class PR，并确认已到达 target release trunk。
  12. 明确 close 已 landing 到 target release trunk 的 ticket 所关联的 Issue，reconcile dependent PR 后，如安全则删除 landed ticket branch。
  13. sweep repository state，修复无 PR 的 ticket branch、Ready 但未 landing 的 ticket PR、已 landing 但仍 open 的 Issue，以及 merged 后残留的 ticket branch。
  14. 按周度或 project-local trigger 执行 release review（hold/candidate/blocked）。若为 candidate，则 freeze scope/SHA，暂缓候选外 landing，基于 current SHA 执行 release gate。候选发生变化时重新验证并 reconcile Linear。
  15. 如果没有 explicit release-merge authorization，则在 release merge 前停止。只有获得 authorization 时，才以 
    merge
    method 将 release PR merge 到 
    main
    ，并确认 merge commit / resulting 
    main
    SHA。
  16. 按 project-local release contract 执行 version tag / GitHub Release / package / deploy / store artifact 等 publication 处理。不能只因 release PR merge 就认定 release complete。
  17. 从 provider/API 重新获取 publication artifact，验证 expected version、expected release SHA、draft/prerelease state 和 artifact availability。如果 publication 缺失、stale 或指向其他 SHA，则将其作为 release blocker，并持续处理直至修复。
  18. publication/post-release verification 完成后，如安全则删除 merged release branch。
  19. 将候选外的未完成 ticket/stack 明确 retarget/rebase 到下一次 release，并 reconcile dependency 与 validation。release 后以已 publication 的 
    main
    为基准开始下一次 release train。

Release publication invariant

Release Publication Invariant

release-x-y-z -> main
のrelease PR mergeはintegration完了であり、publication完了そのものではない。
projectごとに「何が存在すればreleasedか」をproject-local release contractとして定義する。対象例:
  • semantic version tag
  • GitHub Release
  • package registry artifact
  • deploy / environment promotion
  • desktop/mobile installer・store artifact
  • checksum / provenance / attestation
最低限のinvariant:
  • expected versionとrelease merge commit / release source SHAの対応を固定する
  • publication automationは再実行しても安全なidempotent operationにする
  • existing tag/artifactがexpected SHAと異なる場合は上書きせずfail closedする
  • merge成功を根拠にpublication成功を推定しない
  • publish command / workflow successだけで完了せず、provider/APIからartifactを再取得して実在とidentityを確認する
  • GitHub Releaseを採用するrepositoryではdraft / prerelease状態もrelease contractに含める
  • publicationが人手・権限・store review等に依存する場合は、integration complete / publication pendingを別状態として報告する
post-merge verificationでpublication artifactが存在しない、expected release SHAを指さない、またはrequired artifactが利用不能ならreleaseは未完了として扱う。
release-x-y-z -> main
release PR 的 merge 表示 integration 完成，而不表示 publication 完成。
每个 project 都要在 project-local release contract 中定义「存在哪些内容才算 released」。示例：
  • semantic version tag
  • GitHub Release
  • package registry artifact
  • deploy / environment promotion
  • desktop/mobile installer・store artifact
  • checksum / provenance / attestation
最低限度的 invariant：
  • 固定 expected version 与 release merge commit / release source SHA 的对应关系
  • publication automation 必须采用可安全重复执行的 idempotent operation
  • existing tag/artifact 与 expected SHA 不同时，不得覆盖，而应 fail closed
  • 不得根据 merge 成功推断 publication 成功
  • 不仅依据 publish command / workflow 成功，还必须从 provider/API 重新获取 artifact，确认其存在且 identity 正确
  • 对采用 GitHub Release 的 repository，应将 draft / prerelease 状态纳入 release contract
  • 如果 publication 依赖人工、权限或 store review，应将 integration complete / publication pending 作为不同状态报告
post-merge verification 时，如果 publication artifact 不存在、未指向 expected release SHA，或 required artifact 不可用，则 release 应视为未完成。

Ticket branch

Ticket Branch

原則、1 top-level Issueにつき1 durable ticket branchを作る。
canonical format:
<issue-number>
例:
  • 123
  • 418
  • 1024
branch名に 
issue/
prefix、slug、title、type等を追加しない。
nested workerが返すephemeral immutable ref/commitはこの命名規則の対象外でよい。
原则上，每个 top-level Issue 创建一个 durable ticket branch。
canonical format：
<issue-number>
示例：
  • 123
  • 418
  • 1024
不要在 branch 名中添加 
issue/
prefix、slug、title、type 等内容。
nested worker 返回的 ephemeral immutable ref/commit 可以不遵循此命名规则。

Branch creation and PR creation are one start procedure

Branch 创建与 PR 创建是一个启动流程

active durable ticket branchにはpublished remote headとPRを必ず持たせ、PR stateを実際の作業状態と一致させる。
GitHubはremoteで解決できないheadやbaseと差分のないbranchにはPRを作れないため、canonical sequenceは次の通り:
  1. durable branchを作成する
  2. 最初のmeaningful commitを直ちに作る
  3. そのcommitをcanonical remoteへpublishする
  4. remote branch head SHAがpublishしたcommit SHAと一致することを確認する
  5. PRを直ちに作る。active/incompleteならDraft、readiness条件を満たしていればReady for reviewとする
  6. published commit + PRがない状態でactive implementationを継続しない
「後でpushする」「後でPRを作る」は禁止する。
このruleはhuman / Coordinator / implementation worker / subagentのすべてに適用する。 subagentがdurable branchを作る権限を持つ場合、そのsubagent自身がpublish + remote head検証 + PR作成/state設定まで完了する。remote publicationまたはPR mutation権限がないworkerはfirst meaningful commit後ただちにSupervisor/Coordinatorへcontrolを返し、Supervisor/Coordinatorがcommit publication・remote head SHA確認・PR作成/state設定を完了するまで追加implementationを進めない。
Ephemeral immutable worker ref/resultはdurable branchではないため対象外。
active durable ticket branch 必须具有已发布的 remote head 和 PR，且 PR state 必须与实际工作状态一致。
由于 GitHub 无法为 remote 中无法解析的 head，或与 base 没有差异的 branch 创建 PR，canonical sequence 如下：
  1. 创建 durable branch
  2. 立即创建首个 meaningful commit
  3. 将该 commit 发布到 canonical remote
  4. 确认 remote branch head SHA 与已发布 commit SHA 一致
  5. 立即创建 PR。active/incomplete 时设为 Draft，满足 readiness 条件时设为 Ready for review
  6. 在没有 published commit + PR 的状态下，不得继续 active implementation
禁止「稍后再 push」或「稍后再创建 PR」。
此规则适用于 human / Coordinator / implementation worker / subagent。
如果 subagent 有权创建 durable branch，则由该 subagent 自己完成 publish、remote head 验证以及 PR 创建/state 设置。如果 worker 没有 remote publication 或 PR mutation 权限，则在完成 first meaningful commit 后立即将控制权交还 Supervisor/Coordinator；在 Supervisor/Coordinator 完成 commit publication、remote head SHA 确认、PR 创建/state 设置之前，不得继续额外 implementation。
Ephemeral immutable worker ref/result 不是 durable branch，因此不在适用范围内。

PR metadata is required state

PR Metadata 是必需状态

PRはdiffだけではなくdurable work stateである。ただし、durable stateとPR proseを同一視しない。
作成時にrepository evidenceからnative GitHub metadataを評価し、最低限次を設定する。
  • linked Issue。number-only ticket branch 
    <issue-number>
    ではPR本文に 
    Closes #<issue-number>
    （cross-repositoryならqualified reference）または同等のnative linked-Issue relationを必須とし、PRから対応Issueを一意に再発見できるようにする。ただしnon-default release trunkへのlandingでは自動closeに依存せず、landing確認後にIssueを明示closeする
  • accountable assignee
  • reviewer request / CODEOWNERS-derived reviewer
  • repositoryで定義済みの適切なlabels
  • target release branch
  • stacked PRならstack trunk / immediate predecessor / relevant successor context
PR bodyはreviewerがchangeを理解・評価するためのartifactとして書く。必要に応じて次を含める。
  • purpose / intended outcome
  • implementation summary
  • acceptance criteriaまたはその参照
  • non-obvious design decision / constraint
  • review判断に必要なvalidation evidence
  • merge後も意味を持つlimitation / migration / compatibility note
current head SHA、ahead/behind、bot status、branch同期履歴、tool invocation、trial-and-error等を、作業contextに存在するという理由だけでPR bodyへ転写しない。GitHub checks、branch state、review status等のmutable stateはnative surfaceをcanonicalにし、proseへ重複させるのはreader判断に必要な場合だけにする。
ownership、scope、stack position、review requirementが変わった場合はmetadataも更新する。
存在しないlabelを勝手に作る、関係のないreviewerを形式的に指定する、PR author自身を自己reviewerとして埋める、という運用はしない。meaningful reviewer不在をPR bodyへ自動記録せず、それがreview/merge semanticsの理解に必要な場合だけ説明する。
PR title/body/review discussionには 
writing-discipline
を適用し、Select -> Compose -> Rereadを経てreader-oriented proseへ整える。
Issue/PR title/body/review discussionは日本語を標準とする。
PR 不仅是 diff，也是 durable work state。但不能将 durable state 与 PR prose 等同。
创建时根据 repository evidence 评估 native GitHub metadata，并至少设置以下内容。
  • linked Issue：对于 number-only ticket branch 
    <issue-number>
    ，PR 正文必须包含 
    Closes #<issue-number>
    （跨 repository 时使用 qualified reference），或等价的 native linked-Issue relation，确保可以从 PR 唯一地重新发现对应 Issue。不过，对 non-default release trunk 的 landing 不依赖自动 close；确认 landing 后应明确 close Issue
  • accountable assignee
  • reviewer request / CODEOWNERS-derived reviewer
  • repository 中已定义的适当 labels
  • target release branch
  • 如果是 stacked PR，则包含 stack trunk / immediate predecessor / relevant successor context
PR body 应作为 reviewer 理解并评估变更的 artifact。根据需要可包含：
  • purpose / intended outcome
  • implementation summary
  • acceptance criteria 或其引用
  • 不易理解的设计决策 / 约束
  • review 判断所需的 validation evidence
  • merge 后仍然有意义的 limitation / migration / compatibility note
不要仅因为 current head SHA、ahead/behind、bot status、branch 同步历史、tool invocation、trial-and-error 等信息存在于工作上下文中，就将其转写到 PR body。GitHub checks、branch state、review status 等 mutable state 应以 native surface 为 canonical，只有 reader 判断确有需要时才在 prose 中重复。
ownership、scope、stack position 或 review requirement 发生变化时，也要更新 metadata。
不要擅自创建不存在的 label、形式化指定无关 reviewer，或将 PR author 自己填为 self reviewer。不要把 meaningful reviewer 缺失自动记录到 PR body；仅当其影响 review/merge semantics 时，以 reader 所需的方式说明。
对 PR title/body/review discussion 应用 
writing-discipline
，经过 Select -> Compose -> Reread，整理为面向 reader 的 prose。
Issue/PR title/body/review discussion 以日语为标准。

Independent ticket PR

Independent Ticket PR

hard predecessorを持たないticketはtarget release branchをdirect baseにする。
text
main
└─ release-x-y-z
   └─ 123
PR:
123 -> release-x-y-z
没有 hard predecessor 的 ticket 应直接以 target release branch 为 base。
text
main
└─ release-x-y-z
   └─ 123
PR：
123 -> release-x-y-z

Dependency-aware stacked PR

Dependency-aware Stacked PR

同一repository・同一target release内でlinear hard dependencyを持つtop-level Issuesはstacked PRを使用してよい。
text
main
└─ release-x-y-z
   └─ 123
      └─ 124
         └─ 125
PR:
  • 123 -> release-x-y-z
  • 124 -> 123
  • 125 -> 124
全ticketはtarget release 
release-x-y-z
を共通stack trunkとして持つ。
Stack eligibility:
  • same repository
  • same target release
  • real hard dependency
  • stacked segmentがordered chainとして表現可能
  • predecessorにreviewable immutable commit/snapshotが存在
Issue dependency graphがbranchする場合、無理に1本のlinear stackへ変換しない。 PR stackはIssue dependency graphのlinear pathをexecution/integration topologyへprojectionしたものにすぎない。
1 top-level Issue = 1 durable ticket branch = 1 ticket PR
はstackでも維持する。 1 Issueを細切れのdurable PRへ分割するためだけにstackを使わない。
同一 repository、同一 target release 内存在 linear hard dependency 的 top-level Issues 可以使用 stacked PR。
text
main
└─ release-x-y-z
   └─ 123
      └─ 124
         └─ 125
PR：
  • 123 -> release-x-y-z
  • 124 -> 123
  • 125 -> 124
所有 ticket 都以目标 release 
release-x-y-z
为共同 stack trunk。
Stack eligibility：
  • same repository
  • same target release
  • real hard dependency
  • stacked segment 可表示为 ordered chain
  • predecessor 存在 reviewable immutable commit/snapshot
Issue dependency graph 出现分支时，不要强行转换为单条 linear stack。
PR stack 只是将 Issue dependency graph 的 linear path projection 到 execution/integration topology。
即使使用 stack，也维持 
1 top-level Issue = 1 durable ticket branch = 1 ticket PR
。 不要仅为了将 1 个 Issue 拆成多个 durable PR 而使用 stack。

Stack-ready execution

Stack-ready 执行

predecessorがrelease branchへ未mergeでも、reviewable immutable snapshotが存在すればdependent ticketを開始してよい。
開始時に少なくとも以下をpinする:
  • predecessor Issue/PR identity
  • predecessor commit SHA / immutable snapshot
  • common target release
  • immediate PR base
predecessor reviewで変更が入った場合、downstreamをdependency orderでrebase/updateし、影響したrequired validationを再実行する。
古いgreen resultを異なるSHAへ流用しない。
即使 predecessor 尚未 merge 到 release branch，只要存在 reviewable immutable snapshot，也可以开始 dependent ticket。
开始时至少 pin 以下内容：
  • predecessor Issue/PR identity
  • predecessor commit SHA / immutable snapshot
  • common target release
  • immediate PR base
predecessor review 中发生变更时，按 dependency 顺序对 downstream 执行 rebase/update，并重新运行受影响的 required validation。
不要把旧的 green result 用于不同的 SHA。

Ready for review

Ready for Review

Draftは未完了作業の一時状態である。次の条件をすべて満たしたopen PRは、userの明示指示を待たず速やかにReady for reviewへ移す。PR作成時点ですでに条件を満たす場合は最初からReadyとして作成し、形式的なDraft -> Ready往復を行わない:
  • Issue acceptance criteriaを実装済み
  • current SHAに対するticket-level integration quality gateを実行済み
  • blocking known issueが解消済み、または明示的にscope外
  • PR description / assignee / labels / reviewer metadataが現在の実装と一致
  • required reviewerをrequest済み。meaningful reviewer不在はreview/merge semanticsへ影響する場合だけreaderに必要な形で説明し、mutable stateとして恒常的にserializeしない
  • target release branchまたはimmediate stack predecessorとのstaleness/conflictを処理済み
  • predecessor変更によるdownstream revalidationを処理済み
Draft 是未完成工作的临时状态。满足以下全部条件的 open PR，应在无需 user 明确指示的情况下尽快转为 Ready for review。若创建 PR 时已满足条件，则直接以 Ready 创建，不进行形式上的 Draft -> Ready 往返：
  • 已实现 Issue acceptance criteria
  • 已针对 current SHA 执行 ticket-level integration quality gate
  • blocking known issue 已解决，或已明确归入 scope 外
  • PR description / assignee / labels / reviewer metadata 与当前实现一致
  • 已 request required reviewer。meaningful reviewer 缺失仅在影响 review/merge semantics 时，以 reader 所需的方式说明，不要将这一 mutable state 持续序列化
  • 已处理与 target release branch 或 immediate stack predecessor 之间的 staleness/conflict
  • 已处理 predecessor 变更导致的 downstream revalidation

Ticket landing / Done

Ticket Landing / Done

IssueのDone条件:
  • acceptance criteria satisfied
  • current landing candidateに対するapplicable project validationを実行済みで、既知の失敗を残していない
  • blocking review / conversation resolved
  • release/stack staleness handled
  • ticket changesがtarget release trunkへland済み
  • linked Issue explicitly closed after successful trunk landing
independent ticketでは通常のticket PR mergeがそのままtarget release trunkへのlandingになる。readiness/quality gateを満たしreal blockerがなければ、追加のuser merge authorizationを待たずmerge commitでlandingする。
GitHub native stacked PR等のplatform featureは実装手段として使えるが、policy semanticsをpreview feature固有の挙動に依存させない。
native stacked PRもticket-classとして自律landingできる。stackはbottom（trunkに最も近いPR）からdependency順に扱い、実際にlandingするcontiguous setの各ticketがacceptance criteria / review / current-SHA validationを満たしていることを確認する。mid-stack PRだけをintermediate predecessor branchへ孤立してmergeしたものをDone boundaryとして扱わない。
native stack landingを使えずordinary nested PRへfallbackする場合、例えば 
124 -> 123
の通常mergeはintermediate integrationにすぎない。#124のchangesがtarget 
release-x-y-z
へ到達するまでIssue #124をclose/Doneにしない。
contiguous stack groupまたはstack全体を一括landingする場合、含まれるすべてのticketが個別にacceptance criteria / review / current-SHA validationを満たしていることを確認する。landing後に各GitHub Issueを明示的にreconcileする。Linearはticketを全面mirrorしないため、release-level stateだけを必要に応じてreconcileする。
main
へのmergeをIssue単位のDone条件にはしない。Issue Done boundaryはtarget release trunkである。
GitHubのclosing keywordはdefault branch向けPRでのみ自動closeに使えるため、release trunkへのlanding成功確認後にCoordinatorまたはdelivery automationがIssueを明示的にcloseする。
Issue 的 Done 条件：
  • acceptance criteria 已满足
  • 已针对 current landing candidate 执行适用的 project validation，且未留下已知失败
  • blocking review / conversation 已解决
  • 已处理 release/stack staleness
  • ticket changes 已 landing 到 target release trunk
  • linked Issue 已在成功 landing 到 trunk 后明确 close
对于 independent ticket，常规 ticket PR merge 本身就是 landing 到 target release trunk。满足 readiness/quality gate 且不存在 real blocker 后，无需等待额外的 user merge authorization，即可使用 merge commit landing。
GitHub native stacked PR 等 platform feature 可以作为实现手段，但不得让 policy semantics 依赖 preview feature 的特定行为。
native stacked PR 也可作为 ticket-class 自主 landing。stack 从 bottom（最接近 trunk 的 PR）开始按 dependency 顺序处理，并确认实际 landing 的 contiguous set 中每个 ticket 都满足 acceptance criteria / review / current-SHA validation。不要把仅将 mid-stack PR 孤立 merge 到 intermediate predecessor branch 的结果视为 Done boundary。
如果无法使用 native stack landing 而回退到 ordinary nested PR，例如 
124 -> 123
的普通 merge 只是 intermediate integration。在 #124 的 changes 到达 target 
release-x-y-z
之前，不得将 Issue #124 close/Done。
contiguous stack group 或整个 stack 批量 landing 时，确认所含的每个 ticket 都单独满足 acceptance criteria / review / current-SHA validation。landing 后明确 reconcile 每个 GitHub Issue。由于 Linear 不全面 mirror ticket，因此仅按需 reconcile release-level state。
main
的 merge 不属于 Issue 级 Done 条件。Issue 的 Done boundary 是 target release trunk。
GitHub closing keyword 仅可在面向 default branch 的 PR 中用于自动 close，因此 release trunk landing 成功后，必须由 Coordinator 或 delivery automation 明确 close Issue。

Post-landing reconciliation / branch cleanup

Post-landing Reconciliation / Branch Cleanup

target release trunk landing後は次を同じticket operationとして実行する。
  1. ticket changesがtarget release branchからreachableであることを確認する
  2. linked GitHub Issueをcompletedとして明示closeする
  3. downstream/open PRがlanded ticket branchをbase/headとして使用していないか確認する
  4. dependencyがあればsurviving baseへretarget/rebaseし、affected validationを再実行する
  5. dependencyがなくなったlanded ticket branchをremoteから削除する
Issue closeやbranch cleanupを「後で行う任意housekeeping」にしない。削除権限/APIが利用できない場合はcleanup debtをdurableに残してblocker/limitationとして報告するが、黙ってstale branchを正常状態にしない。
target release trunk landing 后，以下操作属于同一个 ticket operation：
  1. 确认 ticket changes 可从 target release branch 到达
  2. 明确将 linked GitHub Issue close 为 completed
  3. 确认 downstream/open PR 没有继续使用 landed ticket branch 作为 base/head
  4. 如果存在 dependency，则 retarget/rebase 到 surviving base，并重新执行受影响 validation
  5. 从 remote 删除已不存在 dependency 的 landed ticket branch
不要把 Issue close 和 branch cleanup 当作「以后再做的可选 housekeeping」。如果没有删除权限/API，则将 cleanup debt 作为 durable state 保留，并报告为 blocker/limitation；不得默默地将 stale branch 视为正常状态。

Repository lifecycle reconciliation

Repository Lifecycle Reconciliation

recovery、onboarding、task completion時にremote branch / open+merged PR / Issue stateを突き合わせ、最低限次を修復する。
  • meaningful unlanded changesを持つnon-release durable branchにPRがない -> intended Issue/base/stackをrepository evidenceから復元してPRを作成
  • Draftだがreadiness gate済み -> Readyへ遷移
  • Ready ticket PRにreal blockerがない -> autonomous landing
  • target release trunkへland済みだがIssue open -> explicit close
  • landed/merged ticket branchが残存 -> dependency確認後delete
  • release PRがbulk/autonomous landing候補へ混入 -> 除外
intended baseを安全に復元できない等、本当に解けない場合だけblockerとして残す。
在 recovery、onboarding、task completion 时，对照 remote branch / open+merged PR / Issue state，并至少修复以下问题。
  • 存在 meaningful unlanded changes、但没有 PR 的 non-release durable branch：从 repository evidence 恢复 intended Issue/base/stack，并创建 PR
  • 仍为 Draft、但 readiness gate 已通过：转为 Ready
  • Ready ticket PR 没有 real blocker：自主 landing
  • 已 landing 到 target release trunk、但 Issue 仍 open：明确 close
  • landed/merged ticket branch 仍然存在：确认 dependency 后删除
  • release PR 混入 bulk/autonomous landing 候选：将其排除
只有当 intended base 无法安全恢复等确实无法解决的情况，才将其保留为 blocker。

Release integration

Release Integration

release branchは複数ticketの統合結果を保持するrelease train integration lineであり、1週間のplanning windowと1:1ではない。
release branchはrelease train開始時に作成する。GitHubは
main
と差分がない状態ではPRを作れないため、release branchに最初のmeaningful integrated differenceが入った直後にDraft release PRを作成する。zero-diff release branchだけはDraft PR invariantの例外である。
Draft release PRにもassignee / reviewer / labels / release goal / included Issuesを設定し、release期間中維持する。release readiness条件を満たしたらDraftのまま残さずReady for reviewへ遷移する。validationのmutable stateはGitHub checks等のcanonical surfaceで追跡し、PR proseにはrelease判断に必要な意味だけを書く。
release候補を選択しscope/current SHAをfreezeした後、release branch上でfull applicable quality gateを実行する。freeze中の新規ticket landingは禁止し、修正でSHAが変わった場合はapplicable gateを再実行する（candidate review）。
release PR:
release-x-y-z -> main
最低限:
  • release goal
  • included Issues/PRs
  • breaking changes
  • migration notes
  • release判断に必要なverification scope / evidence。CIのあるrepositoryではnative checksを正本とし、本文にはreaderが再確認に必要な時だけpointerを置く。CIのないrepositoryでは、検証したSHAと、controlを再実行するcommandを書く
  • durable known limitations
  • version/release metadata
public repositoryでは
main
protectionにより、このrelease PR以外の経路で
main
を更新できない状態を維持する。
release gate成功はrelease PRをready-to-mergeにするquality evidenceであり、release merge authorizationではない。release PRはbulk/autonomous ticket landingとauto-mergeから除外する。genericなmerge/cleanup/finish指示ではreleaseをmergeしない。current interactionで対象release PR/actionへのexplicit authorizationがなければReadyまで整えて停止し、current head SHA / release gate / blockersを報告する。authorizationがある場合だけ、直前にactual head/base/current SHAを再取得して 
base == main
かつ 
head == intended current release-*
を確認し、
merge
methodでmergeする。
release PRがmergeされた時点で 
main
がそのversionのreleased source stateになる。
release PR merge後もtag / deploy / package / store等のproject-defined actual availabilityを確認し、final Linear Project Update / 
Released
checkpointを反映してからLinear ProjectをCompletedへ進める。
release branch 是承载多个 ticket 集成结果的 release train integration line，并不与 1 周的 planning window 一一对应。
release branch 在 release train 开始时创建。由于 GitHub 无法在 release branch 与 
main
无差异时创建 PR，因此在 release branch 首次出现 meaningful integrated difference 后，立即创建 Draft release PR。只有 zero-diff release branch 是 Draft PR invariant 的例外。
即使 Draft release PR，也要设置并在整个 release 期间维持 assignee / reviewer / labels / release goal / included Issues。满足 release readiness 后，不得继续保持 Draft，应转为 Ready for review。validation 的 mutable state 应通过 GitHub checks 等 canonical surface 跟踪，PR prose 只写 release 决策所需的含义。
选定 release 候选并 freeze scope/current SHA 后，在 release branch 上执行全部适用的 quality gate。freeze 期间禁止新的 ticket landing；如果修复导致 SHA 变化，则重新执行适用 gate（candidate review）。
release PR：
release-x-y-z -> main
至少包含：
  • release goal
  • included Issues/PRs
  • breaking changes
  • migration notes
  • release 决策所需的 verification scope / evidence。在有 CI 的 repository 中，native checks 是正本，正文仅在 reader 需要复核时放置 pointer。在没有 CI 的 repository 中，写明已验证的 SHA 和重新执行 control 的 command
  • durable known limitations
  • version/release metadata
在 public repository 中，通过 
main
protection 维持除此 release PR 外没有其他路径更新 
main
的状态。
release gate 成功是 release PR 达到 ready-to-merge 的质量证据，而不是 release merge authorization。release PR 始终排除在 bulk/autonomous ticket landing 和 auto-merge 之外。泛化的 merge/cleanup/finish 指令不能用于 merge release。如果 current interaction 中没有针对目标 release PR/action 的 explicit authorization，则最多整理至 Ready 并停止，同时报告 current head SHA / release gate / blockers。只有获得 authorization 时，才在紧邻操作前重新获取 actual head/base/current SHA，确认 
base == main
且 
head == intended current release-*
，再使用 
merge
method merge。
release PR merge 时，
main
即成为该 version 的 released source state。
release PR merge 后，仍需确认 tag / deploy / package / store 等 project-defined actual availability，更新最终的 Linear Project Update / 
Released
checkpoint 后，再将 Linear Project 转为 Completed。

Version / tag-triggered release consistency

Version / Tag-triggered Release Consistency

versionはSemantic Versioning 
MAJOR.MINOR.PATCH
をcanonical formとする。external ecosystem上の明確な理由がない限り省略形式を使わない。
tag pushをpublish/release triggerとして使用するprojectでは、tag versionとauthoritative package/project versionを必ず一致させる。
例:
  • tag: 
    v1.4.2
  • authoritative version: 
    1.4.2
release automationは不一致を自動修正して続行せずfailする。
conditional minimum sequence:
  1. tag format validation
  2. semantic version extraction
  3. authoritative version comparison
  4. current release SHAに対するfull applicable release gate
  5. release build/package
  6. successful validation後のみpublish/release
複数release unitを持つprojectではauthoritative version sourceまたはunitごとのversion policyを明示する。
adaptive release branch modelとtag releaseは競合しない。release branch/PRがsource delivery、tag/publishがartifact deliveryに使われる場合、両者が同じintended version/SHAを指すことを検証する。
version 以 Semantic Versioning 
MAJOR.MINOR.PATCH
为 canonical form。除非外部 ecosystem 有明确理由，否则不使用省略形式。
对于以 tag push 作为 publish/release trigger 的 project，必须使 tag version 与 authoritative package/project version 一致。
示例：
  • tag：
    v1.4.2
  • authoritative version：
    1.4.2
release automation 遇到不一致时必须 fail，不得自动修正后继续。
最低限度的条件顺序：
  1. tag format validation
  2. semantic version extraction
  3. authoritative version comparison
  4. 针对 current release SHA 执行完整适用的 release gate
  5. release build/package
  6. 仅在 validation 成功后执行 publish/release
对于具有多个 release unit 的 project，必须明确 authoritative version source，或按 unit 划分的 version policy。
adaptive release branch model 与 tag release 不冲突。release branch/PR 用于 source delivery，tag/publish 用于 artifact delivery 时，验证两者指向相同的 intended version/SHA。

Multi-agent integration

Multi-agent Integration

  • 1 top-level Issue = 1 ticket branch = 1 ticket PRを基本とする。
  • independent ticket PR base = target 
    release-x-y-z
    。
  • stacked dependent ticket PR base = immediate predecessor ticket branch。
  • all stack members share one target release trunk。
  • implementation workerはticket branchを複数agentで直接共有しない。
  • nested workerはresolved immutable identityへpinされたcommit/ref resultを返す。
  • durable branchを作るworker/subagentにはremote publication + PR creation/state / metadata contractも適用する。
  • Coordinator/Supervisorだけがorchestrated shared durable integration stateへ順序立てて統合する。
  • ticket-class landingはreadiness/quality gate通過後に追加authorizationなしで進める。
  • release-class landingだけexplicit user authorizationを要求する。
  • merge/landing前にtarget release / predecessor / current validation SHA / actual head+base classificationを確認する。
  • Doneへ移す前にactual target release trunk上のlandingを確認し、Issue close + safe branch cleanupまでreconcileする。
  • main
    protection/rulesetを上記baselineで初期化・検証し、merge executorはrelease-only main source invariantを確認する。
  • 基本原则为 
    1 top-level Issue = 1 ticket branch = 1 ticket PR
    。
  • independent ticket PR base = target 
    release-x-y-z
    。
  • stacked dependent ticket PR base = immediate predecessor ticket branch。
  • 所有 stack members 共享同一个 target release trunk。
  • implementation worker 不直接让多个 Agent 共享 ticket branch。
  • nested worker 返回绑定到 resolved immutable identity 的 commit/ref result。
  • 创建 durable branch 的 worker/subagent 同样适用 remote publication + PR creation/state / metadata contract。
  • 只有 Coordinator/Supervisor 才能将 orchestrated shared durable integration state 有序集成。
  • ticket-class landing 在通过 readiness/quality gate 后，无需额外 authorization 即可推进。
  • 只有 release-class landing 才需要 explicit user authorization。
  • merge/landing 前确认 target release / predecessor / current validation SHA / actual head+base classification。
  • 转为 Done 前，确认 changes 已实际 landing 到 target release trunk，并完成 Issue close + safe branch cleanup reconciliation。
  • 按上述 baseline 初始化和验证 
    main
    protection/ruleset，并由 merge executor 验证 release-only main source invariant。

Language policy

Language Policy

  • Issue title/body: 日本語
  • PR title/body/review discussion: 日本語
  • internal planning docs: 日本語
  • commit message: 英語
  • source code: 英語
commit format:
<work-prefix>: <extremely concise title>
  • Issue title/body：日语
  • PR title/body/review discussion：日语
  • internal planning docs：日语
  • commit message：英语
  • source code：英语
commit format：
<work-prefix>: <extremely concise title>

Refinement boundary

Refinement Boundary

GitHub delivery topologyを変更する場合、最低限次を維持する。
  • durable work identityとdependencyを別actorから再発見できる
  • integration candidateとvalidation/review evidenceを対応付けられる
  • current/released source stateのcanonical authorityが曖昧にならない
  • consequential landingのauthority boundaryが維持される
  • interrupted workをconversation historyなしでreconcileできる
  • valid workがdelivery ceremonyだけで不必要に停止しない
branch名、PR creation/state timing、release branch cadence等はcurrent profileのdefaultであり、上位guaranteeを満たすalternativeを一律に禁止しない。
修改 GitHub delivery topology 时，至少要维持以下内容。
  • durable work identity 和 dependency 可由另一 actor 重新发现
  • integration candidate 与 validation/review evidence 可以对应
  • current/released source state 的 canonical authority 不产生歧义
  • consequential landing 的 authority boundary 得到维持
  • interrupted work 可在没有 conversation history 的情况下完成 reconciliation
  • valid work 不会仅因 delivery ceremony 而被不必要地阻止
branch 名、PR creation/state timing、release branch cadence 等是 current profile 的 default；只要满足更高层级的 guarantee，就不一律禁止采用 alternative。