Governance / Infrastructure Standards

CTX Repo Infrastructure Guide

Infrastructure standard for creating, populating, refreshing, validating, and maintaining third-party vendor documentation context repositories for human operators, AI agents, AI-assisted development tools, automation workers, and future MCP/RAG workflows.

Text size
Status: publishedCreated: 06/28/2026Last updated: 06/28/2026

Document Scope

The service uses CTX repositories as local and remote Git repository context libraries for selected third-party vendor documentation, SDK source material, examples, API references, and related technical guidance used by human operators, AI agents, AI-assisted development tools, automation workers, and future MCP/RAG tooling.

This document defines the infrastructure standard for creating and maintaining third-party vendor documentation context repositories. It covers repository naming, local folder placement, remote repository setup, official source selection, initial population, repeat-safe refresh scripts, commit requirements, remote push requirements, and validation.

This document does not define the Markdown-document drafting standard for individual CTX repository update documents. That drafting standard belongs in CTX Repository Documentation Standard.

1. Purpose

A CTX repository is a read-only reference mirror created for selected third-party vendor documentation and source material.

The purpose is to make important vendor reference material available locally inside the development environment and remotely inside a version-controlled Git repository. This supports local development, AI-assisted development-tool usage, AI-agent work, future MCP/RAG indexing, disaster recovery, and access to prior documentation states that may have been used when earlier application code was built.

CTX repositories are used because outside vendor documentation can change, move, go offline, or become temporarily unavailable. A local and remote Git repository context copy gives the company a stable reference point that can be searched by humans and AI tools before reaching outward to the public internet.

CTX repositories do not replace official vendor documentation. They provide a controlled local context layer. AI agents should search the local CTX repository first. If the local context is missing, stale, incomplete, or insufficient for a specific implementation question, the agent may then search the official vendor website or public upstream source.

2. Current Repository Environment

The local development working directory is:

C:\dev

Current key local repositories include:

C:\dev\admin
C:\dev\site
C:\dev\news
C:\dev\server
C:\dev\ctx-better-auth
C:\dev\ctx-brevo
C:\dev\ctx-resend

The C:\dev\news repository is the current core SaaS application backend repository. It may later be renamed to C:\dev\app. In documentation and instructions that describe the long-term system shape, refer to this repository as the core application/backend repository.

The remote Git repository namespace currently used for the company's repositories is:

sudostac

The current SSH remote format is:

git@gitlab-sudostac:sudostac/<repo-slug>.git

Examples:

git@gitlab-sudostac:sudostac/ctx-better-auth.git
git@gitlab-sudostac:sudostac/ctx-brevo.git
git@gitlab-sudostac:sudostac/ctx-resend.git

The internal admin document library is currently available at:

http://127.0.0.1:42000/docs/

A Cloudflare Tunnel access URL may be added later. Do not delay creating or updating this documentation while waiting for the Cloudflare Tunnel URL. After tunnel access is configured, update the relevant document-library access section with the external/private-access URL.

3. CTX Repository Naming Standard

Every third-party vendor documentation context repository must use the ctx-<vendor-or-product> naming pattern.

The local folder name, remote Git repository slug, and remote URL must use lowercase kebab-case.

Examples:

ctx-better-auth
ctx-brevo
ctx-resend

The local folder must be created under:

C:\dev

Examples:

C:\dev\ctx-better-auth
C:\dev\ctx-brevo
C:\dev\ctx-resend

The remote Git repository display name may use readable casing, but the repository slug and local folder must remain lowercase kebab-case.

4. Remote Git Repository Description Standard

Each CTX repository must have a clear remote Git repository description that explains what the repository contains, how the content is updated, and what the technology is used for inside the service.

The description should follow this pattern:

Context read-only mirror repository containing selected official <Product> documentation and source material for development, AI tooling, and reference. The <Product> update process <briefly describe how official source material is refreshed>. URL: <official documentation URL>

The description must be specific when a product uses multiple official sources.

Example for Better Auth:

Context read-only mirror repository containing selected official Better Auth documentation and source material for development, AI tooling, and reference. The Better Auth update process pulls the latest selected documentation files from the official Better Auth GitHub repo, including the docs/content/docs documentation path used for local authentication implementation reference. URL: https://better-auth.com/docs/introduction

