Developer connection steps
Give the invited developer the complete device procedure.
Open this resource →Administrator guide
Prepare the first team handoff
A complete path from workspace creation to reviewed rules, repository assignment, and one inspected developer connection.
Your first release should be easy to trace. Choose a team, a working repository, and a developer who can check the result with you.
01 / Administrator guide
Agree on the first observable result
Choose the organization owner. Identify the person who will review configuration changes. Select the first team and its initial working repository.
The configuration repository holds reviewed rules and resource files. The working repository holds the code your developer uses. Establish access to both.
Write down the controls that the first connection must support. Mark each requirement as mandatory or advisory. Check agent compatibility before publication.
| Preparation | Question to settle |
|---|---|
| Owner account | Can this account create the team and connect GitHub for the organization? |
| Configuration review | Who owns this repository, and who can approve a rules change? |
| Working repository access | Can the invited developer already access the selected repository through GitHub? |
| Approved software | Which setup package and agent builds does the release owner supply? |
| First acceptance check | Which real task and supported controls will you inspect together? |
Choose a small existing repository check for the initial task. Keep its inputs and expected result clear. Avoid using an invented success message.
A configured rules screen shows intent. The connected session supplies evidence about application. Keep both records when you assess the first release.
02 / Administrator guide
Publish the configuration in order
Establish ownership
Visit the application sign-up page. Create the owner account. Sign in. Open Organization setup. Supply the first team name.
The setup screen retains completed work. Return to it after an interruption. Read saved progress before repeating an operation.
Connect the reviewed source
Connect organization GitHub. Choose the configuration repository. Confirm that the repository reviewers match the people responsible for approved rules.
Each scope has one rules configuration. A saved draft is a revision under preparation. A published release is a reviewed version available for delivery.
Release organization rules
Open the shared rules editor at organization scope. Check tools, permitted shell programs, resource selections, and reporting choices. Save the proposed revision.
Complete the required Git review. Publish the approved revision. Developers do not receive a draft merely because it was saved.
Release team rules
Open the same rules editor at team scope. Review the selected organization baseline. Enter the team changes permitted by that baseline.
Save the team draft. Complete its review. Publish the approved team revision. The baseline remains pinned until the team adopts another reviewed revision.
Include the working repository
Open Projects. Assign the working repository to the team. Save the resulting team draft. Complete review. Publish the changed team configuration.
The assignment becomes part of the signed knowledge map. GitHub access remains controlled by GitHub permissions. Repository assignment does not grant that access.
03 / Administrator guide
Make the unmatched-repository choice explicit
Set unapproved-repository behavior in organization rules. A new organization baseline starts with report_only. A team inherits this setting without a team override.
Under report_only, repository use produces a report without company rules or bindings. Company skills, registry hooks, knowledge, and fleet learning are omitted.
Under apply_team_defaults, the agent receives the applicable team defaults. Company project knowledge remains unavailable when the repository has no matching assignment.
Both choices leave repository approval unchanged. Neither choice blocks unapproved work. The developer and provider retain their existing local settings.
Read the resulting event carefully
The report identifies the signed release, device, agent, and time. Git host, owner, and repository values are sanitized before delivery.
When a remote cannot be resolved, the report uses an opaque alias with a reason. Local paths and command arguments are excluded.
Source, prompts, and credentials are also excluded. A bounded queue handles offline delivery. A failed delivery adds a diagnostic without blocking development.
Team Events presents these records as client evidence. A received event does not establish complete observation of every action on the device.
Check adoption before you depend on the setting
The explicit field needs setup 0.7.0 and Mimir 0.27.0. Check deployed clients before you publish a release that uses it.
An older release can retain its previous behavior until you publish an explicit choice. Teams adopt the updated baseline through their normal review.
04 / Administrator guide
Inspect the invitation handoff
Send the team invite link or issue a personal enrollment code. Ask the first developer to select one agent. Confirm the intended organization and team.
Have the developer finish native provider sign-in. For Codex, have them open /hooks. Ask them to review the Betterloop hooks and complete native trust.
Start a new agent session in the assigned repository. Run doctor there. Review enrollment, signed release, activation, and required controls together.
Repeat the inspection in an unassigned repository. Compare the observed behavior with the published organization choice. Expect no unmatched company project knowledge.
Illustrative rollout: Harbor Search
Harbor selects a Search team and its existing configuration repository. The team adds search-api through Projects. Reviewers approve the organization and team revisions.
One developer connects Codex and completes hook trust. The pair checks doctor in search-api. The release owner records each required control and its conditions.
If hook activation is still pending, the wider invitation waits. The developer checks native trust and starts another session before the team repeats inspection.
| Unexpected result | Investigation |
|---|---|
| Assignment absent in the client | Find the team revision containing the mapping. Confirm review and publication. Refresh the developer connection. |
| Organization change absent in the team | Inspect the selected baseline revision. Propose and review adoption of the intended organization version. |
| Setup still shows an incomplete step | Read the saved release, mapping, and connection state. Complete the missing operation through the setup screen. |
Keep the acceptance record specific. State the agent build, repository, reviewed release, required controls, and observed result. Expand only after the agreed checks are satisfied.
Keep permission ownership clear
Organization GitHub authorization needs organization permissions. A team-only administrator can change permitted knowledge mappings without obtaining that organization-level authorization.
Personal enrollment connects the device to one organization and team. An invitation does not create cross-team routing or simultaneous membership connections.
Executable additions require organization authorization and applicable review. Approval includes their exact versions and supporting files. A team cannot bypass those requirements.