Settings and administration

Provider and source authority

This portable contract describes its linked source snapshot. For current deployment instructions, use current installation, authentication and native Cloudflare guides. Historical receipts do not verify later builds.

Golf separates personal, organization, repository and installation settings. Pages show current values or compact inventories, with explicit New or Edit actions where a supported backend exists. Planned rows explain the missing enforcement and link to implementation tasks; they are not active controls.

The workspace header provides Repositories and Organizations. Navigation follows the current task: choose Your account → User settings for personal Profile/Sign-in and security/Sessions/SSH keys/API credentials/Account activity navigation; repository settings show General/Access/Workflows; instance administration shows its own overview/local-account/infrastructure/coding-agent navigation. System status (/status) is a separate user-menu destination for capability readiness; the legacy /#capabilities link opens the same page. There is no permanent global sidebar.

The Switch workspace header button loads organization memberships only while open. Choose your personal workspace or an actually listed organization; Load more organizations requests further bounded pages. Switching is navigation, not a tenant or administration grant, and current resource authorization still applies. On Repositories, All accessible and Owned by you filter only loaded records, alongside search and visibility; ownership is observed from the loaded native owner name. These filters do not imply a complete server-side inventory or additional authority.

Scopes and authority

Scope	Route	Current authority and behavior
Personal	/account/settings	Your own profile/role display and coverage inventory; navigation to sessions, SSH keys, API credentials and activity. Public profile editing and password-confirmed Golf password/login-alias changes are available; see /account/security. Username changes, verified mail and recovery remain planned.
Organization	/organizations/OWNER/settings	Requires fresh verified organization membership. Existing non-owner teams have membership administration for verified native organization owners; membership alone does not grant edit authority.
Repository	/repositories/OWNER/NAME/settings	Fresh native repository access permits reading general settings. Editing additionally requires native repository administration, a suitable credential and an editable repository.
Instance	/admin/settings	A current enrolled Golf administrator password session can list enabled/disabled local accounts. Password-confirmed ordinary enrollment/reset/enable/disable, execution ceilings, organization creation policy and infrastructure profiles/source-storage activation have dedicated controls. Administrator lifecycle, database cutover and recovery remain operator-managed.

A Golf instance administrator role does not automatically confer native organization ownership or repository administration. Conversely, a native organization owner, repository administrator or provider OAuth login does not acquire the Golf instance role. Credential scopes remain independent: an administrator's read-only token can still be denied a save. Golf never substitutes a global administrator credential for the caller's credential.

Organization owner/admin/member labels remain native observations. Organization/team creation, invitations, team grants and repository assignment changes, owner-team management, last-owner recovery controls and global configuration editing remain planned. Instance administrators have a separate bounded ordinary-account disable action. See organization permission boundaries.

Existing-team membership

Open an organization, select a team and choose Team settings (/organizations/OWNER/teams/TEAM_ID/settings). Members can read the permitted inventory. Only a freshly verified native organization owner with suitable credential scopes can change membership in a non-owner team. A Golf instance role or native site-administrator visibility does not substitute for this ownership proof. Owner teams have no add/remove controls in this preview.

1. Choose Add member, enter an existing native account username and choose Resolve member.
2. Review the resolved immutable user ID and the team's recorded grants, then choose Add resolved member. This adds an existing account; it does not send an invitation or create a user.
3. To remove a listed member, choose Remove and confirm the named account/team. Cancel leaves membership unchanged.

The request binds the organization/team IDs, resolved user ID/login and observed team revision. Golf verifies identity, ownership and membership before dispatch and independently checks the resulting membership afterward. Adding a member activates that team's existing grants; other memberships can combine with them. Removing one membership does not prove complete access revocation or removal from the organization.

These checks detect stale forms and observed disagreement; the provider's username-addressed membership mutation is not an atomic immutable-ID or compare-and-swap operation. Independent native edits can race the final check. Lost responses may follow a completed change: Golf makes no automatic retry and requires refreshing and inspecting actual membership before another action. No durable membership outcome journal is implemented. See the bounded team administration contract.

Personal profile and sign-in settings

Use Profile → Edit profile for display name, bio, location and website. Changes bind the immutable current user and original observed revision; unsupported username/email fields are absent. Native profile updates are one supported API write with verified receipt/readback, not atomic native compare-and-swap. Unconfirmed writes require a manual refresh before another deliberate edit.

Sign-in and security (/account/security) reads your actual Golf login alias. Choose Change password or Change sign-in email, then enter your current Golf password. Saving increments the local credential version, revokes all bound local password sessions and dependent API credentials, expires the current cookie and requires fresh sign-in. Email remains an unverified login alias: mailbox ownership, mail delivery, provider email and recovery are not changed. An uncertain response sends no automatic mutation retry; private UI data clears and you return to manual sign-in. Username changes, MFA, passkeys and verified-mail recovery remain planned.

Instance local-account inventory

Instance settings (/admin/settings) lists persisted enrolled Golf accounts, including disabled accounts. It shows the enrolled username/email, Golf role, local sign-in state, account/native-user IDs and enrollment time. Search and sorting cover loaded rows; Load more requests another bounded server page. The inventory does not include every native Forgejo or OAuth user.

InstanceAdminService.ListLocalAccounts requires a current Golf password session with the explicitly enrolled instance-administrator role. The server checks current provider identity and local session/version authority before and after reading. Ordinary local users, PAT/OAuth sessions and delegated API credentials are denied, even when a token belongs to the same native identity as an enrolled administrator. Results contain metadata only: no password verifier, encrypted token, key material or session credentials.

The /admin overview displays global settings coverage; /admin/settings contains local accounts. Choose Disable local sign-in for an enabled ordinary account, review its immutable ID/version and enter your own current Golf password before confirming. Administrator accounts, including your own, are protected and have no disable action. Password confirmation uses the durable bounded login throttle; the server rechecks actor identity and authority afterward.

One local transaction disables the target, increments its credential version, deletes its bound password sessions and records an actor-bound ADMIN_DISABLED event. Dependent Golf API credentials lose their source session. A stale target version fails; a lost response requires refresh and inspection, with no automatic retry. Independent PAT/OAuth sessions and native Git keys remain usable. This is not a global native-user ban.

Choose New local account to enroll an existing Git identity as an ordinary Golf user, supplying its exact numeric user ID, private credential, Golf username, optional unverified login alias and fresh password. This does not create a Git identity or grant instance administration. Reset password revokes existing password sessions and preserves disabled state; Enable local sign-in requires a fresh password and private credential matching the original immutable Git identity. Every action confirms the acting administrator’s password, binds the target’s original credential version and records actor-bound lifecycle evidence. Administrator/current-actor targets remain protected. Unknown outcomes require manual refresh and inspection without automatic retries. Role changes and administrator recovery remain operator-managed; there is no universal native-user ban. See the disable contract, inventory contract and local authentication.

Repository general settings

Open the repository's Settings link to inspect its description, default branch and issues/wiki/pull-request feature flags. The preview uses RepositorySettingsService through the same browser-session/Origin boundary as other settings.

1. Choose Edit general settings when offered. The action is absent for read-only users, archived repositories and mirrors.
2. Change supported values. Description accepts up to 2,048 UTF-8 bytes; default branch must name an existing native branch. Feature choices control native repository features, not Golf CI, agents or protected merge policy.
3. Choose Save repository settings, or Cancel to discard the draft and return focus to Edit.

Only changed fields are sent. Omitted fields stay unchanged; empty description and disabled flags are explicit values. The request binds immutable repository/owner IDs and the observation revision loaded by the editor. A stale revision or changed identity is rejected before dispatch; native administration and branch existence are checked again before writing.

The revision is stale-form detection, not atomic native compare-and-swap. Another native editor can race between Golf's read and PATCH. Golf validates the native receipt and independently reads back settings, but this slice cannot enforce security-sensitive inherited policy or guarantee exactly-once mutation.

A lost response or failed readback may follow an accepted write. Golf does not automatically retry and blocks another save until you refresh and inspect actual values. Navigation cancellation cannot undo a completed native write. There is no durable settings operation-status journal yet. Private values are hidden during revalidation and after permission failure; a late response cannot populate a departed or different-account view.

See the repository settings contract and runnable checks. The source includes input/authority checks, controlled-provider PostgreSQL tests, a disposable native smoke and browser fixtures; the implementation ledger records which checks passed against which runtime.

Repository collaborator access

Repository settings share a side navigation: General, Access (/repositories/OWNER/NAME/settings/access) and Workflows (/repositories/OWNER/NAME/settings/workflows). Each page performs its own fresh authority check.

Access displays the actual native owner ID and your observed permission. A positively identified personal repository owner or qualified direct collaborator with current native admin authority can load collaborators and manage existing accounts. Ordinary readers receive metadata only; organization repositories and exceptional non-owner native owner authority remain read-only. Golf instance administration does not override these checks. Hidden organization classification fails closed rather than assuming a personal owner.

1. Choose Add collaborator, or Change on an eligible direct collaborator.
2. Enter an existing username and select read/write/admin, then choose Resolve and review access. Review the immutable user ID and original observed grants. Admin includes destructive native repository authority; Golf displays that warning before approval.
3. Choose Apply reviewed access. Removing a direct grant uses a short named confirmation.

Owner, caller self and exceptional owner-level targets are locked. Search/sort cover loaded collaborators; Load more preserves server pagination. The inventory reports direct membership separately from native effective permission: public readability, organization/team grants or other native authority can survive a direct grant removal. It is not a complete effective-permission calculation.

Writes bind repository/owner/user IDs and original repository/collaborator revisions. Golf rechecks authority, dispatches once and validates identity/membership/permission readback. Native username-addressed writes are not atomic compare-and-swap; outside renames, transfers and authority changes can race. Unknown outcomes require fresh inspection and separate review, without automatic retries or a durable mutation journal. Invitations, deploy keys, custom roles and organization grant editing remain planned. See the repository access contract.

Workflow source inspection

Workflows displays direct .github/workflows/*.yml/*.yaml and root .gitlab-ci.yml at one resolved default-branch commit. File links use that immutable commit; refresh resolves the current default branch again. The searchable table shows format, size, bounded jobs/events and fixed diagnostics. No matching files is a successful empty inventory, distinct from denial or inspection bounds.

Inspection subset checked means only the versioned static shape passed: one input-free manual Actions shell job, or one digest-shaped-image GitLab script job. Unknown provider features remain unsupported, malformed documents invalid. Inspection never executes commands or fetches includes/actions, expressions or secret values; an image reference is not a trusted installed runner. Supported manual jobs now have explicit dispatch and run inspection controls after current authority, durable execution policies and worker availability pass. Automatic triggers, remote actions and native engine parity remain unimplemented. See manual pipelines.

Limits are 20 discovered files, 64 KiB per inspected file and 512 KiB aggregate eligible bytes, with bounded YAML nodes/depth/diagnostics. Oversize files remain metadata-only; an overfull inventory fails visibly. Source hashes and immutable repository identities are verified, and private output is withheld after observed authority changes. Inspection does not expand CLI/MCP delegated allowlists or prove broad engine compatibility; execution is a separately qualified bounded shell subset. See the workflow inspection contract and next execution gates.

Settings coverage inventory

All four scopes distinguish Ready, Partial, Read only and Planned. Availability describes a bounded capability, not completion of every related feature. Read the accompanying reason; for example, SSH account keys work while scoped expiring agent Git credentials do not.

Inventories cover:

• Personal identity, passwords/recovery/MFA, sessions, SSH/signing keys, API credentials, connected identities, notifications, appearance, activity and agent/provider credentials.
• Organization members/teams/roles, defaults and repository selection, CI/fork/workflow policy, runners, secrets/OIDC, rulesets, agents/MCP, connections, budgets and audit/retention.
• Repository general/features, collaborators/deploy keys, rules/reviews, engines/workflows, runner resources, secrets/OIDC, environments/previews/CD, agents/MCP, webhooks and destructive administration.
• Instance enrollment/SSO, system health, infrastructure/shared pools, policy ceilings, provider/email connections, credential response, recovery, quotas and retention.

The shared table provides search, sorting and page-size/navigation controls for loaded rows; these local pages never imply the whole server inventory is loaded. The coverage inventory describes displayed settings rows. Session/key/API/activity tables search only loaded records; Load more still requests another server page. Coverage rows are descriptive task inventories, not persisted policy values. Supported policy editors persist default-deny execution ceilings; planned rows have no fake save buttons.

Remaining governance gates

Plan section 6.4 requires typed instance → organization/personal-owner → repository → workflow/environment policy, immutable repository selection, explicit inheritance/locks and an explanation of effective authority.

CI currently enforces disabled/all/selected eligibility, exact workflows, durable epoch fences and attempt-bound worker capabilities. Actor/event expansion, runner groups, allowed workflow dependencies, fork approvals, secrets and budgets still need broader implementation. Agents require their own tool/model/network controls. Secrets, production environments, integrations, model/MCP tools and Cloudflare or portable destination resources need separate authorization. The implemented ceilings are persisted and rechecked during admission, assignment and result publication; the remaining policies cannot be offered as enforced controls until their corresponding execution boundaries exist.

Bounded manual Actions/GitLab shell execution is available; full native-engine parity, integrated coding harnesses, protected integration, Cloudflare execution, previews and production deployment remain open.

Public repository qualification

A separate public source-transfer drill passed with pinned real GitHub and GitLab examples in an isolated local stack. It checks selected-ref history, exact commit/blob identities, README/license and workflow source bytes through Golf's paginated API and CLI, with private cross-user denial and cleanup.

The drill preserves workflow files as untrusted source; it does not run them. It is not a product import screen/API, provider connection, all-ref mirror, collaboration migration or CI compatibility proof. Imported schedule, secret, webhook and runner activation require separate implemented trust gates. The report records source pins, exclusions, runnable commands and the proposed first execution subset.

Infrastructure and policy pages

The admin portal separately exposes infrastructure connections, execution ceilings at /admin/execution and organization creation policy at /admin/organizations. Organization creation can be administrator-only, selected enrolled users or all users; native credentials remain separately authorized. Infrastructure has separate Databases/Object storage sections and Add actions, named saved profiles and exact historical active-version metadata. Saving/testing database profiles stages an operator-controlled cutover and does not change live pools. Object source-storage activation is explicit and version-bound, with a current-to-proposed destination warning; existing runs retain their binding. See manual pipelines for actual supported execution and remaining engine gates.

Capability/provider status and event setup

System status groups the shared Golf platform, coding agents and optional Cloudflare integrations into separate tables. Provider configuration is distinct from verified operation and runtime readiness. The planned per-function selection/resource/last-test panel must enforce inherited policy and immutable connection bindings; the current status table does not supply those controls. Native push intake is operator-configured rather than a settings form. Webhooks distinguishes that bounded intake from future automatic CI and outbound notification subscriptions.

Personal coding-agent accounts

Coding agents in Account settings opens the personal Codex connection page. Connect/reconnect, official device approval or API-key login, provider-reported details, status refresh and confirmed disconnect are implemented separately from task execution. A connection does not grant repository/model/task authority. The admin portal also manages named instance connections at /admin/agents: new items have no allowed users until explicit immutable-user assignment. Use permission, administrator management and private personal credentials remain separate. Other harnesses and managed execution remain planned.