[Context Fabric governance] Protect and adopt main as the integration/default branch

Current accepted topology

The Context Fabric program has converged on main as the intended protected integration/default branch for both ContextualWisdomLab/context-graph-contracts and ContextualWisdomLab/enterprise-architecture-core. Historical guidance that kept develop as the long-term default/integration branch is superseded.

Fresh 2026-09-01 repository evidence:

context-graph-contracts

repository default_branch=develop;
develop@99cb5468ba3c15c5e79688f53dee74724fae2d13, reported protected;
main@99cb5468ba3c15c5e79688f53dee74724fae2d13, unprotected;
current root/stack PRs explicitly require eventual protected main integration and prohibit merging the stack through the obsolete develop integration model;
no GitHub release exists yet.

enterprise-architecture-core

repository default_branch=develop;
develop@1c0fa8b15ceb9e72186274aeb255d6777eb84ef4, reported protected;
main@ca6889497728e1a3f09d68790a9096576e13a3ff is the active product line but is not the default/protected integration authority;
current root/stack PRs explicitly require eventual protected main integration and treat the historical main -> develop synchronization lane as superseded;
no GitHub release exists yet.

Organization ruleset 18156473 targets ~DEFAULT_BRANCH. While repository metadata still names develop, the organization rule therefore follows the wrong long-term integration ref. This is a central control-plane defect, not a product-repository decision and not a reason to weaken release contracts.

Required safe transition

Execute in this order for each Context Fabric repository, refetching live state between every step:

Pre-protect main first. Apply the intended integration/release-grade controls to main before changing default metadata. Preserve deterministic required workflows/security/coverage/package/SBOM/provenance/thread-resolution/deletion/non-fast-forward controls and prohibit routine bypass.
Preserve transition protection on develop only as needed. Do not create a window where either integration candidate is unprotected while stacks are being reconstructed.
Change repository default branch to main only after its effective protection is proven.
Re-read organization/repository rulesets after the switch. Verify ~DEFAULT_BRANCH now resolves to main and that no required control silently fell away.
Rebuild Context Fabric stacks dependency-first from fresh protected main. No predecessor-head review/check/package/provenance evidence transfers across base/default movement.
Reacquire exact-head gates under the new topology. Merge through ordinary protected governance only when the unchanged candidate satisfies then-live policy.
Release only from an exact protected integrated main SHA. Version, package, SBOM, provenance, reproducibility, conformance/admission and release metadata must identify the same immutable source/artifact set.

Interaction with solo-maintainer review governance

.github#772 independently owns the scoped removal/replacement of the structurally impossible generic approving-review-count rule for the current solo-maintainer organization. Self-approval remains forbidden and bot/model output is not human approval. This issue must not wait for fictional reviewer provisioning; branch topology and deterministic protection are executable central governance work.

RED acceptance

Accepted integration/default intent is main.
Repository metadata still says develop.
Organization ruleset 18156473 follows ~DEFAULT_BRANCH, therefore follows develop.
main is not yet the coherent protected default integration authority.
Context Fabric PR stacks cannot safely integrate/release without either using the obsolete topology or targeting an unprotected branch.

GREEN acceptance

For both Context Fabric repositories:

main has integration/release-grade effective protection before the default switch;
repository default_branch=main;
~DEFAULT_BRANCH organization rules resolve to main and required deterministic controls remain enforced;
any temporary develop transition protection is explicit and may later be retired without weakening main;
root PRs are rebuilt against fresh protected main, descendants are restacked dependency-first, and all moved heads reacquire exact-current-head checks/reviews/artifacts;
a protected-main post-integration workflow run proves repository CI/package/security evidence on the resulting exact merge SHA;
no routine administrator bypass or stale/predecessor evidence is used.

Non-goals

Retargeting current stacks to unprotected main before protection exists.
Merging through develop merely because it is currently default.
Recreating obsolete main -> develop synchronization work.
Weakening deterministic gates during migration.
Treating open Context Graph/EA PR heads as released production contracts.

Fresh Context Fabric owner-boundary extension: the same stable-branch protection defect also exists on ContextualWisdomLab/enterprise-architecture-core/main.

Current enterprise-architecture-core/main: ca6889497728e1a3f09d68790a9096576e13a3ff, GitHub reports protected=false and legacy protection disabled.
Protected default/integration branch develop remains 1c0fa8b15ceb9e72186274aeb255d6777eb84ef4 with protected=true.
The repository's current supply-chain workflow on main explicitly contains attest-protected-main and emits SLSA/SBOM attestations only for push on refs/heads/main. PR 🧪 [testing improvement] iter_json_objects 함수에 대한 단위 테스트 추가 #21 is separately repairing post-integration workflow coverage for both develop and main; it does not make an unprotected main a valid release authority.

First causal boundary is therefore central branch/ruleset governance, not repository source. Extend this issue's accepted remedy to EA Core stable main as well: preserve develop as the protected default integration branch, but protect main under the intended stable/release controls before treating attest-protected-main output as release evidence. Do not bypass review/check policy or change the default branch merely to make documentation true. GREEN proof for EA Core is the same shape as Context Graph: GitHub reports the exact stable main ref protected by the intended live ruleset, then one unchanged promoted main SHA produces the required repository/package/SBOM/provenance evidence before any release/tag claim.

Fresh Context Fabric revalidation finds the same stable-branch control gap in the second program-owned Git Flow repository, so the central remedy should cover both stable main refs rather than only the contract provider.

ContextualWisdomLab/context-graph-contracts/main@99cb5468ba3c15c5e79688f53dee74724fae2d13: GitHub still reports protected=false, legacy protection disabled.
ContextualWisdomLab/enterprise-architecture-core/main@ca6889497728e1a3f09d68790a9096576e13a3ff: GitHub also reports protected=false, legacy protection disabled.
enterprise-architecture-core#21@ddeacbf37847b21f874e13e463f2abc5ca9d5c0a is the current dependency-root PR targeting main before Sync OpenCode review failure handling #14 can synchronize stable main back into protected develop. Its repository-owned exact-head CI/runtime-readiness/supply-chain runs are already terminal GREEN, but there is still no qualifying formal approval and the independent-reviewers team request still returns HTTP 422 because the team is not a repository collaborator.

First causal boundary: the repositories intentionally implement Git Flow with protected develop, but stable main is outside the live protection/ruleset scope. The workflow patch in #21 only makes protected-develop integration execute repository checks; it cannot make an unprotected main mutation valid governance evidence.

