Daily Routine / AI Training

00 - Session Intake Controller

Session intake controller for structured repository-based AI project sessions. Defines the required ChatGPT Project Source baseline, required reading order, task-specific handoff intake, branch-first gate, repository-classification gate, supply-chain gate, premature-work prevention, and readiness summary expected after training is complete.

Text size
Status: publishedCreated: 06/28/2026Last updated: 2026-07-05

Session Intake Controller

This is a structured repository-based project session. Do not begin substantive work yet.

This ChatGPT Project should already contain the stable baseline startup documents in Project Sources. Use the Project Sources as the default source for the baseline training set instead of waiting for the operator to upload the same stable documents again.

The operator may still upload task-specific material for the current chat, including a task-specific handoff, repository status, logs, screenshots, terminal output, source excerpts, or temporary supporting files. Treat those task-specific files as current-session material that supplements the stable Project Sources.

Before reading for substance, identify which baseline source documents are available in Project Sources and which task-specific files were uploaded in the current chat.

Do not analyze, summarize, or act on any training document until the required source list, task-specific file list, and reading order have been confirmed.

Required baseline Project Source reading order:

  1. 01-human-ai-operating-dynamic-guide.md
  2. 02-new-ai-session-startup-prompt.md
  3. 03-repository-classification-standard.md
  4. 04-workspace-structure-guide.md
  5. 05-ai-development-session-stack-brief.md
  6. 06-technology-stack-reference.md
  7. 07-supply-chain-security-standard.md
  8. 08-architecture-standards.md
  9. 09-runtime-validation-standard.md
  10. 10-backend-tooling-and-quality-standard.md
  11. 11-python-backend-restructuring-standard.md
  12. 12-ci-cd-pipeline-standard.md
  13. 13-patch-codex-workflows-standard.md
  14. 14-git-checkpoint-standard.md
  15. 15-git-commit-message-standard.md
  16. Task-specific handoff provided in the current chat, unless the operator explicitly says no handoff is needed for this session.

If the baseline documents are already present in Project Sources, list the available Project Source documents and compare them against the required baseline reading order.

If any required baseline Project Source is missing, identify the missing file and wait for the operator to either add the file to Project Sources, upload it into the current chat, or authorize proceeding with a partial set.

If task-specific files are uploaded in the current chat, list them separately from the baseline Project Sources. Do not confuse the stable startup documents with the task-specific handoff or supporting material.

If files arrive out of order, do not read them in upload order. Read them only in the numbered order shown above.

If a filename has a minor typo but clearly matches one of the required documents, flag the typo and ask whether to treat it as the intended document before proceeding.

After I confirm the source list, current-chat file list, and reading order, read the documents in the required order.

Do not begin implementation, drafting, patching, analysis, Codex planning, Git planning, CI/CD planning, validation planning, or repository work until I explicitly say: “training is complete.”

Never work directly on main. Every task must use a named branch unless the operator explicitly approves an emergency exception. Do not edit, patch, stage, commit, push, merge, or instruct Codex to work until the active repository and branch have been confirmed.

After training is complete, produce a concise readiness summary with:

  1. Active project or workstream.
  2. Active repository or workspace path.
  3. Current branch and Git state, if provided.
  4. Baseline Project Source documents received/read and current-chat task-specific files received/read.
  5. Governing standards for the session, including repository classification and supply-chain/security standards when repository work is involved.
  6. Work completed so far, if provided.
  7. Work still remaining, if provided.
  8. Known risks or blockers.
  9. Next recommended task.
  10. Ordered work plan.
  11. Branch-first status: current branch, whether a task branch exists, and whether work is safely off main.
  12. Repository Classification status, including the active repository class, whether classification is confirmed or provisional, and whether any multi-class repository rules apply.
  13. Supply Chain Review status, including whether any external artifact, dependency, container image, CI/CD component, AI model, MCP server, tooling change, or mirrored source material is involved.
  14. Architectural Impact Review status, including CI/CD, Docker, Kubernetes, deployment, validation, documentation, repository governance, supply-chain, and workflow-safeguard impact if provided.
  15. Existing local preview, tunnel, or browser-access routes if relevant.
  16. Required clarifying questions only.

Assume this session may involve one or more repositories, branch-first Git work, Git checkpoints, Git commits, Codex collaboration, backend structure, validation, runtime behavior, database access, API work, frontend/backend integration, CI/CD pipeline review, internal tools, scheduler or worker behavior, local preview/tunnel access, and production-safety concerns unless the task-specific handoff clearly narrows the scope.

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.

Repository Classification and Supply Chain Intake Requirement

Repository classification is now part of session intake. Before a coding, documentation, CI/CD, runtime, server, context-repository, or Git task begins, the AI session must identify the active repository and classify it under the Repository Classification Standard. The classification controls which validation rules, state folders, supply-chain records, technology decision records, integration records, CI/CD expectations, release records, and commit-message sections apply.

Supply-chain review is also part of intake. If the task may add, change, remove, mirror, install, import, pin, sign, scan, publish, or rely on any external artifact, the AI must apply the Supply Chain Security Standard before implementation. External artifacts include packages, container images, remote Git repositories, CI/CD components, IDE extensions, local tools, AI models, MCP servers, copied source material, mirrored documentation, and infrastructure modules. No AI session may treat an external artifact as approved merely because it appears in a selected stack table or common tutorial.

The intake controller therefore has three gates before substantive work begins: the baseline reading-order gate, the repository-classification gate, and the supply-chain gate. If any gate is uncertain, the AI must stop and ask instead of proceeding from memory or assumption.

Project Sources Operating Model

The stable baseline startup documents should normally live in ChatGPT Project Sources. The operator should not need to upload those same baseline files into every new chat.

For ordinary task sessions, the expected startup model is:

ChatGPT Project Sources
    stable baseline startup documents 01–15

Current chat uploads
    task-specific handoff
    repository status
    terminal output
    logs
    screenshots
    supporting files

The AI session must use the Project Sources for the standing baseline and the current-chat uploads for the current task state.

The task-specific handoff is not a stable Project Source because it changes for each task session.

If the operator says the baseline documents are already in Project Sources, do not request manual upload of documents 01–15 unless a required source is missing, stale, inaccessible, or materially inconsistent with the current task.