Example for Brevo:

Context read-only mirror repository containing selected official Brevo documentation and source material for development, AI tooling, and reference. The Brevo update process downloads the current OpenAPI YAML, pulls the latest selected files from the official Brevo Node repo, and pulls the latest selected files from the official Brevo Python repo. URL: https://developers.brevo.com/docs/getting-started

Example for Resend:

Context read-only mirror repository containing selected official Resend documentation and source material for development, AI tooling, and reference. The Resend update process pulls the latest selected documentation, examples, and SDK reference files from official Resend sources for transactional email, SMTP relay, and related email-sending infrastructure. URL: https://resend.com/docs

5. Required Infrastructure Outputs for Every CTX Repository

Every CTX repository must produce the following infrastructure outputs:

  1. A remote Git repository with a standardized ctx-<product> name and description.
  2. A local repository under C:\dev.
  3. A repeat-safe PowerShell refresh script.
  4. A committed local repository populated from official vendor sources.
  5. A pushed remote Git repository with the same committed context material.
  6. A clean final git status.

A CTX repository is not infrastructure-complete until the repository exists locally and remotely, has been populated from official vendor sources, has been committed, has been pushed, and has been validated.

The separate documentation outputs are controlled by CTX Repository Documentation Standard.

6. Source Discovery Standard

Before creating the refresh script, identify the official source locations that are relevant to the way the service uses the product.

Preferred source order:

  1. Official vendor documentation.
  2. Official vendor GitHub repositories.
  3. Official OpenAPI, API schema, SDK, or reference files.
  4. Official examples maintained by the vendor.
  5. Official AI-readable documentation files such as llms.txt or llms-full.txt, if available.
  6. Official AI tooling or MCP repositories, if relevant.
  7. Official template, UI, framework, or integration repositories, if relevant.

Do not use unofficial mirrors, blog posts, random examples, third-party tutorials, or old package forks as primary CTX sources unless there is a specific documented reason.

The source set must be based on the product's actual technical use inside the service.

Examples:

Better Auth is used for authentication, so the CTX repository stores selected Better Auth documentation for user accounts, login, sessions, and account-access control.

Brevo is used as an email delivery provider, so the CTX repository stores selected Brevo OpenAPI, Node SDK, and Python SDK reference material for transactional email, SMTP relay, and related email infrastructure.

Resend is used as an email delivery provider and related email tooling source, so the CTX repository stores selected Resend documentation, OpenAPI material, Node SDK material, Python SDK material, examples, React Email material, and AI-tooling references.

7. PowerShell Script Standard

Every CTX refresh script must be repeat-safe.

Every PowerShell script or code block must start with a cd line so the operator is placed in the correct working directory before the script runs.

Required opening pattern:

cd C:\dev

$ErrorActionPreference = "Stop"

The script must:

  1. Use explicit local paths.
  2. Use explicit official source URLs.
  3. Use the remote Git repository SSH remote for the CTX repository.
  4. Remove temporary source checkout folders before cloning.
  5. Create required destination folders.
  6. Download or clone official source material.
  7. Copy only the selected files and folders into the CTX repository.
  8. Capture upstream commit hashes when using Git sources.
  9. Ensure the local CTX folder is a Git repository.
  10. Ensure the origin remote is set correctly.
  11. Stage all resulting changes.
  12. Commit only if content changed.
  13. Use a clear verbose Git commit body.
  14. Push changes to the remote Git repository.
  15. Remove temporary source checkout folders.
  16. End with git status.

The script must not store SSH keys, passphrases, API keys, SMTP credentials, vendor secrets, company secrets, service secrets, environment files, or application configuration secrets.

Git authentication must rely on the operator's existing local SSH configuration.

8. Commit Message Standard

CTX refresh commits must use a clear subject and a detailed commit body.

The subject should use this pattern:

Update <Product> documentation context

For initial population, this subject is acceptable:

Add <Product> documentation context

The commit body must include these sections:

Changed behavior:
Source:
Operational context:
Validation performed:

The Source section must identify each official source used and include upstream commit hashes when available.

The Operational context section must explain why the CTX repository exists and how it supports local review, AI-assisted development tools access, future documentation indexing, and future MCP/RAG workflows.