Smallest central remedy: extend the accepted stable-branch ruleset to both context-graph-contracts/main and enterprise-architecture-core/main while preserving develop as each default integration branch, then revalidate exact branch protection plus the counted independent-review path tracked in #772. Context Fabric will not use the current unprotected main refs as a bypass.

Fresh direct branch revalidation (2026-08-19 UTC / 2026-08-20 KST): ContextualWisdomLab/context-graph-contracts still has protected default/integration develop@99cb5468ba3c15c5e79688f53dee74724fae2d13 (protected=true) while stable release main@99cb5468ba3c15c5e79688f53dee74724fae2d13 remains protected=false. The release boundary is therefore still fail-closed: no immutable cwl-context-contracts release should be promoted from main until the central ruleset makes that exact stable branch protected without changing develop as the Git Flow default. Revalidate this branch flag after the owner-side ruleset change before Context Fabric promotion/release work resumes.

Fresh Context Fabric release-governance revalidation — 2026-08-21 KST.

The stable-branch protection gap is still live and unchanged at the exact repository refs:

ContextualWisdomLab/context-graph-contracts/develop@99cb5468ba3c15c5e79688f53dee74724fae2d13 reports protected=true.
ContextualWisdomLab/context-graph-contracts/main@99cb5468ba3c15c5e79688f53dee74724fae2d13 reports protected=false with legacy protection disabled.

The dependency-root source candidate remains context-graph-contracts#4@99d230991b9d48fbf87489e0b375b7bbf09d8559, whose exact-head CI/supply-chain/security/SAST evidence is terminal GREEN but whose counted independent review remains separately blocked by #772. Even after that review boundary is repaired and the contract stack integrates through protected develop, an immutable release must not be promoted from the currently unprotected main branch.

Smallest central-owner remedy remains to attach the accepted stable-release controls to main while preserving develop as the Git Flow default/integration branch. Revalidation criterion from Context Fabric: after the ruleset change, re-fetch main and require GitHub to report it protected under the intended policy; only then, after dependency-first integration, promote one exact integrated source commit to main, require fresh exact-SHA CI/package/SBOM/provenance and independent-review evidence, and create the tag/release from that unchanged protected commit. Do not solve by changing the default branch, direct unreviewed push, bypass, or weakening release gates.

Fresh direct revalidation on 2026-08-21 KST shows the stable-branch protection state has changed since the last owner-path evidence: both exact stable refs now report protected=true while their commit SHAs remain unchanged.

ContextualWisdomLab/context-graph-contracts/main@99cb5468ba3c15c5e79688f53dee74724fae2d13: protected=true; legacy branch-protection payload still reports protection.enabled=false, so the observed protection is consistent with a ruleset rather than the legacy branch-protection API.
ContextualWisdomLab/enterprise-architecture-core/main@ca6889497728e1a3f09d68790a9096576e13a3ff: protected=true; legacy branch-protection payload likewise reports protection.enabled=false.
context-graph-contracts/develop@99cb5468ba3c15c5e79688f53dee74724fae2d13 remains protected=true and remains the repository default/integration branch.

This clears the previously observed protected=false branch-flag portion of #1137 for both program-owned Git Flow repositories, but Context Fabric will not yet treat the issue as fully accepted because this connector did not expose the applicable ruleset body. Central governance should verify that the attached rule(s) are the intended stable-release controls (deletion/non-fast-forward protection, required review/check/thread handling, and no routine bypass), not merely any rule that causes GitHub to set the protected flag.

Context Fabric revalidation criterion after that policy-content confirmation is unchanged: dependency-first integration, one unchanged promoted protected main SHA, then fresh exact-SHA CI/package/SBOM/provenance/independent-review evidence before tag/release. The separate counted independent-reviewer eligibility blocker remains #772.

Fresh Context Fabric revalidation on 2026-08-21 changes the first acceptance fact: context-graph-contracts/main@99cb5468ba3c15c5e79688f53dee74724fae2d13 now reports protected=true. The same branch payload still reports legacy branch protection enabled=false with no legacy required-status contexts, so the protection is consistent with a ruleset but this task's repository-scoped GitHub interface cannot retrieve the live ruleset definition itself.

Do not treat the boolean protected flag alone as release authorization. The central governance owner should now verify the effective ruleset targeting stable main and record the exact rules/ruleset identity showing at minimum: deletion and non-fast-forward protection; required review/check/thread policy appropriate to release promotion; no routine bypass path; and continued separation of protected develop integration from protected main release promotion. If that effective-policy evidence is confirmed, the original protected=false defect is resolved and #1137 can move to the post-integration acceptance phase rather than branch-protection provisioning.

Context Fabric-side revalidation criterion remains unchanged: after the contract stack integrates dependency-first, one exact promoted main SHA must itself produce terminal CI/package/SBOM/provenance/attestation-verification evidence, and release/tagging remains forbidden until independent approval and all release gates refer to that same unchanged SHA.

Fresh Context Fabric owner-boundary revalidation on 2026-08-21 KST shows a substantive state change from the earlier evidence in this issue: both stable release refs now report protected=true while retaining the same commit identities.

ContextualWisdomLab/context-graph-contracts/main@99cb5468ba3c15c5e79688f53dee74724fae2d13: protected=true; the branch response still exposes legacy protection.enabled=false / no legacy required-status contexts, so protection is evidently coming from a ruleset or other non-legacy policy path.
ContextualWisdomLab/enterprise-architecture-core/main@ca6889497728e1a3f09d68790a9096576e13a3ff: protected=true; likewise legacy protection.enabled=false.

This clears the old binary protected=false defect, but it is not yet sufficient release authorization because the Context Fabric writer cannot inspect the effective ruleset payload through the available repository interface. Central governance should now verify and record that the rules actually attached to both main refs implement the intended stable-release controls: deletion/non-fast-forward protection, required exact-head checks/reviews and unresolved-thread handling as applicable, and no routine bypass. Keep develop as the default/integration branch.

GREEN revalidation criterion from Context Fabric is therefore narrowed: central owner evidence must identify the effective ruleset(s) and prove the required stable-release controls apply to these two exact refs; then, only after dependency-first integration and counted independent review, promote one unchanged integrated SHA to protected main and require fresh CI/package/SBOM/provenance/attestation verification before tag/release. No direct unreviewed promotion, bypass, or inference from the branch flag alone.

