Document Scope
The service uses a modular multi-repository workspace instead of one monolithic Git repository.
This document defines the higher-level organization of the local development workspace. It explains what the workspace root is, how to refer to that root in a way that can survive a later move from Windows to Linux, what each major top-level folder is for, which folders are separate Git repositories, how those repositories relate to one another, where the standing documentation library lives, how ChatGPT Project Sources relate to repository documentation, how humans and AI agents should decide which repository to work in, and which assumptions must not be made when working across the workspace.
This document is written for human operators, employees, ChatGPT sessions, Codex sessions, AI-assisted development tools, automation workers, and future MCP/RAG workflows. Its purpose is to provide enough context that a future session can understand the workspace structure without requiring the user to re-explain the project layout.
This document does not define a repository rename task, a product rename, a public website copy standard, a backend refactor, a deployment process, a Cloudflare resource naming standard, or a database naming standard. It is limited to the organization of the local SaaS workspace and the rules for working safely inside a modular multi-repository project.
Standard
Document Type: Workspace Infrastructure Standards Document Applies To: Local development, repository navigation, AI-agent onboarding, Codex sessions, ChatGPT handoffs, Git workflows, internal documentation, workspace-level reasoning, and future MCP/RAG context use. Status: Authoritative project standard unless later superseded by a newer dated standards document. Primary Purpose: Define how the local SaaS project workspace is organized so humans and AI agents understand that the project is made of multiple separate Git repositories under one workspace root, not one monolithic repository.
1. Workspace Root
The workspace root is the top-level folder that contains the separate repositories and support folders that make up the broader SaaS project.
For this document, the workspace root is represented as:
<workspace-root>
The current workspace root on the Windows Server machine is:
C:\dev
This Windows path is the current machine-specific value of <workspace-root>. It is not intended to be a permanent hard-coded standard for all future machines.
The workspace may later move to a Linux computer or Linux VPS. When that happens, <workspace-root> will point to whatever top-level directory is chosen on that Linux system. The folder names and repository relationships should remain conceptually the same even though the absolute path and operating-system path separators may change.
Examples:
Current Windows machine:
<workspace-root> = C:\dev
Possible future Linux machine:
<workspace-root> = /srv/app-workspace
The exact future Linux path is not defined by this document. The important rule is that the top-level workspace should be discussed and documented as <workspace-root> unless a task specifically requires the current machine's literal path.
Use <workspace-root> throughout durable documentation, AI-agent handoffs, project standards, and repository-boundary explanations.
Use the current literal path only when writing a machine-specific command, a machine-specific setup instruction, or a diagnostic note that must be run on the current Windows Server machine.
Do not assume that <workspace-root>/app is the entire project. It is the core application repository, but it is only one repository inside the larger workspace.
The broader project includes multiple repositories with separate purposes, including the core backend application, the public website, the internal admin site, server/environment configuration, and local context/documentation repositories.
2. Path Notation Standard
Durable documentation should use this placeholder form:
<workspace-root>/repository-or-folder
Examples:
<workspace-root>/app
<workspace-root>/admin
<workspace-root>/site
<workspace-root>/server
<workspace-root>/ctx-cloudflare
This notation is intentionally operating-system neutral. It explains the logical location of a folder relative to the workspace root without locking the document to a Windows-only absolute path.
When a human operator or AI agent needs to run an actual command, convert the placeholder to the correct local path for the current machine.
Current Windows examples:
<workspace-root>/app means C:\dev\app
<workspace-root>/admin means C:\dev\admin
<workspace-root>/site means C:\dev\site
<workspace-root>/server means C:\dev\server
Possible Linux examples:
<workspace-root>/app could mean /srv/app-workspace/app
<workspace-root>/admin could mean /srv/app-workspace/admin
<workspace-root>/site could mean /srv/app-workspace/site
<workspace-root>/server could mean /srv/app-workspace/server
Do not edit durable documentation merely to replace one absolute workspace path with another. Define <workspace-root> once for the current machine, then refer to repository locations relative to <workspace-root>.
If a command must be written for a specific operating system, make that clear in the text immediately before the command.
3. Workspace Model
Many developers put an entire application into one large Git repository. This project does not use that model.
Instead, the project uses several smaller Git repositories that are cloned into the same local parent folder.
Each major repository has its own role. The repositories are designed to work together, but they should not be collapsed into one folder, casually merged, or treated as interchangeable.
The working model is:
<workspace-root>
├── app core SaaS application/backend repository
├── admin internal admin/operator repository and Command Center document library
├── site public customer-facing website repository
├── server machine/server/environment repository
├── ctx-* read-only vendor/tool context repositories
└── tmp global scratch folder
When working in this environment, always identify which repository you are in before editing files, running commands, creating commits, or interpreting documentation.
This rule matters because a command that is correct in one repository may be wrong in another. A clean Git status in one repository does not mean the whole workspace is clean. A branch name in one repository does not imply that another repository is on the same branch. A file path under one repository does not automatically belong in another repository just because both repositories support the same larger service.
3.1 Repository Classification Layer
The workspace layout identifies where repositories live. The Repository Classification Standard identifies what each repository is allowed to affect and which workflow standards apply to it. Both concepts are required.
A top-level folder under <workspace-root> is not just a path. If it is a Git repository, it must be understood by class before work begins. The current examples are:
app Class A deployable application repository
site Class A deployable application repository
admin Class A deployable application repository
server Class E infrastructure repository, with possible Class A characteristics depending on task scope
ctx-* Class C context/reference repositories
These examples are not exhaustive. Future repositories may be Class A, Class B, Class C, Class D, Class E, Class F, Class G, or multi-class repositories. The repository class determines validation depth, CI/CD expectations, required state folders, supply-chain governance, release records, and commit-message content. Do not infer class from name alone when the affected files suggest a different operational role.
4. Current Top-Level Workspace Layout
The current top-level layout is:
<workspace-root>
├── .wrangler
├── admin
├── app
├── ctx-authentik
├── ctx-better-auth
├── ctx-brevo
├── ctx-cloudflare
├── ctx-obsidian
├── ctx-resend
├── server
├── site
├── tmp
└── backup.lnk
Each folder has a distinct purpose. Do not assume that a file belongs in app merely because it relates to the SaaS project.
Some folders are active Git repositories. Some folders are local tooling state. Some folders are scratch or shortcut material. A future assistant must inspect the folder purpose before deciding whether it is safe to modify anything inside it.
The layout above is the current Windows Server layout expressed in workspace-root notation. If the workspace later moves to Linux, the top-level folder names may remain the same while the absolute root path changes.
5. Repository and Folder Purposes
app
This is the core SaaS application/backend repository.
Purpose: backend application code, processors, workers, databases, ingestion, Telegram logic, subscription logic, monitoring, and related operational code.
This repository is central to the project, but it is not the whole project. Other repositories may refer to it, support it, display information from it, or provide infrastructure around it.
When a task concerns backend processing, application runtime behavior, database workflows, monitoring scripts, ingestion logic, Telegram posting, operations workers, or application-level automation, app is usually the first repository to inspect.
The app repository should not be treated as the public website repository. It should not be treated as the internal admin repository. It should not be treated as the machine/server-environment repository. It owns the core application behavior, not every file or document related to the broader project.
Logical location:
<workspace-root>/app
admin
This is a separate Git repository.
Purpose: internal company/admin website for operator, employee, and AI-agent workflows.
This repository may contain internal dashboards, company documentation, report links, report outputs, non-public operational UI, and internal workflow tools. It is expected to sit behind access controls.
Do not confuse admin with the public customer website. It is for internal operations, not ordinary customer-facing marketing.
Be careful with any public folder in admin. A public folder may still contain content that should not be casually rewritten unless the task specifically calls for it.
When a task concerns internal documents, internal dashboards, operator pages, internal report access, private work surfaces, internal navigation, AI-agent work pages, or protected administrative tooling, admin is usually the relevant repository.
Logical location:
<workspace-root>/admin
Command Center documentation source and rendered output:
<workspace-root>/admin/docs_source
<workspace-root>/admin/public/docs
Important documentation paths:
<workspace-root>/admin/docs_source
<workspace-root>/admin/public/docs
docs_source contains Markdown source files for the internal Command Center document library.
public/docs contains browser-rendered or published documentation output used by the Command Center local preview.
Current Windows paths:
C:\dev\admin\docs_source
C:\dev\admin\public\docs
The current local Command Center documentation route is:
http://127.0.0.1:42000/docs/
The stable AI startup Markdown files numbered 01 through 15 are also mirrored into ChatGPT Project Sources for faster ChatGPT onboarding. The Project Sources are the convenient ChatGPT access layer. The admin repository remains the local repository location for the source and rendered documentation library.
Codex and local AI coding tools with workspace access should use the repository files directly. ChatGPT sessions inside the ChatGPT Project should use the Project Sources for the stable baseline startup documents and current-chat uploads for task-specific handoffs.
Do not treat ChatGPT Project Sources as a replacement for repository source control. Durable documentation changes should still be made to the Markdown source files in the appropriate repository and then committed through the normal branch-first Git process.
site
This is a separate Git repository.
Purpose: public customer-facing website.
This repository is where customers can learn about services, log in, view dashboards, sign up, cancel, and make payments.
When a task concerns customer-facing pages, public website copy, pricing display, account pages, subscription pages, checkout flows, cancellation flows, or public service descriptions, site is usually the relevant repository.
Do not casually change product wording in site. Public-facing wording should be handled deliberately.
This repository should not receive internal admin tools merely because they are web pages. If a page is meant for operator or employee use, it likely belongs in admin, not site.
Logical location:
<workspace-root>/site
server
This is a separate Git repository.
Purpose: machine/server-environment configuration and supporting operational material.
This repository may include current Windows setup, future Linux VPS setup, startup scripts, scheduled-task exports, Cloudflare tunnel configuration, bootstrap scripts, machine notes, environment documentation, and operational support files.
This repository is not the core application runtime, but it may contain active or future operational references used to run the project.
Use server when a task concerns machine setup, local development environment setup, server migration, scheduled tasks, startup behavior, tunnel configuration, or environment-level automation.
Do not treat server as a dumping ground for application code. It is for environment and machine operations material.
Logical location:
<workspace-root>/server
ctx-* repositories
Each folder beginning with ctx- is a separate context/reference repository.
Known context repositories include:
ctx-authentik
ctx-better-auth
ctx-brevo
ctx-cloudflare
ctx-obsidian
ctx-resend
Purpose: local documentation mirrors for third-party vendors, tools, or services used in the project.
These repositories exist so an assistant or coding agent can consult local documentation without relying only on memory or internet search.
Treat these repositories as read-only reference material unless the user explicitly asks to update them.
Do not modify ctx-* repositories during ordinary application, website, admin, or server work.
A normal task involving a vendor or tool may require reading the matching ctx-* repository. Reading is not the same thing as modifying. The default rule is to inspect these repositories as local reference material, not to patch them.
Logical locations:
<workspace-root>/ctx-authentik
<workspace-root>/ctx-better-auth
<workspace-root>/ctx-brevo
<workspace-root>/ctx-cloudflare
<workspace-root>/ctx-obsidian
<workspace-root>/ctx-resend
.wrangler
This is Cloudflare/Wrangler local cache and tooling state.
Do not modify this folder unless the user specifically gives a Cloudflare/Wrangler maintenance task that requires it.
Logical location:
<workspace-root>/.wrangler
tmp
This is a global scratch folder under <workspace-root>.
Do not use it for repo-specific temporary files when working inside a repository.
For repo-specific work, use that repository's own lowercase tmp folder.
Examples:
<workspace-root>/app/tmp
<workspace-root>/admin/tmp
<workspace-root>/site/tmp
<workspace-root>/server/tmp
Use repo-local tmp folders for helper scripts, verification output, inventories, temporary reports, generated patch files, and other task-specific scratch material.
backup.lnk
This is a Windows shortcut to the user's backup program.
Do not modify it.
Because backup.lnk is Windows-specific, do not assume it will exist in the same form after a future Linux move.
Logical current location:
<workspace-root>/backup.lnk
6. Review and Archive Material
Some older folders that used to sit directly under <workspace-root> have been moved into:
<workspace-root>/server/_review_required
Those folders include:
_news-doc_revamp
_news_image_capture
_news_roadmap_removed
_reusables
Treat these as inactive review/archive material.
Do not patch, reorganize, or rely on them as active application folders unless the user specifically instructs you to inspect them.
The presence of a folder under _review_required does not mean it is part of the current active runtime, current documentation source, current website, or current application layout. It means the material has been retained for review.
7. ChatGPT Project Sources and Command Center Documentation
The stable AI startup documents are maintained in two useful access forms.
The repository source form lives in the admin repository:
<workspace-root>/admin/docs_source
The browser-rendered Command Center form lives under:
<workspace-root>/admin/public/docs
The current local browser route is:
http://127.0.0.1:42000/docs/
The ChatGPT Project Source form lives inside the ChatGPT Plus project created for this workstream. It currently contains the stable baseline startup Markdown documents numbered 01 through 15.
These three access forms serve different users:
ChatGPT Project Sources
standing baseline context for ChatGPT sessions
<workspace-root>/admin/docs_source
Markdown source of truth for local documentation work
<workspace-root>/admin/public/docs
rendered browser-readable Command Center documentation
Codex workspace access
direct access to repository files under <workspace-root>
The task-specific handoff is not part of the stable Project Source set because it changes for each task session. The current chat should provide the task-specific handoff and any current logs, screenshots, repository status, terminal output, or supporting files.
When updating stable startup documentation, update the Markdown source file in the repository, then replace or refresh the corresponding ChatGPT Project Source file so future sessions receive the current version.
Do not assume that updating a ChatGPT Project Source alone updates the repository copy. Do not assume that generated HTML under public/docs is the Markdown source.
7.1 Stable Startup Document Set
The stable startup document set currently consists of documents 01 through 15. The task-specific handoff is separate. It may be presented as item 16 in a reading sequence, but it is not a standing standards document and should not be maintained as part of this baseline set.
The repository classification and supply-chain standards are now part of the baseline startup context. Future AI sessions must read them before applying repository-specific validation, CI/CD, Git checkpoint, Codex, or commit-message workflows.
8. GitLab Repository Model
The GitLab namespace is:
sudostac
Relevant repositories include:
sudostac/admin
sudostac/app
sudostac/ctx-authentik
sudostac/ctx-better-auth
sudostac/ctx-brevo
sudostac/ctx-cloudflare
sudostac/ctx-obsidian
sudostac/ctx-resend
sudostac/echo
sudostac/server
sudostac/site
Each repository has its own Git history and should be handled separately.
Before giving Git commands, making commits, or interpreting git status, confirm which repository is being used.
Do not assume that a branch, commit, remote, or working-tree status in one repository applies to any other repository.
This is especially important for multi-repository work. A future assistant must not prepare a commit message that mixes unrelated changes from separate repositories unless the user explicitly asked for a coordinated multi-repository change plan.
9. echo Backup Repository
There is also a GitLab repository named:
echo
Purpose: backup program repository.
Its working code is not currently under <workspace-root>. Only backup.lnk appears under <workspace-root> on the current Windows Server machine.
Do not modify echo unless the user specifically asks for backup-program work.
Do not infer that backup.lnk means the backup program source is present in the current workspace. It is only a shortcut.
10. Product Naming and Repository Naming
The project includes a customer-facing product/service called News.
The repository named app is the broader core application repository. It does not mean that the News product has been renamed.
Keep these concepts separate:
app = technical core application repository
News = customer-facing product/service concept
Do not globally rename product wording.
Do not change customer-facing News language merely because a folder or repository is called app.
Do not rename Cloudflare resources, database names, service names, or public product wording unless the user explicitly asks.
Protected examples include:
News product
news feed
news headline
news service
news database
news DB
News subscription service
jh-news-stage
jh-news-prod
jh-news-* Cloudflare/D1 resources
database names containing jh-news
customer-facing News wording
public website News wording
admin/public product wording
This distinction is permanent. Repository names and product names are not the same thing. A technical repository may be named for its architectural role while the product retains its own public name.
11. How to Decide Which Repository to Work In
Use the task type to choose the repository.
For backend runtime, processors, workers, monitoring, databases, ingestion, Telegram delivery, subscription logic, or application automation, start with:
<workspace-root>/app
For public website pages, pricing pages, checkout/customer flows, public documentation, and customer-facing service descriptions, start with:
<workspace-root>/site
For internal dashboards, admin tools, internal reports, operator workflows, non-public UI, Command Center documentation, and Daily Routine / AI Training source documents, start with:
<workspace-root>/admin
For machine setup, server migration, scheduled tasks, startup scripts, Cloudflare tunnel configuration, and environment notes, start with:
<workspace-root>/server
For vendor or tool documentation, inspect the relevant ctx-* repository as read-only reference material.
If a task crosses repository boundaries, handle each repository separately. Do not make a single combined commit across multiple repositories unless the user explicitly approves that workflow.
A future assistant should pause before touching more than one repository. Cross-repository changes may be valid, but they require deliberate handling because each repository has a separate Git history and separate operational purpose.
12. Repository Boundary Rules
The workspace boundary is <workspace-root>.
The repository boundary is each top-level Git repository inside <workspace-root>.
A task may involve the whole workspace conceptually, but actual file changes still happen inside one repository at a time.
Use these rules:
- Do not treat
<workspace-root>itself as one Git repository unless the user explicitly says it is. - Do not assume a top-level folder is safe to modify merely because it is under
<workspace-root>. - Do not move files between repositories unless the user explicitly asks.
- Do not merge repositories.
- Do not create cross-repository commits.
- Do not interpret
git statusfrom one repository as applying to the whole workspace. - Do not assume a branch name in one repository exists in another.
- Do not assume remotes use the same URL pattern without checking.
- Do not run a broad destructive command from
<workspace-root>. - Do not use a global search-and-replace across
<workspace-root>unless the user has expressly approved that exact scope.
These rules exist because the modular workspace gives the project cleaner separation, but it also requires more discipline. An agent that ignores repository boundaries can accidentally mix public website changes, internal admin changes, backend runtime changes, and server configuration changes into the same task.
13. No Guessing Rule
Do not guess the user’s intent.
Do not infer that product wording should change.
Do not infer that repository boundaries should be changed.
Do not infer that a file should move from one repository to another.
Do not infer that Cloudflare resource names should change.
Do not infer that database names should change.
Do not infer that public website copy should change.
Do not infer that backend application work should also include website, admin, server, or documentation changes.
Do not take leaps of faith.
When in doubt, stop and ask before changing files.
The no-guessing rule is especially important in this workspace because the same general concept may appear in multiple repositories. A phrase may appear in public website copy, internal admin documentation, backend code, server configuration, and context repositories for different reasons. Similar text does not mean the same change should be made everywhere.
14. Stop-and-Ask Triggers
Stop and ask the user before proceeding if you find:
1. A reference that could be either product wording or technical repository/path wording.
2. A Cloudflare resource, D1 database, Worker, R2 bucket, tunnel, or domain name that includes product-specific wording.
3. A public/customer-facing file where product wording appears.
4. An admin public-facing file where product wording appears.
5. A scheduled-task XML/export file that appears stale or machine-specific.
6. Any need to rename, move, or reorganize a folder outside the repository being worked on.
7. Any proposed change outside the scope of the current task.
8. Any failing test that is not clearly explained.
9. Any uncertainty about whether to patch a file or leave it alone.
10. Any situation where multiple repositories appear to need coordinated changes.
11. Any instruction or file that uses a literal machine path where a durable `<workspace-root>` path should be used instead.
Stopping to ask is not a failure. In this workspace, stopping is the correct behavior when a change may cross repository, product, public/private, infrastructure, runtime, or machine-specific path boundaries.
15. Working Style for Agents
Work incrementally.
Make small, reviewable changes.
Do not batch unrelated edits together.
Do not modify another repository simply because something looks outdated.
Do not perform broad search-and-replace operations across the whole <workspace-root> workspace.
Do not collapse repositories or assume the project should be reorganized into a monorepo.
Before making changes, identify:
1. Which repository is relevant.
2. Whether the task affects one repository or several.
3. Whether the file is active, public-facing, internal, reference-only, or archived.
4. Whether the change is clearly inside the user’s requested scope.
5. Whether a path should be written as a durable `<workspace-root>` reference or as a current-machine command path.
If a task requires investigation, start with read-only inspection. Do not edit while still discovering the boundaries of the task.
If a task affects multiple repositories, separate the work by repository in the explanation, validation, and commit guidance.
16. Temporary Output Rule
Use repo-local temporary folders for repo-specific work.
Examples:
<workspace-root>/app/tmp
<workspace-root>/admin/tmp
<workspace-root>/site/tmp
<workspace-root>/server/tmp
Do not write repo-specific helper files, generated reports, scans, inventories, or patch files to:
%TEMP%
Downloads
<workspace-root>/tmp
unless the user explicitly instructs it.
<workspace-root>/tmp is only a global scratch folder. It should not replace repo-local tmp folders for repository-specific work.
This rule matters because temporary files are often used for inventories, patch helpers, verification outputs, and migration reports. Those files need to stay near the repository they apply to so a later human or AI session can understand their context.
When writing durable documentation, use <workspace-root>/repository/tmp notation. When giving a machine-specific command, convert the placeholder to the correct path for the current operating system.
17. Git and Commit Rules
Each top-level project repository has its own Git status, branch, history, and remote.
Before suggesting edits, Codex work, staging, or a commit, confirm:
1. The exact repository path.
2. The current branch and whether it is safely off `main`.
3. Whether a task branch exists or must be created before file changes.
4. The files changed in that repository.
5. Whether other repositories were also touched.
Never work directly on main unless the user explicitly approves an emergency exception. Ordinary task work must happen on a named task branch.
Do not mix unrelated repository changes into one commit message.
Do not assume that because one repository is clean, the whole workspace is clean.
Do not push unless the user explicitly instructs it and the environment has the required access.
When preparing commit guidance, keep the repository boundary and branch state clear.
For this workspace, commit messages should be detailed enough to explain the scope of the work, the repository affected, the changed areas, validation performed, and intentional exclusions. Do not use a one-line commit message for meaningful project work unless the user specifically asks for one.
If multiple repositories were changed, prepare separate commit guidance for each repository unless the user asks for a coordinated release procedure.
Architectural Impact Review Requirement
Before any repository commit is treated as ready, the session must perform an Architectural Impact Review. This review is broader than CI/CD. It asks whether the work affected or exposed required changes to validation, dependencies, configuration, environment variables, runtime commands, database behavior, API contracts, frontend behavior, monitoring, operations records, documentation, runbooks, CI/CD, Docker, Kubernetes, deployment, backups, security, or future AI-agent workflows.
This review is action-oriented. If the review identifies an issue that can be fixed safely inside the current task scope, the assistant or coding agent should fix and validate it before the commit. If the issue cannot be fixed safely before commit, it must be recorded as a generated follow-up task with enough context for a future human, AI session, automation worker, or operations database process to act on it.
Every commit and merge commit must also answer this question in its own subsection:
Has this commit revealed a weakness, ambiguity, missing safeguard, or repetitive manual step in the project standards or workflows?
The answer must state whether the issue was fixed before commit or deferred as a structured follow-up. It must not be hidden inside a generic risk note.
18. Public, Internal, Backend, and Infrastructure Separation
The workspace separates different kinds of project work by repository.
Use this conceptual separation:
site = public customer-facing website
admin = private internal/operator/admin surface
app = core SaaS application/backend
server = machine, environment, startup, tunnel, and operational setup
ctx-* = local vendor/tool documentation reference
This separation should guide file placement and review.
Customer-facing content belongs in site unless the user says otherwise.
Internal operator content belongs in admin.
Backend runtime code belongs in app.
Machine and environment setup belongs in server.
Vendor/tool reference material belongs in the matching ctx-* repository.
Do not move content across these boundaries casually. If a file appears misplaced, flag it and ask before moving it.
19. Active Material Versus Reference or Archive Material
Not every file under <workspace-root> is active runtime material.
Before editing, determine whether the file is:
active code
active documentation
active operational instruction
public-facing content
internal-only content
reference-only material
generated output
temporary output
archived/review material
machine-specific export
This distinction matters because old documentation, archived review folders, generated files, and machine-specific exports may contain outdated references that should not be patched automatically.
A stale reference inside inactive material is not automatically a current project problem.
A current operational instruction inside active material is more important and should be handled carefully.
20. AI-Agent Use of Context Repositories
The ctx-* repositories are intended to help AI agents and AI-assisted tools answer implementation questions with better source material.
When a task involves a vendor or tool that has a matching context repository, an agent should usually inspect the local context repository first.
Examples:
Cloudflare task → <workspace-root>/ctx-cloudflare
Better Auth task → <workspace-root>/ctx-better-auth
Authentik task → <workspace-root>/ctx-authentik
Brevo task → <workspace-root>/ctx-brevo
Resend task → <workspace-root>/ctx-resend
Obsidian task → <workspace-root>/ctx-obsidian
The local context repository is a reference source. It does not own the production implementation.
For example, ctx-cloudflare may contain Cloudflare documentation, but the actual tunnel configuration or application integration may belong in server, admin, site, or app, depending on the task.
Do not confuse documentation context with implementation ownership.
21. Examples of Correct Repository Selection
If the task is:
Update the public pricing page.
Start with:
<workspace-root>/site
If the task is:
Add an internal report link to the operator dashboard.
Start with:
<workspace-root>/admin
If the task is:
Fix a feed processor runtime error.
Start with:
<workspace-root>/app
If the task is:
Update the Windows scheduled task wrapper.
Start with:
<workspace-root>/server
If the task is:
Check current Cloudflare Tunnel documentation before changing tunnel configuration.
Read:
<workspace-root>/ctx-cloudflare
Then modify the implementation repository that actually owns the tunnel configuration, if a change is required and within scope.
If a command must be run on the current Windows Server machine, convert the placeholder to the current Windows path before running the command.
22. Examples of Incorrect Assumptions
Do not assume:
The app repository is the whole project.
Do not assume:
A public website page belongs in app because it mentions the service.
Do not assume:
An internal admin dashboard belongs in site because it is a web page.
Do not assume:
A Cloudflare documentation repository owns the actual Cloudflare configuration.
Do not assume:
A search result under _review_required is active.
Do not assume:
The same branch exists in every repository.
Do not assume:
A clean git status in app means admin, site, and server are also clean.
Do not assume:
A product term should be renamed because a repository has a different technical name.
Do not assume:
A durable document should use C:\dev everywhere because that is the current Windows path.
23. Validation Expectations
When completing work in this workspace, validation should match the repository and task.
For most repository work, at minimum check:
git status --short
git branch --show-current
For code changes, use the relevant syntax, compile, test, import, or runtime checks for that repository.
For documentation changes, check that the Markdown or generated HTML still follows the document-library conventions and that frontmatter remains valid.
For website/admin changes, check the relevant local preview or build process when applicable.
For server/environment changes, check the specific script, config, scheduled-task wrapper, or tunnel reference affected by the task.
Do not run expensive live operations without asking.
Do not run broad monitoring, audit, or long-running application processes unless the user has approved that level of verification for the current task.
If validation output includes absolute paths, interpret them according to the current machine. Do not automatically rewrite durable documentation to match machine-specific validation output unless the document is intended to be machine-specific.
24. How Future Sessions Should Use This Document
A future human, ChatGPT session, Codex session, AI-assisted development tool, automation worker, or MCP/RAG workflow should use this document before making assumptions about the workspace.
The document should answer these initial questions:
1. What is <workspace-root>?
2. What is the current Windows value of <workspace-root>?
3. Is this project one Git repository or several?
4. Which repository owns backend application work?
5. Which repository owns public website work?
6. Which repository owns internal admin work?
7. Which repository owns server/environment work?
8. Which repositories are context/reference material?
9. What should not be renamed or modified without asking?
10. When should the agent stop and ask?
11. How should temporary files and Git commits be handled?
12. Where do ChatGPT Project Sources, Command Center documentation source files, and rendered browser docs fit?
13. How should durable documentation avoid hard-coding current machine paths?
14. Is the work on a named task branch rather than `main`?
If this document does not answer a repository-boundary question clearly, the correct next step is to ask the user rather than guess.
25. Summary for Future Chat Sessions
This project is a modular SaaS workspace under one workspace root.
In this document, that root is written as:
<workspace-root>
The current Windows Server value is:
C:\dev
It is made of multiple separate Git repositories, not one monolithic repository.
The core application backend is:
<workspace-root>/app
But the full project also includes separate repositories for:
<workspace-root>/admin
<workspace-root>/site
<workspace-root>/server
<workspace-root>/ctx-*
Treat each repository as separate. Inspect and modify only the repository or repositories that are actually relevant to the task. Use a named branch for every task; do not work directly on main without explicit emergency approval.
Do not rename product concepts, Cloudflare resources, database names, or public wording without explicit instruction.
Use <workspace-root> in durable documentation so the document does not need to be rewritten when the workspace later moves from Windows to Linux.
When uncertain, stop and ask.
26. Related Repositories
This document concerns the organization of the local SaaS workspace and the relationship among its top-level repositories.
Primary local workspace:
<workspace-root>
Current Windows Server value:
C:\dev
Core application/backend repository:
<workspace-root>/app
Internal admin/operator repository and Command Center documentation repository:
<workspace-root>/admin
Public customer-facing website repository:
<workspace-root>/site
Server/environment repository:
<workspace-root>/server
Context/reference repositories:
<workspace-root>/ctx-authentik
<workspace-root>/ctx-better-auth
<workspace-root>/ctx-brevo
<workspace-root>/ctx-cloudflare
<workspace-root>/ctx-obsidian
<workspace-root>/ctx-resend
Backup program repository:
sudostac/echo
The backup program repository is not currently present as working source code under <workspace-root>; only backup.lnk appears in the local workspace on the current Windows Server machine.
27. Maintenance Notes
This document should be updated when a top-level repository is added, removed, renamed, assigned a new durable purpose, or when the standing ChatGPT Project Source / Command Center documentation workflow changes.
Every substantive update should revise lastUpdated in the frontmatter.
Generated HTML, navigation, and search files should be treated as build artifacts if this Markdown file is published through the internal document library.
Do not treat status, searchable, or frontmatter metadata as access control. Access control belongs at the deployment, hosting, tunnel, authentication, or document-library protection layer.
This document should remain focused on workspace organization and repository boundaries. Do not turn it into a backend architecture guide, public website guide, server setup guide, Cloudflare tunnel guide, or product naming guide. Those topics may have their own documents.
This document should also remain portable. Do not reintroduce machine-specific absolute paths throughout the document. Define the current value of <workspace-root> once, then use <workspace-root> for durable references.