Instruction resources
Evaluate the workflow and applicability. Model compliance remains a behavior to verify.
Configuration ownership
Make the shared setup maintainable.
Give organization requirements and team additions a clear owner, revision history, and release path.
Agent configuration needs the same care as other shared engineering dependencies. Betterloop keeps inheritance, review, and signed delivery connected.
01 / Configuration ownership
Write a change that another owner can review.
Harbor is an imaginary organization. Its Search team wants an approved documentation connection and consistent review instructions for search-api.
The proposed change should explain who needs it and which clients will use it. It should also name the affected controls and resource versions.
Describe a permitted operation and a prohibited operation where a control applies. State the client event that performs the check.
A shell rule, for example, can restrict a literal executable at a covered hook. It does not contain every process that executable starts.
Include that limit in the review description. The reviewer can then judge whether the proposed boundary meets the team's actual requirement.
Each organization and team maintains one configuration. An unfinished draft and a published release belong to its history; they are not separate profiles.
Organization and team owners use the same rules editor. Their permissions and inheritance responsibilities differ, but the configuration workflow remains consistent.
A useful review therefore combines structural validity with engineering judgment. A well-formed rule can still be unsuitable for the team's working environment.
02 / Configuration ownership
Treat the parent revision as a dependency.
The Search configuration pins a compiled organization revision. Its inherited requirements and resource grants come from that particular baseline.
A later organization release becomes available for review. It does not automatically replace the revision already selected by the team.
An ordinary team save preserves the existing pin. Adopting a newer baseline requires the owner to refresh it explicitly in the editable configuration.
The effective preview shows the combined result. Examine inherited requirements together with permitted team additions before requesting approval.
Publish the adopted baseline through the team's normal review path. Availability at organization scope does not establish delivery to Search devices.
Mandatory inherited requirements remain binding. Team changes cannot weaken them or override the organization-owned treatment of unknown repositories.
Suppose Harbor revises its documentation connection. Search can examine that revision with its dependent resources rather than receiving different connection bytes without review.
Track the unadopted revision as maintenance work. Ask whether the team needs more review time, compatibility work, or a correction to the proposed baseline.
03 / Configuration ownership
Review the files behind each resource name.
The configuration registry identifies resources with an ID, version, type, and digest. A familiar display name does not identify the reviewed bytes.
The release selects exact versions at the reviewed Git commit. Validation checks the selected files and their schemas before signing the effective configuration.
Published version directories are immutable. Make a changed resource a new version so earlier releases remain reproducible and understandable.
Dependencies also need exact reviewed versions. Multi-file resources retain their relative layout. Validation rejects unsafe paths, absent dependencies, and changed immutable files.
A helper file stays a file until an applicable mechanism executes it. Resource discovery does not run supporting scripts merely because they exist.
Team executable additions need an organization grant or the approved resource at the pinned organization baseline. A grant does not authorize replacement bytes.
Optional library approval has a separate purpose from required delivery. It permits a developer choice without adding the resource to every team setup.
Skills supply guidance, while hooks run at covered events. MCP definitions identify approved connections, whose credentials and service permissions remain separate.
Executable hooks
Inspect the implementation, parameters, event binding, and failure behavior.
External connections
Review endpoints and requested scopes separately from developer authorization.
04 / Configuration ownership
Carry approval through to the artifact.
Review authority is evaluated at the exact pull request head. Eligible mapped reviewers must cover configuration and selected registry paths.
Use explicit CODEOWNERS entries for configuration files, resource paths, and the registry manifest. Separate owners can cover different parts of a change.
A new commit changes what must be evaluated. Approval of an earlier revision does not establish approval of the final files.
Automated validation can reject an invalid structure or inheritance conflict. People still decide whether the intended behavior is appropriate.
After approval, an isolated signer produces compatible artifacts. Compilation, signing, expiration, and delivery are distinct stages with distinct failure conditions.
For Search, merging the configuration pull request is an intermediate milestone. A usable Codex artifact must still exist and reach participating devices.
Keep the approved commit and resulting release identifiable. That connection makes later setup investigations much easier than comparing mutable files by name.
- 01
Prepare a draft
Edit the proposed rules and selected resource versions.
- 02
Read the effective result
Check inherited requirements against the intended team behavior.
- 03
Open the review
Submit the configuration change for eligible owners.
- 04
Complete the requirements
Resolve validation results and required approvals.
- 05
Inspect release output
Check signing and the required runtime artifact after merge.
05 / Configuration ownership
Repair the stage that failed.
A signing failure needs release repair. It does not call for pretending that the merged configuration became active on developer devices.
An inheritance conflict needs a corrected draft. Personal selections cannot serve as a route around mandatory organization requirements.
An unsupported client action needs a different deployment decision. Requiring a control more strongly does not implement the missing native boundary.
An ambiguous project match needs an explicit selection. Supplying every possible project's references would discard repository isolation rather than resolve the ambiguity.
A temporary outage can leave a valid signed cache usable. Expired material and known revocations change that result and require separate investigation.
A corrective release follows the same approval and signing path. Compare the delivered revision with the intended correction before closing the investigation.
Connections provides reported configuration and coverage information. Sessions adds bounded lifecycle and decision context. Neither represents independent attestation of the device.
Keep unresolved delivery or activation questions visible. The configuration history explains what was approved; local checks explain what became usable.
| Maintenance point | Owner check | Record to retain |
|---|---|---|
| Draft preparation | Does the effective configuration express the intended change? | Selected baseline and proposed resource versions |
| Git approval | Do eligible owners cover the current head? | Approval and validation results for that revision |
| Artifact publication | Is the target runtime release usable? | Signature, expiry and compatible variant |
| Local activation | Did the participating client invoke its integration? | Fresh-session diagnostics and stated gaps |
How do teams move to a newer organization baseline?
Refresh the pinned baseline explicitly, inspect the effective result, and publish it through normal team review.
Why does an approved registry entry remain inactive?
Registry presence only identifies available content. Selection, publication, installation, and applicable execution still need their own checks.
Does project mapping authorize repository access?
No. Mapping selects context for a repository. GitHub permissions and authorization to referenced services remain independent.