Fresh Context Fabric release-governance revalidation on 2026-08-21 now shows a material owner-side state change that supersedes the latest protected=false evidence in this issue.

ContextualWisdomLab/context-graph-contracts/main@99cb5468ba3c15c5e79688f53dee74724fae2d13 now reports protected=true; protected default/integration develop@99cb5468ba3c15c5e79688f53dee74724fae2d13 remains protected=true.
ContextualWisdomLab/enterprise-architecture-core/main@ca6889497728e1a3f09d68790a9096576e13a3ff now reports protected=true; protected default/integration develop@1c0fa8b15ceb9e72186274aeb255d6777eb84ef4 remains protected=true.
For both main branch responses the legacy protection.enabled payload remains false, so the protected flag appears to be supplied by a ruleset rather than legacy branch protection. Context Fabric cannot infer release-grade policy from the flag alone.

This closes the earlier branch-flag RED condition but not yet the full release-governance acceptance criterion. Central owner should now verify the attached live ruleset semantics for both stable main refs: deletion and non-fast-forward protection, required current-head checks/reviews appropriate to promotion, review-thread handling/stale-review behavior, and no routine bypass. If those controls are confirmed, record that evidence here; Context Fabric will then treat stable-branch policy as satisfied while still requiring dependency-first integration, counted independent approval from #772, exact protected-main CI/package/SBOM/provenance evidence, and unchanged-SHA release/tag verification. No release or bypass was attempted.

Fresh Context Fabric branch revalidation on 2026-08-21 KST supersedes the most recent context-graph-contracts/main protection observation in this issue: ContextualWisdomLab/context-graph-contracts/main@99cb5468ba3c15c5e79688f53dee74724fae2d13 now reports protected=true, while default/integration develop@99cb5468ba3c15c5e79688f53dee74724fae2d13 also remains protected=true. Legacy branch-protection payloads still report enabled=false, so the protection flag appears ruleset-derived rather than evidence that the intended release-grade rule set has been fully verified.

This closes the earlier branch-flag RED for Context Graph but not release authorization. The remaining owner-side acceptance is to inspect the effective rule(s) applying to stable main and prove deletion/non-fast-forward protection, unresolved-thread handling, exact-current-head checks/reviews appropriate to release promotion, and no routine bypass. Context Fabric will continue to refuse tag/release promotion based on protected=true alone. After dependency-first integration, release evidence must still be regenerated on one unchanged protected main SHA.

No repository source, default branch, review requirement, or bypass was changed from the Context Fabric writer.

Fresh Context Fabric branch revalidation now contradicts the earlier protected=true evidence and shows the contract stable branch has regressed to unprotected. Two consecutive direct GitHub branch reads in this run report ContextualWisdomLab/context-graph-contracts/main@99cb5468ba3c15c5e79688f53dee74724fae2d13 as protected:false, with legacy protection.enabled:false and no legacy required-status contexts. develop@99cb5468ba3c15c5e79688f53dee74724fae2d13 remains protected:true.

Treat the earlier protected=true observations as transient/superseded, not release authorization. First failing release-governance boundary is again the stable main ref itself: before any immutable contract promotion/tag, restore the intended stable-release ruleset to context-graph-contracts/main while preserving develop as default/integration, then re-fetch the branch twice and record the effective ruleset semantics (deletion/non-fast-forward protection, exact-head required checks/reviews/thread handling, stale-review behavior, no routine bypass). Context Fabric will not use direct/unreviewed main mutation or infer policy from predecessor branch-state evidence.

This is independent of #772 counted-review provisioning; both must be satisfied on the then-current exact refs before release.

Fresh live regression evidence on 2026-08-21 supersedes the earlier transient protected:true observation for the Context Graph stable branch:

context-graph-contracts still reports default branch develop.
develop@99cb5468ba3c15c5e79688f53dee74724fae2d13: protected=true.
main@99cb5468ba3c15c5e79688f53dee74724fae2d13: protected=false; legacy protection payload remains enabled=false with no required status contexts.

This means stable-release governance is currently fail-closed again: do not tag, publish, attest, or promote an immutable cwl-context-contracts release from main until the central ruleset owner restores and verifies effective release-grade protection on that branch while preserving develop as the Git Flow default/integration branch.

Smallest required remedy/acceptance remains: attach the intended effective ruleset to main; prove deletion and non-fast-forward protection, required exact-head checks/reviews, unresolved-thread handling, stale/latest-push review semantics where configured, and no routine bypass; then refetch main and verify protected=true plus the effective rule behavior before any release operation. Context Fabric will not treat a prior/transient protection flag as current evidence.

Fresh Context Fabric revalidation on 2026-08-21: ContextualWisdomLab/context-graph-contracts still uses develop as the default integration branch. Direct branch reads now report both develop@99cb5468ba3c15c5e79688f53dee74724fae2d13 and stable main@99cb5468ba3c15c5e79688f53dee74724fae2d13 as protected:true; the legacy branch-protection payload remains enabled:false with no legacy required-status contexts, so the protection is consistent with a ruleset rather than legacy branch protection. This supersedes the issue body's older main protected=false snapshot.

The remaining falsifiable owner-side acceptance is narrower: inspect the effective ruleset actually covering main and prove it supplies the intended release controls (deletion and non-fast-forward protection, unresolved-thread handling, exact-current-head required checks/reviews appropriate to release promotion, and no routine bypass) while develop remains default. Context Fabric will not infer release authorization from the branch boolean alone, and will not tag/release until one exact promoted protected-main SHA satisfies all repository/package/SBOM/provenance/review/rollback gates together.

Fresh release-governance revalidation on 2026-08-21 still fails closed at the stable branch:

ContextualWisdomLab/context-graph-contracts default/integration branch is develop@99cb5468ba3c15c5e79688f53dee74724fae2d13 and GitHub reports protected=true.
Stable release branch main@99cb5468ba3c15c5e79688f53dee74724fae2d13 still reports protected=false; legacy protection is also enabled=false.
The active release-attestation stack intentionally restricts protected-main attestation to refs/heads/main, so a release/tag/promotion from this branch cannot yet satisfy the repository's own protected-source release invariant.

