How HQ is organized

A workspace is a collection of projects and the boundary for membership. A project is the product, service, tool, or effort you maintain. A repository is a source-code identity belonging to a provider. One project often has one repository, but neither is an alias for the other.

Workspace: membership and access
  Project: durable maintained effort
    Repositories: code identities and expectations
    Hooks: explicitly related subscriptions or provider resources
    Monitoring: explicitly related targets
    Secrets: explicitly enrolled provider resources
    Activity: immutable attribution and work reports

This is a navigation model, not a rule that every resource must have exactly one project. Repositories can remain unassigned. A monitor or subscription can be relevant through explicit repository links, direct project context, or both. Shared resources retain one provider configuration and operation history.

What each decision means

Decision	What it controls	What it does not prove or change
Workspace membership	Access to HQ data and permitted operations	Provider credentials or provider roles
Project grouping	Organization and relevant resource navigation	GitHub ownership or deployment location
Importance	Maintainer priority: Standard, High, or Critical	Incident severity or observed health
Portfolio inclusion	Undecided, Planned, Listed, or Excluded visibility decision	Publication of a portfolio page
Repository tracking	Maintained or watchlist intent	GitHub administration permission
Expectations	Evidence and review requirements	Actual CI, scanning, or endpoint results
Connection enrollment	Approved provider resources and HQ scope	New upstream authority

Assessment and organization controls take effect inside HQ. A repository review date appears in Overview when due; it is not an outbound reminder. Changing project lifecycle or disabling an HQ connection does not stop a provider's service. Use the specific Monitoring, Hooks or Secrets operation and inspect its exact review and receipt for a provider change. Unavailable operation controls name the missing capability instead of accepting an intent-only substitute. Portfolio publication and reusable secret-value storage are not provided by their metadata or inventory screens.

Connections own provider access

A connection belongs to a workspace and refers to independently provisioned provider authority. It can enroll resources without pretending those resources are GitHub repositories. A connection's descriptive project context does not assign every target to that project.

GitHub webhooks are repository-scoped GitHub configuration. Hookrelay subscriptions are a different authority and can receive events unrelated to GitHub. Likewise, endpoint health describes a target, not every aspect of a repository's quality.

Following a shared resource from a project does not narrow the effect of its provider operation. Review the full target and shared-impact information before confirming.

Moving is different from regrouping

Assigning a repository to another project inside its workspace is an ordinary metadata edit. Moving a project between workspaces changes access and requires Owner membership in both. The exact review accounts for source enrollment, dependencies, history, and credentials. Unsupported provider dependencies block the move before any partial transfer.

Local and hosted are the same product

The hosted application runs defined, authorized operations against HQ state or supported provider APIs. It does not run a remote shell on your machine. Local development uses the same application with an isolated loopback identity. Local publishers contribute checkout observations; when they are offline, those observations become stale rather than preventing you from opening the dashboard.