The Validation performed section must state what the script downloaded, cloned, copied, staged, committed, and pushed.

9. Cheat-Sheet Script Standard

The cheat-sheet script must be the repeat-safe refresh script.

Do not maintain a separate simplified cheat-sheet script that does something different from the formal admin document-library script. The operator-facing cheat-sheet block and the formal Markdown document's PowerShell script must stay aligned.

If the script is updated in one place, it must be updated in both places.

The cheat-sheet block exists for fast manual use. The formal Markdown document exists for durable human, employee, AI-agent, AI-assisted development tools, automation, and MCP/RAG reference.

10. AI Agent Infrastructure Operating Standard

When an AI agent is asked to create a new third-party vendor CTX repository, the agent must follow this infrastructure sequence:

  1. Identify the product name and the way the service uses the product.
  2. Determine the lowercase kebab-case repo slug.
  3. Create or request creation of the remote Git repository using the ctx-<product> naming standard.
  4. Set the remote Git repository description using the CTX repository description standard.
  5. Create or use the matching local folder under C:\dev.
  6. Identify official vendor source locations.
  7. Build a repeat-safe PowerShell refresh script.
  8. Ensure the PowerShell script begins with cd C:\dev.
  9. Run or provide the script to populate the local CTX repository.
  10. Commit and push the populated repository to the remote Git repository.
  11. Confirm that the local branch is up to date with origin/main.
  12. Confirm that git status shows a clean working tree.
  13. Hand off to the documentation process defined in CTX Repository Documentation Standard.

The AI agent must not assume that a normal git pull from the CTX repository refreshes vendor content. A normal git pull only updates the local copy from the configured remote Git repository. The repeat-safe refresh script is required to pull current official vendor material into the CTX repository.

11. Human Operator Infrastructure Workflow

The human operator workflow is:

  1. Decide that a third-party vendor's documentation or SDK reference material should be preserved locally.
  2. Confirm why the service uses that product.
  3. Create the remote Git repository with the ctx-<product> naming standard.
  4. Set the remote Git repository description.
  5. Run the initial population script.
  6. Confirm that the repository pushed to the remote Git repository.
  7. Confirm that git status shows a clean working tree.
  8. Save the repeat-safe PowerShell script to the cheat-sheet code list.
  9. Use the CTX repository as the first reference source when assigning implementation work to AI-assisted development tools or AI agents.
  10. Complete the documentation workflow defined in CTX Repository Documentation Standard.

12. Infrastructure Validation Checklist for a New CTX Repository

A new CTX repository is infrastructure-complete only after all of the following are true:

  1. The remote Git repository exists.
  2. The remote Git repository uses the ctx-<product> naming standard.
  3. The remote Git repository description explains what the repo contains, how it updates, and where the official docs live.
  4. The local repository exists under C:\dev.
  5. The local repository uses lowercase kebab-case.
  6. The remote Git repository uses the approved SSH alias or approved remote URL.
  7. The repository has been populated from official vendor sources.
  8. The repository has been committed.
  9. The repository has been pushed to the remote Git repository.
  10. git status shows a clean working tree.
  11. git log --oneline -1 shows the expected CTX commit.
  12. The cheat-sheet PowerShell block exists.
  13. AI agents are instructed to search the local CTX repository first before searching outward.

13. Existing CTX Repository Examples

Current completed CTX repositories include:

C:\dev\ctx-better-auth
C:\dev\ctx-brevo
C:\dev\ctx-resend

Their current remote Git repositories are:

git@gitlab-sudostac:sudostac/ctx-better-auth.git
git@gitlab-sudostac:sudostac/ctx-brevo.git
git@gitlab-sudostac:sudostac/ctx-resend.git

Their formal admin document-library files are:

ctx-better-auth-repo-update.md
ctx-brevo-repo-update.md
ctx-resend-repo-update.md

These examples should be used as the model for future third-party vendor documentation context repositories.

14. Related Repositories

This document concerns the CTX repository infrastructure creation and maintenance process.

It is related to:

C:\dev\admin
C:\dev\site
C:\dev\news
C:\dev\server
C:\dev\ctx-better-auth
C:\dev\ctx-brevo
C:\dev\ctx-resend

The CTX repositories are reference repositories. They do not define the production implementation itself. Product implementation belongs in the applicable service application repository.