Minimal central remedy is unchanged: preserve develop as the default integration branch and attach the intended release-grade ruleset to main, then verify deletion/non-fast-forward protection, unresolved-thread handling, exact-current-head checks/reviews, stale/latest-push behavior, and no routine bypass. Context Fabric will revalidate the exact promoted main SHA and its package/SBOM/provenance evidence after dependency-first integration; it will not treat the current unprotected branch as release-authorized.

Fresh Context Fabric release-governance revalidation — 2026-08-22 KST

Direct branch reads now prove the stable-release branch is unprotected in both owned Context Fabric repositories while each Git Flow integration branch remains protected:

ContextualWisdomLab/context-graph-contracts: develop@99cb5468ba3c15c5e79688f53dee74724fae2d13 reports protected=true; main@99cb5468ba3c15c5e79688f53dee74724fae2d13 reports protected=false, legacy protection enabled=false.
ContextualWisdomLab/enterprise-architecture-core: develop@1c0fa8b15ceb9e72186274aeb255d6777eb84ef4 reports protected=true; main@ca6889497728e1a3f09d68790a9096576e13a3ff reports protected=false, legacy protection enabled=false.

This extends the existing owner-boundary acceptance rather than changing product policy: preserve develop as default/integration, but apply and verify the intended release-grade stable-main ruleset on both repositories before any immutable release/promotion is treated as authorized evidence. Revalidate deletion/non-fast-forward protection, unresolved-thread handling, exact-current-head checks/reviews, and no routine bypass. A protected boolean alone is not sufficient if the effective ruleset cannot be shown.

No branch/ruleset mutation, bypass, tag, release, or self-approval was attempted from the Context Fabric writer. After central remediation, Context Fabric will refetch both exact branch tips/effective policy and require fresh protected-main CI/package/SBOM/provenance/review evidence before release.

Fresh release-governance revalidation — 2026-08-22 KST.

The release-grade stable-branch boundary remains unsatisfied on both Context Fabric repositories while their Git Flow defaults remain protected:

ContextualWisdomLab/context-graph-contracts/develop@99cb5468ba3c15c5e79688f53dee74724fae2d13: protected=true; stable main@99cb5468ba3c15c5e79688f53dee74724fae2d13: protected=false, legacy protection enabled=false.
ContextualWisdomLab/enterprise-architecture-core/develop@1c0fa8b15ceb9e72186274aeb255d6777eb84ef4: protected=true; stable main@ca6889497728e1a3f09d68790a9096576e13a3ff: protected=false, legacy protection enabled=false.

This is a central ruleset/policy boundary, not a reason to weaken repository release evidence. Smallest owner remedy: preserve develop as each protected default/integration branch and attach the intended release-grade ruleset to both stable main refs. GREEN proof must demonstrate effective deletion/non-fast-forward protection, unresolved-thread handling, exact-current-head required checks/reviews appropriate to release promotion, and no routine bypass. After any Context Fabric stack integration, release/tag/provenance evidence must be regenerated on one exact protected main SHA; PR/develop/predecessor evidence is non-transferable.

Context Fabric owner-plane dependency refresh, 2026-09-07 KST: the CodeQL prerequisite now has a concrete canonical source owner, .github#1902@4b025af481f3a4fb0bdb4d400a7e055066a496a2 on protected .github/main@c9052e607e5f3cc76e73207e7786b21500721b79. Its first missing-verdict and stale-base defects are repaired, but hosted canaries exposed a still-open two-language exact-job wake race: both native scan shards can publish terminal receipts, the first wakes the required run, and the second can receive HTTP 403 because that run is already executing. #1902 remains Draft/fail-closed while it repairs deterministic settlement; treating the 403 as success or using an unbound run-wide rerun is explicitly rejected.

I bound #1902's post-integration canary to the unchanged consumers currently blocking this migration: .github#1644@5f5d7a9e849984c052c72a08eba34f68cb694024 and context-graph-contracts#4@5117383ac15cdfe3813340455cd99b92937ef47c, both of which have actions + python CodeQL compatibility jobs that reached the missing authenticated-terminal-verdict boundary on attempt 2. After #1902 is integrated, both unchanged heads must obtain per-language authenticated terminal receipts and semantically terminal exact required jobs before #1644 may be represented as CodeQL-GREEN.

Fresh product settings remain RED in parallel: CGC still default_branch=develop, develop@99cb5468ba3c15c5e79688f53dee74724fae2d13 protected and byte-identical main@99cb5468... unprotected; EA still default_branch=develop, protected develop@dd71e40a86385fb7861b0f1be19891a3f3e29ece, with product main@ca6889497728e1a3f09d68790a9096576e13a3ff not yet the default integration authority. Effective inherited ruleset 18156473 is still active on ~DEFAULT_BRANCH, still has bare required_approving_review_count=1, no named/CODEOWNER/last-push reviewer, required thread/workflows/deletion/non-fast-forward gates, and routine OrganizationAdmin/always bypass.

Owner order is therefore now explicit: finish #1902 exact-bound multi-language settlement -> reacquire #1644 CodeQL and all exact-head gates -> ordinary protected integration of #1644 -> separately credentialed live #772 ruleset reconciliation -> protect CGC/EA main first -> switch defaults -> reread ~DEFAULT_BRANCH -> only then reconstruct product stacks non-force. No leaf retarget/restack is authorized before that control plane converges.

Fresh Context Fabric owner-plane supersession, 2026-09-07 KST. Revalidated before any product ref/base mutation.

