[freeqaz-openai]

Summary

Prepare protected GitHub App material from admitted repository bindings. Namespace-owned APIs retain bounded Agent drafts, exact binding/Secret authorization, generation checks, PostgreSQL persistence and transactional audit.

Trusted preparation authenticates an immutable Kubernetes source and a separate pinned encryption key, then exposes bounded material to the issuer. AES-GCM envelopes, private custody state, currentness checks, descriptor cleanup and plaintext-buffer wiping remain enforced. Encrypted token storage preserves original commitments and refuses overwrite or conflicting recovery.

Controller composition now consumes the concrete issuer from apps/controller/src/providers/token/github. Protected crypto and token-store exports remain in OCC. Their implementations and the repository-access SQL are unchanged; that migration now follows main's Agent stop migration.

Dependency and behavior boundary

Based on #136. Bindings remain unverified; saving a draft does not invoke preparation. Nonempty repository selections fail deployment with REPOSITORY_VERIFICATION_UNAVAILABLE before revision, queue or Compute effects. Production Work admission, verified checkout and retained credential-owner composition remain separate integration work.

Current supplier refresh

This update receives #136 at 38ff25fcf8985b31c7f167e2704168fea7d7cc9d, including main's Agent stop and Go CLI changes. Agent storage projections and generated API responses retain both repository selections and desired runtime state. Repository-draft deployment refusal and stop/resume behavior remain documented together.

• Repository transaction, binding-memory, platform-state-memory, and controller-lifecycle suites: 30 passed, 0 failed, 0 skipped, including Agent stop lifecycle coverage.
• Fastify API integration suite: 16 passed, 0 failed, 0 skipped, covering stop-response schemas, authorization, and failure boundaries.
• Project typecheck, generated OpenAPI/reference checks, workspace boundaries, documentation length, migration consistency, formatting of resolved files, and diff whitespace checks passed.
• PostgreSQL migrations and database integration were not rerun locally for this head. Required hosted CI must assess this exact revision before merge.

Validation on the previously published head

At faed9fcd8facec195730b0acb0a950df01420bad, 61 selected provider-protocol, protected-crypto and real-filesystem token-store tests passed with zero failures or skips. Focused formatting, workspace boundaries and documentation length checks also passed. The documentation suite passed 16 of 17 tests; the generated-API fixture and additional OCC-root token-store test could not load the workspace dependencies.

The full typecheck and generated API checks now pass as recorded above; the earlier focused results remain evidence for the prior head. These checks do not qualify live GitHub, Kubernetes, PostgreSQL, installed custody or the regular Agent workflow.

[kevinlin-openai]

i'm concerned that we are nerfing the agent too much if we constraint it to a specific checkoutref or what refs it can checkout. its very typical for an agent to checkout from main. branch locally. push to a new ref. or review other prs

[kevinlin-openai]

there is no need to put namespace in the payload since that part of the url parameters. we should also not let client set id.

POST /namespaces/{namespaceId}/repository-bindings

        "bindingRef": {
          "kind": "repository_binding",
          "namespaceId": "ns_11111111-1111-4111-8111-111111111111",
          "id": "rb_22222222-2222-4222-8222-222222222222"
        },

[kevinlin-openai]

id alone should be enough ehre. there is no reason to also add kind/namespace for secret ref

[kevinlin-openai]

both appid, installationid and repositoryids as integers are github specific. anything we have as a top level api should be implementation agnostic

ideally, we'd implement repositories behind a pluggable interface (eg. GithubRepoDriver)

we can then configure repos in a way the driver understands

POST /namespaces/ns_example/reposets

{
  "name": "backend",
  "repositories": [
    "acme/api",
    "acme/worker"
  ],
  "driverConfiguration": {
    "appId": 123,
    "installationId": 456,
    "keySecretId": "sec_example"
  }
}

separately, driver is responsible for verifying access to repo and checkout. this means we have a way of authorizing different repositories (pxxxdriver, gitlabdriver, etc)

[kevinlin-openai]

i don't like the name repository-bindings - anything with bindings reeks of llm slop. fine for internal impl but not public interface. can we call this reposet?