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

[seonghobae]

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:

1. 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.
2. Preserve transition protection on develop only as needed. Do not create a window where either integration candidate is unprotected while stacks are being reconstructed.
3. Change repository default branch to main only after its effective protection is proven.
4. Re-read organization/repository rulesets after the switch. Verify ~DEFAULT_BRANCH now resolves to main and that no required control silently fell away.
5. Rebuild Context Fabric stacks dependency-first from fresh protected main. No predecessor-head review/check/package/provenance evidence transfers across base/default movement.
6. Reacquire exact-head gates under the new topology. Merge through ordinary protected governance only when the unchanged candidate satisfies then-live policy.
7. 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.

[seonghobae]

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.

[seonghobae]

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.

[seonghobae]

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.

[seonghobae]

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.

[seonghobae]

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.

[seonghobae]

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.

[seonghobae]

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.

[seonghobae]

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.

[seonghobae]

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.

[seonghobae]

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.

[seonghobae]

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.

[seonghobae]

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.

[seonghobae]

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.

[seonghobae]

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.

[seonghobae]

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.