Protected central .github/main has advanced to 78a4937c684a54ca8e415822c913742f41c6efc4 (fix(codeql): accept queued pre-cutover scan-dispatch payloads #2009). Both owner-source PRs are now stale against that protected tip: fix(codeql): recover reruns after missing dispatch verdict #1902 remains Draft at 4b025af481f3a4fb0bdb4d400a7e055066a496a2 with recorded base c9052e607e5f3cc76e73207e7786b21500721b79; fix(governance): automate ruleset owner-plane reconciliation #1644 remains Draft at 5f5d7a9e849984c052c72a08eba34f68cb694024 with the same recorded base. Their predecessor hosted evidence therefore cannot be treated as current after required non-force protected-main adoption.
Product control-plane state remains pre-migration: both Context Fabric repositories still report default_branch=develop; CGC develop@99cb5468ba3c15c5e79688f53dee74724fae2d13 is protected while byte-identical main@99cb5468... is unprotected. Effective inherited ruleset 18156473 still follows ~DEFAULT_BRANCH with the bare solo-impossible approval count tracked by [Governance] Make protected-PR review policy solo-maintainer compatible without weakening deterministic gates #772. Do not retarget product stacks yet.
CGC Context Assertion 🧪 [testing improvement] iter_json_objects 함수에 대한 단위 테스트 추가 #21 is still Draft exact 26ab77428a723e825bfd54a7b6fc26e7a65c787c with no exact-head workflow materialization. EA ⚡ Bolt: JSON 파싱 성능 최적화 #40 has advanced by three ordinary fast-forward commits to ac4b7d0c015f0ef261047b63b762e88124fede60: it now test-first requires the CGC context-assertion-message-admission:v1 conformance profile and packaged resource in both the dependency manifest and immutable-release verifier, closing a consumer-side false-release gap. EA exact-head Actions are still empty, so no hosted GREEN is claimed.

Causal owner order remains: non-force adopt current protected .github/main@78a4937... into the canonical #1902 settlement repair and reacquire exact-head terminal gates -> non-force adopt current protected main into #1644 and reacquire its exact-head gates -> ordinary protected integration when live policy permits -> separately credentialed #772 ruleset reconciliation -> protect CGC/EA main first and prove effective protection -> switch defaults to main -> reread ~DEFAULT_BRANCH -> hand fresh protected refs back for dependency-root-first non-force product reconstruction with no predecessor evidence transfer. This remains an actionable central owner-plane sequence, not a product-source or user-decision blocker.

Fresh Context Fabric causal evidence for the accepted default-branch migration (2026-09-07 KST): the current develop default is not merely pointing ~DEFAULT_BRANCH at the wrong governance target; it also prevents the repository PR workflows from materializing because the workflow definitions are absent from that default line.

CGC remains default_branch=develop, develop@99cb5468ba3c15c5e79688f53dee74724fae2d13 protected, byte-identical main@99cb5468... unprotected. .github/workflows/ci.yml is 404 on develop, while the stacked base and current #21@aae092056eef8f28c287b23437c05d88ecede98d contain on: pull_request; the exact head has zero workflow runs.
EA remains default_branch=develop; .github/workflows/ci.yml is also 404 on develop. Current #40@9a26898d07bb4746d3896f2199b9e6972a3d6ed8 has zero exact-head workflow runs despite candidate workflow definitions and explicit exact-source checkout.

This strengthens #1137's existing execution order rather than changing it: protect main first to the intended deterministic integration/release policy; prove protection; switch default to main; re-read inherited ~DEFAULT_BRANCH; then reconstruct dependency roots/descendants non-force and reacquire exact-head workflows. Copying candidate workflows backward into obsolete develop solely to make these Draft descendants run would prolong the superseded topology and is not the causal remedy.

Fresh Context Fabric owner handoff (2026-09-08 KST): both repositories still report default_branch=develop. CGC remains protected develop@99cb5468ba3c15c5e79688f53dee74724fae2d13 with byte-identical unprotected main@99cb5468ba3c15c5e79688f53dee74724fae2d13; EA remains protected/default develop@dd71e40a86385fb7861b0f1be19891a3f3e29ece while product main@ca6889497728e1a3f09d68790a9096576e13a3ff has not become protected/default authority. Organization ruleset 18156473 still follows ~DEFAULT_BRANCH with bare approving-review count 1 and routine OrganizationAdmin/always bypass. Product roots remain Draft and non-passing under this topology: CGC #4 exact 5117383ac15cdfe3813340455cd99b92937ef47c; EA integration root #21 exact 7231e58cd10d55c936ca08fb4f806af2a23bf247; fresh repository Actions for EA #21 are empty. Please execute the already accepted owner sequence only: protect main first to the intended deterministic integration/release standard, preserve transition develop protection as needed, switch default to main, reread effective ~DEFAULT_BRANCH rules, and coordinate #772's removal/replacement of only the structurally impossible bare solo approval count/routine bypass without weakening required checks/security/coverage/package/SBOM/provenance/thread/deletion/non-fast-forward controls. Product writers will rebuild stacks from fresh protected main and reacquire exact-head evidence after this owner-plane change; no predecessor evidence transfers.

Fresh Context Fabric owner handoff after an EA-owned causal repair; revalidate before central mutation.

context-graph-contracts still reports default_branch=develop; develop@99cb5468ba3c15c5e79688f53dee74724fae2d13 remains protected and byte-identical main@99cb5468ba3c15c5e79688f53dee74724fae2d13 remains outside the intended protected/default-main state. Current CGC Context Assertion 🧪 [testing improvement] iter_json_objects 함수에 대한 단위 테스트 추가 #21 is Draft at exact 29af389e764758b7d5b33b04bb0b8ca1f64d5317; fresh exact-head PR Actions lookup is empty.
enterprise-architecture-core still reports default_branch=develop; protected develop@dd71e40a86385fb7861b0f1be19891a3f3e29ece and integration candidate main@ca6889497728e1a3f09d68790a9096576e13a3ff are unchanged from the current topology. EA ⚡ Bolt: JSON 파싱 성능 최적화 #40 advanced linearly/non-force to exact 1ff2a40bb7bea79b81339d12c74a96d5def6875f after repairing an internal Context Assertion receipt-contract RED: the production connector validator already required message_profile_id/message_profile_version, while all ten checked-in context_assertion_cloudevent connector receipts omitted them. The commit adds only those two semantics to those ten receipts; hosted exact-head evidence is not transferred or claimed.
Repository-scoped live reads still resolve organization ruleset 18156473 on ~DEFAULT_BRANCH with required_approving_review_count=1, required_reviewers=[], require_code_owner_review=false, require_last_push_approval=false, required thread resolution/workflows/deletion/non-fast-forward controls, and OrganizationAdmin/always bypass. [Governance] Make protected-PR review policy solo-maintainer compatible without weakening deterministic gates #772 therefore remains RED.

The central owner sequence remains the accepted causal path: converge the live central governance implementation on protected .github/main without force -> obtain its exact-head deterministic gates -> repair the impossible bare approval count/routine bypass centrally -> protect each Context Fabric main first -> switch default to main -> reread effective ~DEFAULT_BRANCH rules -> hand fresh refs back for dependency-root-first non-force stack reconstruction and new evidence acquisition. Do not copy workflows back to develop, retarget product PRs onto unprotected main, or transfer predecessor checks/reviews.

Fresh Context Fabric owner revalidation (2026-09-08 KST) confirms the migration is still at the pre-protect-main step; no product ref/base mutation is safe yet.

Live repository truth:

context-graph-contracts: default_branch=develop; develop@99cb5468ba3c15c5e79688f53dee74724fae2d13 reports protected=true; byte-identical main@99cb5468ba3c15c5e79688f53dee74724fae2d13 reports protected=false.
enterprise-architecture-core: default_branch=develop; develop@dd71e40a86385fb7861b0f1be19891a3f3e29ece reports protected=true; product main@ca6889497728e1a3f09d68790a9096576e13a3ff remains outside default-branch authority.
Effective inherited ruleset 18156473 remains active on ~DEFAULT_BRANCH with required_approving_review_count=1, required_reviewers=[], CODEOWNER/last-push approval disabled, required thread resolution + central workflows + deletion/non-fast-forward, and OrganizationAdmin/always bypass. It therefore still follows develop in both product repositories.

Current exact product evidence is still fail-closed: CGC root #4@5117383ac15cdfe3813340455cd99b92937ef47c has SAST success but CodeQL and Security Scan failures; CGC Context Assertion #21@49318782cfe3dffdc78fbcd2bb8e3ee0860d9329 has zero exact-head PR workflow runs. EA dependency root #21@7231e58cd10d55c936ca08fb4f806af2a23bf247 likewise has zero exact-head PR workflow runs. EA #31@9da48e30f9fc60c0999928df84343834be402492 remains stale and its historical three repository workflows were cancelled pre-step; no checkout evidence transfers.

EA Context Fabric #40 has advanced linearly/non-force to exact 06ded6a1d6febab9cd85d0716ddcfadd9f8d30a6. It test-first closes a consumer false-release gap by requiring the installed CGC ContextAssertionAdmission.schema_version == 1 in addition to the exact event-profile/message-profile/admission identities, and hardens the focused doubles so message-profile regressions isolate their intended field plus a compatible positive receipt path. Fresh provider source confirms CGC exposes immutable schema_version = 1. Exact-head EA #40 Actions remain absent, so no hosted GREEN is claimed and this source progress does not alter migration order.

The central source prerequisite itself needs ordinary non-force reconciliation before owner-plane apply: protected .github/main is now 78a4937c684a54ca8e415822c913742f41c6efc4, while canonical CodeQL settlement #1902@4b025af481f3a4fb0bdb4d400a7e055066a496a2 and ruleset reconciler #1644@5f5d7a9e849984c052c72a08eba34f68cb694024 still record base c9052e607e5f3cc76e73207e7786b21500721b79. #1902 remains Draft with the exact two-language settlement race unresolved; #1644 remains Draft and explicitly requires protected-source integration before its separately credentialed Administration-write apply path may run.

Owner order remains: central owner non-force adopts current protected .github/main into the canonical settlement/reconciler lanes and reacquires exact-head gates -> integrate the reconciler through ordinary protected governance -> execute the separately credentialed ruleset convergence from protected truth -> protect CGC/EA main first and prove effective protection -> switch defaults to main -> reread ~DEFAULT_BRANCH -> hand fresh protected refs back for dependency-root-first non-force reconstruction. Do not copy workflows backward into obsolete develop, retarget product stacks to unprotected main, or transfer predecessor evidence.

Fresh branch-topology proof for the EA migration: enterprise-architecture-core still defaults to protected develop@dd71e40a86385fb7861b0f1be19891a3f3e29ece, while unprotected main@ca6889497728e1a3f09d68790a9096576e13a3ff contains the actual merged product foundation/history. main...develop is diverged (develop ahead 2, behind 1; merge-base 1c0fa8b15ceb9e72186274aeb255d6777eb84ef4). Critically, comparing that merge-base to develop reports two commits but zero changed files: 266b1285... introduced an accidental empty path and dd71e40... reverted it. Therefore there is no substantive develop-only product delta to preserve or merge into main. This strengthens the accepted causal sequence: protect current main first, switch default to main, re-read ~DEFAULT_BRANCH, then rebuild open PR bases/stacks from fresh heads. Do not merge the net-zero develop history into main merely to manufacture ancestry, and do not transfer predecessor gate evidence.

Fresh Context Fabric owner handoff after an EA-owned DDD repair. Product control-plane state is still pre-migration: both repositories still default to develop; CGC main@99cb5468ba3c15c5e79688f53dee74724fae2d13 remains unprotected and EA protected inventory still contains only develop@dd71e40a86385fb7861b0f1be19891a3f3e29ece, while product main@ca6889497728e1a3f09d68790a9096576e13a3ff is outside default-branch authority. Effective organization ruleset 18156473 still follows ~DEFAULT_BRANCH with the bare solo-impossible approval count and routine admin bypass tracked by #772.

The product writer did not work around that control plane. It instead repaired an independent EA ownership defect on Draft enterprise-architecture-core#40, now exact 08879d2ddbe56b5f7f8039b7fd82b3aecc30586e: the existing hostile connector-contract RED mutates Quarantine Sandbox Runtime ea_core_owns to true, but the production quarantine validator previously failed to reject that false ownership claim. The exact current commit adds only the four-line fail-closed ea_core_owns is False invariant. Fresh exact-head EA Actions are still absent, so no hosted GREEN transfers or is claimed.

Fresh provider anchors remain CGC root #4@421d50e17102a68de616d71559d8b90cb3aa372f and Context Assertion #21@49318782cfe3dffdc78fbcd2bb8e3ee0860d9329. Central source remains stale against protected .github/main@78a4937c684a54ca8e415822c913742f41c6efc4: #1902@4b025af481f3a4fb0bdb4d400a7e055066a496a2 and #1644@5f5d7a9e849984c052c72a08eba34f68cb694024 still record base c9052e607e5f3cc76e73207e7786b21500721b79. The causal owner order is unchanged: non-force reconcile those central owner lanes to protected truth and reacquire gates -> integrate the reconciler -> execute privileged #772 convergence -> protect both product main refs first -> switch defaults -> reread ~DEFAULT_BRANCH -> return fresh refs for dependency-root-first non-force product reconstruction. No product retarget, bypass, or predecessor evidence transfer is authorized before that convergence.

Fresh protect-main migration evidence, 2026-09-08 KST, re-read from both Context Fabric repositories and the effective inherited ruleset:

context-graph-contracts: default_branch=develop; protected develop@99cb5468ba3c15c5e79688f53dee74724fae2d13; unprotected byte-identical main@99cb5468ba3c15c5e79688f53dee74724fae2d13.
enterprise-architecture-core: default_branch=develop; protected develop@dd71e40a86385fb7861b0f1be19891a3f3e29ece; unprotected main@ca6889497728e1a3f09d68790a9096576e13a3ff.
Effective inherited organization ruleset 18156473 is still active on ~DEFAULT_BRANCH with required_approving_review_count=1, required_reviewers=[], code-owner/last-push approval disabled, thread resolution and required central workflows retained, deletion/non-fast-forward protection retained, and routine OrganizationAdmin/always bypass still present.
Current owner-plane implementation remains .github#1644@5f5d7a9e849984c052c72a08eba34f68cb694024, Draft against protected .github/main@c9052e607e5f3cc76e73207e7786b21500721b79; its source models approval count 0 and removal of routine bypass while preserving deterministic controls, but its current exact-head central gates are not clean and privileged live apply remains disabled.

The required sequence therefore remains unchanged and actionable: land the owner-plane repair through its own deterministic gates, protect each product main before changing default, then switch default to main, re-read effective ~DEFAULT_BRANCH, and only afterward non-force rebuild the CGC/EA stacks from fresh protected integration truth. Do not retarget current product PRs to unprotected main or treat their historical evidence as transferable.

Context Fabric owner-path refresh — fresh direct state on 2026-09-08 KST, superseding stale comments that still describe develop as the intended long-term target.

context-graph-contracts: repository default remains develop; develop@99cb5468ba3c15c5e79688f53dee74724fae2d13 is protected, while byte-identical main@99cb5468ba3c15c5e79688f53dee74724fae2d13 is still unprotected.
enterprise-architecture-core: repository default remains develop; develop@dd71e40a86385fb7861b0f1be19891a3f3e29ece is protected, while main@ca6889497728e1a3f09d68790a9096576e13a3ff is still unprotected.
In both repositories inherited organization ruleset 18156473 remains active on ~DEFAULT_BRANCH, with bare required_approving_review_count=1, required_reviewers=[], require_code_owner_review=false, require_last_push_approval=false, required review-thread resolution, deletion/non-fast-forward protection, central required workflows, and an OrganizationAdmin/always bypass actor. This remains the structurally impossible solo-maintainer rule tracked by [Governance] Make protected-PR review policy solo-maintainer compatible without weakening deterministic gates #772; it must not be satisfied by self/model approval or synthetic reviewers.
The live ruleset owner PR remains .github#1644@e35cdc5d6527dfa8634654719a6c3681f16ed82a on protected .github/main@7fd571dbcdbae6acf29d8f4ee704d7ba6297e4db. Ruleset Governance Reconcile 34183081305, SAST 34183081262, CodeQL 34183081272, Python Security 34183081259, and Security Scan 34183081206 are all terminal success on that unchanged exact head. The PR remains Draft and live repository/ruleset settings have not converged; predecessor evidence does not transfer.
Current product candidates remain fail closed: CGC Context Assertion #21@b3558f993dd84604aa2bcb9c94be630af15db53d and EA Context Fabric/quarantine #40@77a4b740eb07765385aa56a59392c37a4873c341 each still have zero exact-head workflow runs. EA ⚡ Bolt: JSON 파싱 성능 최적화 #40 advanced non-force through a test-first fail-closed connector-direction repair; the new head therefore requires fresh execution and no 1daf5912... evidence transfers. This is materialization/control-plane evidence, not a passing lane and not a reason for no-op source churn.

Owner acceptance remains unchanged and is the next causal control-plane action: land the owner-plane repair through its protected deterministic path; protect each product main to the intended integration/release standard before changing defaults; apply the #772 solo-maintainer-compatible review rule without weakening deterministic/security/thread/deletion/non-fast-forward gates; switch each repository default to main; re-read effective ~DEFAULT_BRANCH; then rebuild CGC/EA stacks non-force from fresh protected heads and reacquire exact-head evidence. Do not retarget current product PRs to unprotected main, transfer historical checks/reviews, or use routine admin bypass.

Fresh owner-path revalidation materially advances the source side of this transition. Central PR #1644 remains Draft/mergeable at exact e35cdc5d6527dfa8634654719a6c3681f16ed82a over unchanged protected main@7fd571dbcdbae6acf29d8f4ee704d7ba6297e4db. Its exact-head Actions inventory is now 10/10 completed; fresh outcome inspection finds no failure, cancelled, skipped, neutral, timed_out, action_required, startup_failure, stale, null, queued, or in_progress conclusion/status. Named exact-head lanes include Ruleset Governance Reconcile, CodeQL PR, SAST Semgrep, Python Security, Security Scan, and Required PR Review Merge Scheduler as success. Fresh review-thread inventory is fully resolved; reviews remain COMMENT-only, so no human approval is invented or transferred.

This removes hosted-check waiting as the source-lane reason to leave the accepted protect-main/default-main/ruleset repair dormant. The remaining owner sequence is still the accepted one: advance #1644 through the ordinary protected source path under its live policy, then expose/use the separately provisioned least-privilege Administration-write environment to protect CGC/EA main first, switch defaults, reread effective ~DEFAULT_BRANCH, and apply #772's solo-maintainer canonicalization without weakening deterministic gates. Current CGC evidence continues to prove the practical impact: both live integration refs omit repository workflows while its active exact PR head contains them, so leaf no-op retriggers are not a causal repair.

Context Fabric fresh control-plane read (2026-09-08): EA still has protected/default develop@dd71e40a86385fb7861b0f1be19891a3f3e29ece and unprotected/non-default intended main@ca6889497728e1a3f09d68790a9096576e13a3ff. Organization ruleset 18156473 is still active on ~DEFAULT_BRANCH with bare required_approving_review_count=1, required_reviewers=[], require_code_owner_review=false, require_last_push_approval=false, thread resolution + required central workflows + deletion/non-fast-forward retained, and OrganizationAdmin/always bypass. CGC likewise remains default develop with intended main not made the integration authority. Meanwhile central owner PR .github#1644@e35cdc5d6527dfa8634654719a6c3681f16ed82a now has its current Ruleset Governance Reconcile, CodeQL PR, SAST Semgrep, Python Security and Security Scan runs all terminal SUCCESS. Source validation is therefore no longer the missing evidence; live protect-main/default-switch/effective-ruleset reconciliation is still the causal owner-plane action. New EA exact head #40@b64d64b5a5179d24079dda1467cd418fe6fbb3bd remains a zero-materialization PR lane until that control plane converges. Preserve the accepted sequence: protect main first, retain develop only for transition safety, switch default, re-read ~DEFAULT_BRANCH, then rebuild stacks from fresh heads without transferring predecessor evidence.

Fresh Context Fabric owner handoff after an EA-owned contract repair (2026-09-08 KST): enterprise-architecture-core#40 is now exact f6542cbcf4bd933a002e33af8d8dd15b3652c0f5, non-force over unchanged parent #39@cd2a2471a53e34c5442aaf7194fb0a74df23b732. The repair restores the fail-closed caller-scoped quarantine application-service session-lifecycle invariant already required by the hostile connector contract. The new exact head still materializes zero repository PR workflows, so no predecessor evidence is transferred. Live governance itself is unchanged: EA remains default/protected develop@dd71e40a86385fb7861b0f1be19891a3f3e29ece with unprotected main@ca6889497728e1a3f09d68790a9096576e13a3ff; CGC remains default/protected develop@99cb5468ba3c15c5e79688f53dee74724fae2d13 with unprotected byte-identical main; inherited ruleset 18156473 still follows ~DEFAULT_BRANCH with bare approval count 1 and routine OrganizationAdmin bypass. Keep the accepted owner sequence: land/apply the central reconciler through its protected path, protect both product main refs first, switch defaults, reread effective rules, then return fresh refs for dependency-root-first non-force stack reconstruction and exact-head gate reacquisition.

Context Fabric owner-plane refresh — source-side governance reconciler is now exact-head GREEN, while live repository settings remain unchanged.

Fresh central owner PR: .github#1644@e35cdc5d6527dfa8634654719a6c3681f16ed82a, base protected .github/main@7fd571dbcdbae6acf29d8f4ee704d7ba6297e4db, still Draft. Exact-head runs are all terminal success: CodeQL PR 34183081272, SAST Semgrep 34183081262, Python Security 34183081259, Security Scan 34183081206, and Ruleset Governance Reconcile 34183081305. This supersedes the earlier queued receipt in the PR body; no predecessor evidence is transferred.

Fresh product topology is still RED and unchanged: CGC default_branch=develop, protected develop@99cb5468ba3c15c5e79688f53dee74724fae2d13, unprotected byte-identical main@99cb5468ba3c15c5e79688f53dee74724fae2d13; EA default_branch=develop, protected develop@dd71e40a86385fb7861b0f1be19891a3f3e29ece, unprotected product main@ca6889497728e1a3f09d68790a9096576e13a3ff. Effective org ruleset 18156473 still follows ~DEFAULT_BRANCH with bare required_approving_review_count=1, no named/code-owner/last-push reviewer, and routine OrganizationAdmin/always bypass.

The next owner action is no longer another source-side reconciler repair. Preserve the accepted sequence: ordinary protected integration of #1644 through its own live governance, then expose the separately provisioned least-privilege Administration-write maintenance environment and perform protect-main-first -> verify effective protection -> switch default to main -> re-read ~DEFAULT_BRANCH -> eliminate only the impossible generic approval/routine-bypass defect while preserving deterministic workflows/security/thread/deletion/non-fast-forward controls. Current GitHub App surface used by product writers can read these settings but cannot mutate repository default/protection or organization rulesets, so do not request leaf no-op commits as a substitute.

Wardnet read-only dependency sweep, 2026-09-11 KST: branch-topology RED remains exact and unchanged. context-graph-contracts still reports protected/default develop@99cb5468ba3c15c5e79688f53dee74724fae2d13; enterprise-architecture-core still reports protected/default develop@dd71e40a86385fb7861b0f1be19891a3f3e29ece. Fresh GitHub Release inventories for both repositories are empty. Current CGC and EA open stacks continue to describe protected main as the intended integration authority, so ~DEFAULT_BRANCH still follows the obsolete develop metadata until this owner-plane repair executes.

GREEN acceptance remains the existing issue contract: pre-protect main first, switch default only after effective protection is proven, re-read ~DEFAULT_BRANCH rules, then rebuild/restack product stacks dependency-first and reacquire exact-head gates. No Wardnet source/PR-state mutation, mutable foreign-head dependency, or routine bypass was performed.

Navigation Menu

Repository navigation

[Context Fabric governance] Protect and adopt main as the integration/default branch #1137

Current accepted topology

context-graph-contracts

enterprise-architecture-core

Required safe transition

Interaction with solo-maintainer review governance

RED acceptance

GREEN acceptance

Non-goals

Fresh Context Fabric release-governance revalidation — 2026-08-22 KST

99 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Context Fabric governance] Protect and adopt main as the integration/default branch #1137

