## Why While a project is syncing from GitHub, it has to stay read-only on the GitLab side. If someone could push code, create issues, or merge a merge request directly in GitLab, that change would either get silently overwritten by the next sync from GitHub or would quietly diverge from what's on GitHub, and the customer would have no way to know which copy is correct. The same logic has to stop GitLab's own legacy repository mirroring from running against a project that GitHub already owns, otherwise two systems would be fighting to write the same repository. All of this enforcement already works in the proof of concept, merge request [!251883](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/251883) (branch `feature/github-connected-project-poc`). This issue ports it into a fresh MR against `master`, using the models landed in https://gitlab.com/gitlab-org/gitlab/-/work_items/628581. ## What to do Port `Continuity::Projects::WritePolicy` as `Import::Sync::Projects::WritePolicy`. It's a small policy object with two entry points: - `read_only?(project)`, true whenever the project's `Import::Sync::Repository#authority_state` is one of `provisioning`, `provider_canonical`, `disconnected`, `cutting_over`, or `cutover_failed`. Only `bootstrap_canceled` and `gitlab_canonical` are writable. - `repository_mirroring_blocked?(project)`, true for the same set of states (exposed on the repository model as `provider_bound?`). It deliberately re-checks the database on every call instead of caching, so a state change mid-request (for example, a "stop updates" cutover finishing) is picked up immediately rather than served stale. Wire it into the places that currently block writes: - **Git push.** `check_push_access!` in `lib/gitlab/git_access.rb` already runs a `project&.repository_read_only?` check first, before the archived check (around line 392-394 on current `master`). Decided 2026-09-10: instead of adding a new, separately-named check, feed the write policy into that existing check, so the project reads as read-only when either the current column-backed check or `WritePolicy.read_only?(project)` is true. The `ForbiddenError` message differs by case: for the GitHub-sync case it tells admins to push to GitHub instead, or stop updates in project settings, with different wording for non-admins; the ordinary read-only message is unchanged. It does not touch pull/fetch. - **Issues, work items, merge requests, notes.** `app/policies/project_policy.rb` adds a `continuity_read_only` condition and reuses the entire `project:archived` permission group as its blocklist, plus a few repository-mutation abilities (`rewrite_repository_history`, branch rule create/update/delete, squash options). `app/policies/work_item_policy.rb` adds the same condition and blocks `admin_work_item_link`/`admin_parent_link`. Rename the condition to `import_sync_read_only` (or similar) and port both files. - **Merging.** `app/models/merge_request.rb#can_be_merged_by?` returns `false` outright if the target project is read-only, before the normal branch-permission check. - **Legacy mirroring.** Decided 2026-09-10: only port the guard at the worker layer and in the EE update service, not in every service that touches a mirror. `repository_mirroring_blocked?` guards `RepositoryUpdateRemoteMirrorWorker`, `EE::RepositoryUpdateMirrorWorker`, and `EE::ProjectImportScheduleWorker`, which skip their work and log rather than raise, and `ee/app/services/ee/projects/update_service.rb#validate_repository_mirror_update`, which raises a validation error, but only when the request actually changes mirror-related attributes and the mirror isn't being explicitly disabled. Don't duplicate the guard in `RemoteMirrors::{CreateService,SyncService,UpdateService}`, `ee/app/services/repositories/pull_mirrors/update_service.rb`, or `ee/app/services/start_pull_mirroring_service.rb`: `ProjectPolicy` already denies the `admin_remote_mirror` ability for a read-only project, which is what actually gates creating or reconfiguring a mirror through the UI or API, so a guard in those five services would just duplicate that. Confirm the reduced call-site list against the real code as you port it, an earlier internal review of this area got it wrong once, listing a call site that didn't check the right thing. One thing worth calling out explicitly: **the plain `Projects::UpdateService` does not check `repository_mirroring_blocked?` at all.** Only the EE override, `ee/app/services/ee/projects/update_service.rb`, does, inside a `validate_repository_mirror_update` method that only runs when the request actually touches mirror-related attributes. That's consistent with pull mirroring being an EE-only feature, so port both files as-is; don't add a check to the CE base service. Port the specs alongside each file: the read-only scenarios in `spec/policies/{project_policy,work_item_policy}_spec.rb`, `spec/services/projects/update_service_spec.rb`, the `can_be_merged_by?` scenario in `spec/services/merge_requests/merge_service_spec.rb`, and the six GraphQL mutation specs under `spec/requests/api/graphql/mutations/` that cover blocked repository-mutation mutations (`projects/blobs_remove_spec.rb`, `projects/text_replace_spec.rb`, `projects/branch_rules/squash_options/update_spec.rb`, `branch_rules/{update,create,destroy}_spec.rb`). Also port the two work-item link specs (`spec/services/work_items/related_work_item_links/destroy_service_spec.rb`, `spec/services/work_items/parent_links/create_service_spec.rb`), the EE counterparts (`ee/spec/services/projects/update_service_spec.rb` and both worker specs), `spec/workers/repository_update_remote_mirror_worker_spec.rb`, and the read-only scenarios already present in `spec/services/repositories/rewrite_history_service_spec.rb` and `spec/services/projects/cleanup_service_spec.rb`. ## PoC files to read - `app/services/continuity/projects/write_policy.rb` - `app/models/continuity/repository.rb` (for the `authority_state` enum and the `READ_ONLY_AUTHORITY_STATES`/`PROVIDER_BOUND_AUTHORITY_STATES` lists) - `lib/gitlab/git_access.rb` (the `repository_read_only?` check in `check_push_access!`, around line 392-394 on current `master`) - `app/policies/project_policy.rb`, `app/policies/work_item_policy.rb` - `app/models/merge_request.rb` (`can_be_merged_by?`) - `app/services/projects/update_service.rb` and `ee/app/services/ee/projects/update_service.rb` (`validate_repository_mirror_update`) - `app/workers/repository_update_remote_mirror_worker.rb`, `ee/app/workers/{repository_update_mirror_worker,project_import_schedule_worker}.rb` - Specs: `spec/policies/{project_policy,work_item_policy}_spec.rb`, `spec/services/projects/update_service_spec.rb`, `spec/services/merge_requests/merge_service_spec.rb`, `spec/services/work_items/related_work_item_links/destroy_service_spec.rb`, `spec/services/work_items/parent_links/create_service_spec.rb`, the six GraphQL mutation specs listed above, `spec/services/continuity/projects/write_policy_spec.rb`, `ee/spec/**` counterparts (`ee/spec/services/projects/update_service_spec.rb`, `ee/spec/workers/{repository_update_mirror_worker,project_import_schedule_worker}_spec.rb`), `spec/workers/repository_update_remote_mirror_worker_spec.rb`, `spec/services/repositories/rewrite_history_service_spec.rb`, `spec/services/projects/cleanup_service_spec.rb`. ## Acceptance criteria - Git push is rejected for a read-only project at the Gitaly access layer, regardless of the pushing user's role. - Issue, merge request, note, and work-item creation/mutation are rejected at the Ability layer for a read-only project. - Mirror scheduling and sync are rejected while `provider_bound?` is true, at the worker call sites listed above; mirror reconfiguration through `Projects::UpdateService` (EE) is rejected the same way when the request changes mirror-related attributes. - Ability-layer regression specs exist for the read-only-while-syncing case for issues, merge requests, notes/work items, and git push. If any of these is missing while porting, add it rather than skipping it. - No model-level `validate`/`before_save` guard is added anywhere. This was a deliberate decision (2026-09-09): the policy layer is considered sufficient for this phase, and a console session or script calling a model method directly is an accepted residual risk, not a gap this issue needs to close. - All ported specs pass. ## Out of scope - Adding a model-level write guard on `Note`, `Issue`, `WorkItem`, or `MergeRequest`. Decided against for this phase. - Changing `authority_state` or `WritePolicy` itself beyond the rename. Later, unrelated work is expected to touch this area (for example, splitting `read_only?` into separate git-content and collaboration-content checks), but that is not this issue. - The stop-updates/cutover logic that flips `authority_state` in the first place (a different LAND issue). - `Import::Sync::Repositories::RequestConnectionCheckService` and any "check connection now" UI. Those exist only on unpushed local branches and land in a later EXP issue. - `Projects::OpenWorkItemsCountService` and its EE override. Decided 2026-09-10: this is a cache-consistency fix unrelated to the GitHub-sync epic (it fixes a bug that `Project#after_import` already hits on current `master`). It moves to its own MR, tracked as https://gitlab.com/gitlab-org/gitlab/-/work_items/628603 ("Refresh both open work item count cache keys after import"). ## Notes for the reviewer - Treat the mirror-exclusion call-site list above as a checklist, not a given. A previous internal review pass already found one call site described incorrectly, so re-verify each one against the ported code rather than trusting this description. - Double-check that the plain (non-EE) `Projects::UpdateService` genuinely has no mirror-exclusion check, and that this is intentional (pull mirroring is EE-only), not a gap introduced during the port. --- **OAuth-path note:** `WritePolicy` keys on `authority_state`, which is provider-agnostic — no change needed for GitHub OAuth-connected projects (see epic 23553, which is now pursuing GitHub OAuth as the active connection path).