intrnl.cloud
Building applications

Source control

Managed Forgejo repositories, change sets, GitHub canonical mode, and full-history transfer.
v1 design baseline. This page specifies intended behavior. Delivery and validation are tracked in the implementation plan; it is not a claim that the platform is already implemented.

Two source modes

Managed Source
└── Forgejo is canonical

External Git
└── External provider is canonical

An application has exactly one writable source of truth at a time.

Managed source

Managed applications are stored in hidden Forgejo repositories.

Mapping:

intrnl organization
└── Forgejo organization using opaque ID
    ├── app_01K...
    ├── app_01K...
    └── app_01K...

Users see:

Version 12 — Added manager approval
Version 11 — Added department selection
Version 10 — Initial app

They do not have to see:

commit
branch
origin
rebase
merge

Forgejo supports normal repository APIs, SSH/HTTPS Git, webhooks, mirroring, and push-to-create. Push-to-create remains disabled for ordinary users by default and can later support controlled developer workflows. Forgejo repositories

Branch/change-set model

main
change/chg_01K...
change/chg_01K...

main is protected. Only the intrnl control-plane service can advance it.

An AI or browser edit operates on a change-set branch.

A change set has:

base revision
current revision
human actor
agent/client
status
build
preview
requested capabilities
migration analysis

Suggested lifecycle:

Draft
Building
Build Failed
Ready for Preview
Deployment Requested
Approved
Merged
Deployed
Discarded

When accepted, preserve full commit history with a controlled merge commit. Do not throw away audit-relevant intermediate history unless retention policy explicitly says otherwise.

Direct Git access

Managed apps may later enable:

git clone git@code.intrnl.cloud:org_01K/app_01K.git

This is:

  • Disabled by default
  • Available only to Developer-role users
  • Scoped to specific repositories
  • Audited
  • Revoked through the organization identity lifecycle

The Forgejo web interface remains hidden unless a future developer product intentionally exposes it.

External Git

V1 GA supports GitHub through a GitHub App.

Use:

  • Installation on selected repositories
  • Minimum repository permissions
  • Signed webhooks
  • Short-lived installation tokens
  • Exact commit SHA fetching
  • No personal access tokens

GitHub Apps can authenticate as an installation and be installed on selected repositories, which fits repository-scoped access better than broad personal credentials. GitHub Apps overview

For an external repository:

GitHub = canonical source

GitHub push/webhook
        ↓
verify webhook
        ↓
fetch exact SHA
        ↓
create immutable source revision
        ↓
build

If AI editing is enabled:

AI change
   ↓
intrnl creates branch
   ↓
commits change
   ↓
opens pull request
   ↓
GitHub workflow remains authoritative

intrnl does not independently modify an internal mirror and later attempt unrestricted two-way synchronization.

Forgejo mirroring can be useful for caching or archiving, but push mirrors can force-push and overwrite changes, reinforcing why two writable masters are prohibited. Forgejo repository mirrors

Source cache

For external repositories, intrnl may maintain a read-only bare cache or mirror for:

  • Faster builds
  • Resilience
  • Immutable revision retrieval
  • Audit preservation

The external repository remains canonical.

Managed-to-external transfer

A production-worthy citizen-developed app can be transferred to engineering:

  1. Freeze managed-source writes.
  2. Export the complete Git history.
  3. Create or select the external repository.
  4. Push history.
  5. Install and validate the GitHub App.
  6. Verify webhook delivery.
  7. Record the external canonical repository.
  8. Switch source_mode.
  9. Unfreeze operations.
  10. Audit the cutover.

Thereafter, AI edits must become external branches/PRs.