Description

Current accepted topology

context-graph-contracts

enterprise-architecture-core

Required safe transition

Interaction with solo-maintainer review governance

RED acceptance

GREEN acceptance

Non-goals

Activity

seonghobae commented on Aug 19, 2026

seonghobae commented on Aug 19, 2026

seonghobae commented on Aug 19, 2026

seonghobae commented on Aug 20, 2026

seonghobae commented on Aug 20, 2026

seonghobae commented on Aug 20, 2026

seonghobae commented on Aug 20, 2026

seonghobae commented on Aug 21, 2026

seonghobae commented on Aug 21, 2026

seonghobae commented on Aug 21, 2026

seonghobae commented on Aug 21, 2026

seonghobae commented on Aug 21, 2026

seonghobae commented on Aug 21, 2026

seonghobae commented on Aug 21, 2026

Fresh Context Fabric release-governance revalidation — 2026-08-22 KST

seonghobae commented on Aug 21, 2026

99 remaining items

seonghobae commented on Sep 7, 2026

seonghobae commented on Sep 7, 2026

seonghobae commented on Sep 7, 2026

seonghobae commented on Sep 7, 2026

seonghobae commented on Sep 7, 2026

seonghobae commented on Sep 7, 2026

seonghobae commented on Sep 7, 2026

seonghobae commented on Sep 7, 2026

seonghobae commented on Sep 7, 2026

seonghobae commented on Sep 8, 2026

seonghobae commented on Sep 8, 2026

seonghobae commented on Sep 8, 2026

seonghobae commented on Sep 8, 2026

seonghobae commented on Sep 8, 2026

seonghobae commented on Sep 10, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions