I FLY AI - COMPLETE PROMPT PACK
The Know Code Academy
Book edition: Draft 3.0
Official library: https://knowcode.academy/iflyai/prompts

========================================================================
CHAPTER 3 PROMPT ALPHA - Begin the Installation
ID: 3-alpha | VERSION: 1.0 | DESTINATION: browser-based ChatGPT
========================================================================

I completed The Know Code Academy **I Fly AI — The Discovery Flight** at `https://knowcode.academy/iflyai/preflight`. The supported starting assumption is that the ChatGPT desktop app and Codex can run on this computer. Help me install the official ChatGPT desktop app, sign in through the official workflow, and open its Codex software-development experience.

Use the current official OpenAI instructions for my operating system. Call the installed product the ChatGPT desktop app. Distinguish download, installation, launch, sign-in, Codex selection, and successful entry into Codex.

Do not claim you can inspect or change the computer unless this conversation is running in an explicitly authorized surface that can do so. Ask only for the operating-system and permission information you need. Give me one small, safe step at a time, explain its expected evidence, and wait for my result.

Do not ask me to paste passwords, verification codes, recovery codes, tokens, cookies, private keys, or secret environment values. If the evidence conflicts with the starting assumption, stop and explain the exact boundary rather than guessing.

========================================================================
CHAPTER 4 PROMPT ALPHA - Use Chat in the Desktop App as Your Cockpit Instructor
ID: 4-alpha | VERSION: 1.0 | DESTINATION: Chat inside the ChatGPT desktop app
========================================================================

I completed The Know Code Academy **I Fly AI — The Discovery Flight** at `https://knowcode.academy/iflyai/preflight` and verified that Codex can run on this computer. Help me prepare the remaining cockpit for the *I Fly AI Flight Manual*.

You are not connected to this computer. Do not claim that you can inspect it, run commands, install software, change settings, or verify a result directly. Your role is to give me one small, safe instruction at a time. My role is to review the instruction, execute it on the computer, and return the actual non-secret output or other verifiable evidence. After every result, explain what the evidence proves, what remains unknown, and the next smallest safe action. Do not continue until I respond.

Work through the operating system and browser; installation authority; Git; Node.js and npm; the terminal or shell; confirmation that Codex opens; several gigabytes of workspace storage; permission to create files and directories; local development ports such as 8000; and reliable internet access. If a required tool is missing, guide me through its current official installation route one approved step at a time. Before each step, explain what it changes, what success should look like, and how to stop or recover safely.

If I say only that a step failed, do not guess that it succeeded and do not restart the entire process. Ask me for the exact visible error or the smallest safe diagnostic evidence, with secrets removed. Use that evidence to adjust the next instruction. If this is ChromeOS, verify Linux compatibility, application-installation permission, storage, and browser access to Linux development ports. Separate command evidence, other observable evidence, my statements, inference, and missing information. Never request passwords, authentication codes, tokens, cookies, private keys, or secret environment values. Finish with READY, CONDITIONALLY READY, or NOT READY, cite the evidence for each required tool, and provide exact corrective actions for anything unresolved.

========================================================================
CHAPTER 4 PROMPT BRAVO - Establish Account Ownership
ID: 4-bravo | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Act as my Codex tutor. Before planning or changing anything, determine which mission values must come from me and cannot reasonably be established from the current project.

This is a guided tutorial with approved mission values. In your follow-up message, give me the three completed lines below and instruct me to paste them back unchanged. Do not substitute different names or leave the values blank.

`OBJECTIVE=Build the sales dashboard`

`PROJECT=ElectronicsStoreRollUp`

`CONSTRAINTS=Use the existing technology stack`

After I reply, restate your interpretation and identify anything still missing or ambiguous. Do not plan, modify files, run mutating commands, or take external action until the required information is complete and I confirm your interpretation.

Once the values are confirmed, establish repository context, distinguish verified facts from inference, propose a plan before changing files, identify approval checkpoints, preserve the current technology stack unless a change is justified, run appropriate checks, and report evidence and limitations. Do not request credentials or invent files, architecture, test results, or permissions.

========================================================================
CHAPTER 4 PROMPT CHARLIE - Prepare Chat, Work, and Codex
ID: 4-charlie | VERSION: 1.0 | DESTINATION: Codex inside the ChatGPT desktop app
========================================================================

Treat this as a cockpit check. Do not change files, install dependencies, start services, or access external systems.

Explain which local workspace and Git repository this Codex project is centered on. Report the repository purpose, branch, working-tree state, remotes, and most recent commit when present. Explain what you can do locally, what would require my approval, and which credentials must never be provided in this conversation.

Distinguish verified facts from inference. End with one harmless read-only check I can authorize to prove that Codex is connected to the intended workspace.

========================================================================
CHAPTER 4 PROMPT DELTA - Obtain the Starter Aircraft
ID: 4-delta | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Help me plan my first Git repository transfer using the public Academy repository `https://github.com/BillHood/KnowCode-Academy-BasicWebSite`.

Before planning, ask me for my GitHub username. Instruct me to reply on one plain-text line beginning `GITHUB_USERNAME=`. Restate the username after I reply and wait for my confirmation.

Do not change files, create repositories, clone anything, or run a mutating command yet. Explain fork, clone, branch, commit, and push in plain language using this specific repository. Show which copy will belong to the Academy, which copy will belong to me on GitHub, and which copy will live on my computer. Explain why Download ZIP is not sufficient for the complete mission.

Verify only the non-sensitive local Git configuration and GitHub authentication state needed for this transfer. Do not display or request passwords, tokens, cookies, recovery codes, SSH private keys, or authentication codes. Identify every human approval checkpoint and finish with the next single action I should take in the GitHub interface.

========================================================================
CHAPTER 4 PROMPT ECHO - Obtain the Starter Aircraft
ID: 4-echo | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Before verifying my fork, ask me for my GitHub username and the HTTPS URL shown for the new fork. Instruct me to reply using two plain-text lines beginning `GITHUB_USERNAME=` and `FORK_HTTPS_URL=`. Restate both values and wait for my confirmation before continuing.

Verify without changing anything that the URL names my GitHub account and the expected repository. Explain what evidence confirms that this is my fork rather than the Academy repository. Identify the expected default branch and relationship to the public Academy source when that relationship is verifiable.

Do not clone yet. Do not change repository settings, visibility, branches, files, or upstream configuration. Finish with VERIFIED FORK, NEEDS REVIEW, or BLOCKED and explain the evidence.

========================================================================
CHAPTER 4 PROMPT FOXTROT - Obtain the Starter Aircraft
ID: 4-foxtrot | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Before planning the clone, ask me for the verified HTTPS URL of my fork and the full path of the approved parent folder. Instruct me to reply using two plain-text lines beginning `FORK_HTTPS_URL=` and `COURSE_PARENT_FOLDER=`. Restate both values and wait for my confirmation.

After confirmation, plan to clone my verified student-owned fork into the approved parent folder.

Begin read-only. Verify that the parent folder exists, is appropriate for course repositories, is not itself inside an unrelated Git repository, and does not already contain a conflicting `KnowCode-Academy-BasicWebSite` directory. Show me the exact `git clone` command and explain what it will create. Wait for my approval before running it.

After approval, run only the approved clone. Then enter the cloned repository and report its full local path, repository name, current and default branches, clean working-tree state, `origin` URL, latest commit, and whether `origin` belongs to my GitHub username. Do not create a branch, edit files, install dependencies, start the application, add an upstream remote, commit, or push yet. Finish with READY TO OPEN IN CODEX, NEEDS REVIEW, or BLOCKED.

========================================================================
CHAPTER 4 PROMPT GOLF - Obtain the Starter Aircraft
ID: 4-golf | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Verify the locally cloned `KnowCode-Academy-BasicWebSite` repository without changing files, installing dependencies, or starting services. Report its name, full local path, purpose, owner when verifiable, current and default branches, working-tree state, `origin` URL, latest commit, and whether `origin` belongs to my GitHub username.

Confirm whether the repository is ready for a future feature branch. Distinguish verified facts from inference and finish with READY, NEEDS REVIEW, or BLOCKED.

========================================================================
CHAPTER 4 PROMPT HOTEL - Verify Network and Local Runtime
ID: 4-hotel | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Conduct a bounded readiness flight in this approved training repository. Begin read-only: inventory the repository, verify the branch and clean working tree, identify the documented startup command, and propose one documentation-only readiness change.

Show the exact files, steps, checks, Git checkpoints, and cleanup before acting. Wait for approval before creating a feature branch or changing a file. Wait separately before staging, committing, or pushing. Do not merge, deploy, change credentials, or alter external resources.

After approval, create the feature branch, make the one approved documentation change, inspect the diff, run an existing lightweight check, and start the local application only when its documented dependencies are ready. Report the local URL or output, stop the process cleanly, and produce a short flight record containing verified evidence, limitations, and the next human decision.

========================================================================
CHAPTER 5 PROMPT ALPHA - Your First Codex Mission
ID: 5-alpha | VERSION: 1.0 | DESTINATION: Codex
========================================================================

You are my Codex engineering partner.

Our project is named **ElectronicsStoreRollUp**.

Our mission is to build the first version of an application that reads ten electronics-store CSV sales files, combines them, calculates company-wide sales results, and displays a simple management dashboard in a browser.

Before changing anything:

1. Establish the current repository and project context.
2. Inspect the relevant files, directory structure, documentation, data, and technology stack.
3. Report what you verified directly and clearly separate verified facts from assumptions or inference.
4. Identify important unknowns.
5. Ask only for information that cannot reasonably be answered from the project itself.

If information must come from me, collect all still-needed values in one follow-up message before proposing the implementation plan. Create concise, logical uppercase variable names using underscores, such as `DATA_FOLDER` or `LOCAL_PORT`, based on the actual unknowns you found.

Give me one editable plain-text `VARIABLE=value` line for each required value. When the repository or mission supports a reasonable default, place that suggested value after the equals sign and explain briefly why you suggest it. When no responsible suggestion can be made, leave the value blank and give me a short hint describing the information needed. Clearly label suggestions as suggestions rather than verified facts or approved choices.

Instruct me to review or replace every value and paste the completed lines as my next message. After I reply, restate your interpretation, identify anything still missing or ambiguous, and wait for my confirmation.

6. Only after the required information is complete and I confirm your interpretation, propose a short implementation plan before modifying files.

**Do not change files until you have presented the plan and I have approved it.**

Preserve the existing technology stack, project structure, and conventions unless a change is justified. Identify any significant architecture, dependency, configuration, or technology change as a separate approval checkpoint before making it.

Make the smallest reasonable changes needed for this mission. Avoid unrelated changes and preserve existing working behavior unless the mission requires otherwise.

The first version of **ElectronicsStoreRollUp** must:

- read ten electronics-store CSV sales files;
- combine them into one company-wide sales view;
- calculate useful company-wide sales totals;
- summarize sales by store;
- identify useful product or sales patterns supported by the data;
- display the results in a simple management dashboard;
- run locally and be viewable in a browser; and
- preserve the source CSV files unchanged.

Use only the available data as evidence. Do not hard-code results, invent business explanations, expose credentials, use production information, or add an external service unless I approve it.

During implementation, run appropriate tests, builds, checks, and other available verification. Never claim something works when it has not been verified. If something cannot be tested or verified, say so.

When you finish an implementation step, report:

- what changed;
- which files changed;
- what checks were run;
- evidence that the application works;
- how to start ElectronicsStoreRollUp locally;
- how to open it in the browser; and
- remaining limitations, risks, or unresolved issues.

Remember: **I am the Pilot in Command.** Present significant decisions before making them, distinguish evidence from inference, and wait for my approval of the plan before changing files.

========================================================================
CHAPTER 5 PROMPT DELTA - Cleared for Takeoff
ID: 5-delta | VERSION: 1.0 | DESTINATION: Codex
========================================================================

I have reviewed the proposed ElectronicsStoreRollUp implementation plan.

**Pilot approves the plan and authorizes the bounded build.**

Implement the smallest first version in controlled steps. Begin with CSV discovery, validation, ingestion, and deterministic calculations. Preserve all source CSV files. Separate analysis from presentation so the dashboard does not duplicate calculation logic.

Test valid files, missing or unexpected files, missing columns, invalid numeric values, blank required values, duplicates, and reconciliation failures relevant to the actual project. Company-wide totals must reconcile with store summaries and every displayed result must come from the data.

Then build the simplest local browser dashboard supported by the existing technology stack. Display useful company-wide totals, sales by store, and product or sales patterns supported by the data. Include clear errors and data limitations. Keep the interface readable, keyboard accessible, and responsive.

After each step, report what changed, files changed, checks run, results, limitations, and Git status. Stop for approval before any significant architecture, dependency, configuration, or technology change. Do not commit, push, merge, deploy, or alter an external system.

========================================================================
CHAPTER 5 PROMPT ECHO - Run ElectronicsStoreRollUp
ID: 5-echo | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Run ElectronicsStoreRollUp locally using the verified startup procedure. Do not change code merely to make the application start.

Report the exact command, local address and port, successful startup evidence, relevant warnings, and how to stop the process cleanly. Confirm that the application reads all ten expected CSV files and that no source file is modified.

If startup fails, diagnose the observed error, separate evidence from inference, and propose the smallest correction. Wait for approval before changing files or installing anything.

========================================================================
CHAPTER 5 PROMPT FOXTROT - Verify the Landing
ID: 5-foxtrot | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Verify ElectronicsStoreRollUp against the ten source CSV files and the approved mission. Do not change files during this review.

Run the complete available test suite and relevant build or quality checks. Reconcile company-wide totals with store totals. Confirm that displayed product or sales patterns are supported by calculated data and that results are not hard-coded. Verify the main browser path, readable errors, startup and shutdown, and documented acceptance criteria.

Compare the working branch with its starting state. Review the diff for unrelated changes, duplicated calculation logic, generated artifacts, credentials, security problems, accessibility issues, and unnecessary complexity.

Report files reviewed, commands, pass and fail counts, reconciliation evidence, runtime evidence, browser evidence, limitations, risks, unresolved issues, and Git status. Separate verified defects from optional improvements. Never claim the application works beyond the evidence gathered.

========================================================================
CHAPTER 5 PROMPT GOLF - Return to Git
ID: 5-golf | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Prepare ElectronicsStoreRollUp for preservation as a known-good version, but do not stage, commit, push, or merge yet.

Show the complete diff and explain every material change. Confirm that accepted source, tests, documentation, and the flight record are included, while credentials, caches, generated output, temporary files, source-data modifications, and unrelated changes are excluded.

Summarize the mission, starting state, files changed, calculations, tests, runtime and browser evidence, reconciliation, limitations, and remaining risks. Propose one concise commit message and wait for approval before staging.

After staging is separately approved, stage only the accepted files, show the staged diff and status, and wait again before committing. Do not push or merge.

========================================================================
CHAPTER 6 PROMPT ALPHA - Verify Before Installing
ID: 6-alpha | VERSION: 1.0 | DESTINATION: Chat inside the ChatGPT desktop app
========================================================================

Help me determine whether a supported Python 3 installation is already available on this computer. Do not pretend you can inspect or change the computer directly, install anything, or request an administrator password.

Ask whether I use Windows, macOS, or ChromeOS and whether the computer is personal or managed. Give me one safe command at a time to identify the operating system, processor architecture when relevant, Python launcher, version, executable location, and pip association. Explain successful evidence and wait for my result after every command.

Separate verified command evidence, my statements, inference, and missing information. Do not display environment-variable values, credentials, tokens, browser data, or unrelated software. Finish with PYTHON READY, INSTALLATION NEEDED, or ADMINISTRATOR REVIEW NEEDED.

========================================================================
CHAPTER 6 PROMPT BRAVO - Install Through an Official Route
ID: 6-bravo | VERSION: 1.0 | DESTINATION: Chat inside the ChatGPT desktop app
========================================================================

Python 3 was not verified. Using the platform evidence already gathered, guide me through the safest current installation from an official source. Prefer python.org or an approved operating-system package manager and cite the official page.

Explain the installer choice, supported version, architecture, PATH or launcher option, installation scope, administrator implications, expected disk use, verification, update path, and uninstall path. Do not download, execute, elevate, or change settings for me. Do not recommend an unofficial mirror, bundled stack, global third-party package, or disabled security control.

Pause while I complete the official installer privately. Then provide the smallest commands needed to verify Python, its executable location, and the pip instance associated with that interpreter.

========================================================================
CHAPTER 6 PROMPT CHARLIE - Ideate the First Python Flight in Chat
ID: 6-charlie | VERSION: 1.0 | DESTINATION: Chat inside the ChatGPT desktop app
========================================================================

Help me ideate my first Python application. I want a small command-line program that uses only the Python standard library, records a few safe facts about the verified Python runtime, and writes a JSON report inside its own repository.

Ask me one useful question at a time about the user, purpose, approved runtime facts, output filename and location, command-line behavior, privacy boundary, failure behavior, test expectations, and definition of success. The program must not inspect usernames, home-directory paths, environment-variable values, credentials, network configuration, browser information, unrelated files, or external services.

Do not write code, create a repository, or install a package. End with one concise project description I can review and carry into Work.

========================================================================
CHAPTER 6 PROMPT DELTA - Specify the Flight in Work
ID: 6-delta | VERSION: 1.0 | DESTINATION: Work inside the ChatGPT desktop app
========================================================================

Convert the approved project description below into a bounded Version 1 specification for a beginner Python application.

Define the user, objective, approved output fields, JSON schema, command-line interface, repository structure, source and generated files, privacy and filesystem boundaries, deterministic behavior, errors and exit codes, tests, startup command using the verified Python command, Git exclusions, acceptance criteria, and Definition of Done.

Use only the Python standard library. Require functions with clear responsibilities, explicit UTF-8 encoding, a main entry point, a generated report beneath an approved output directory, and tests using controlled temporary data rather than assumptions about the student's real computer. Do not write the implementation.

Before writing the specification, ask me for the approved project description. Instruct me to reply with `PROJECT_DESCRIPTION=` followed by the complete approved description on the same line or the following lines. Restate the description and wait for my confirmation before continuing.

========================================================================
CHAPTER 6 PROMPT ECHO - Prepare the Repository in Codex
ID: 6-echo | VERSION: 1.0 | DESTINATION: Codex inside the ChatGPT desktop app
========================================================================

Use the approved Work specification for this mission. Center the project on the intended `iflyai-python-check-ride` folder. Do not write application code yet.

Begin read-only. Report the full workspace path, whether it is already a Git repository, whether it contains files, whether it is nested inside another repository, the verified Python command and version when available, and any conflict with the specification. Do not search outside the approved workspace or display secret values.

Propose the smallest repository structure, files, functions, tests, commands, output boundary, `.gitignore`, feature-branch name, failure cases, and Git checkpoints. Explain how the code will remain testable without asserting the student's real operating-system values. Wait for Pilot approval before initializing Git, creating a branch, or writing files.

========================================================================
CHAPTER 6 PROMPT FOXTROT - Build, Test, and Run
ID: 6-foxtrot | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Pilot approves the Python flight plan. Initialize the repository when needed, establish the default branch and initial documentation state, create a clearly named feature branch, and implement only the approved Version 1 specification.

Add the program, automated tests, README, approved specification, `.gitignore`, and flight-log entry. Use only the Python standard library. Keep generated output out of Git.

Run the tests first. Then run the program with the verified Python command and inspect the JSON artifact. Report commands, test counts, approved fields, files changed, generated files, errors, limitations, Git status, and the exact rerun command. Do not stage, commit, push, or merge yet.

========================================================================
CHAPTER 6 PROMPT GOLF - Improve and Preserve the Landing
ID: 6-golf | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Propose one beginner-sized Version 1 improvement supported by the original mission, such as separating the Python major and minor version into numeric fields. Identify the specification change, code and test changes, expected JSON, failure cases, and acceptance criteria. Wait for approval.

After approval, update the specification first, implement only the approved increment, run focused and complete tests, rerun the application, and compare the artifact with the approved expectation.

Show the final Git diff and confirm that generated output, caches, credentials, and unrelated files are excluded. After separate approval, stage only the accepted source, tests, specification, README, ignore file, and flight log. Show the staged diff and wait again before committing. Do not push or merge.

========================================================================
CHAPTER 7 PROMPT ALPHA - Repository Possession Prompt Sequence
ID: 7-alpha | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Take possession of my fork of `KnowCode-Academy-BasicWebSite` as a read-only first step. Confirm that the repository’s `origin` points to my GitHub account and identify the original upstream repository. Then inventory the repository without changing it. Explain its purpose, entry points, architecture, data flow, dependencies, security boundaries, tests, startup procedure, and Git state. Cite exact files. Distinguish verified facts from inference.

========================================================================
CHAPTER 7 PROMPT BRAVO - Repository Possession Prompt Sequence
ID: 7-bravo | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Using the repository inventory, trace one representative user action from its entry point through user interface, route or handler, service logic, data access, external dependency, and returned result. Cite the exact files, functions, classes, and configuration involved.

Present the flow first in plain language and then as a compact sequence diagram. Mark authentication, authorization, validation, persistence, external calls, failure handling, and logging boundaries. Identify any step that is inferred rather than proven.

Do not run the application, change code, call external services, or inspect secrets unless I separately approve those actions.

========================================================================
CHAPTER 7 PROMPT CHARLIE - Repository Possession Prompt Sequence
ID: 7-charlie | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Produce a read-only control inventory for this repository. Identify commands and code paths that read data, write data, send messages, deploy, change permissions, modify infrastructure, delete resources, migrate schemas, rotate credentials, or otherwise create consequential external state.

For each control, report its entry point, authorization mechanism, configuration dependency, reversibility, likely blast radius, audit evidence, and whether human approval is currently enforced or merely assumed. Do not execute any of these controls.

Separate verified controls from inferred capabilities and list questions that must be answered by the repository owner.

========================================================================
CHAPTER 7 PROMPT DELTA - Repository Possession Prompt Sequence
ID: 7-delta | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Explain exactly how a new authorized engineer would prepare and start this repository locally without changing it.

Identify required language and tool versions, dependency manifests and lockfiles, environment variables by name but never secret value, databases, migrations, seed data, build steps, startup commands, ports, health checks, and shutdown procedure. Cite the files supporting each instruction.

Flag undocumented assumptions, platform-specific paths, globally installed tools, missing lockfiles, and steps that could contact production or incur cost. Do not install dependencies or start services yet. End with a proposed bounded startup checklist.

========================================================================
CHAPTER 8 PROMPT ALPHA - Baseline and Boundary Prompt Sequence
ID: 8-alpha | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Establish a reproducible baseline for this repository before implementing any feature.

First inspect the documented setup and propose the exact bounded commands needed to verify language and dependency versions, install or validate dependencies, prepare local data, run migrations, build, test, start, and perform a minimal health check. Identify commands that write files, alter data, contact external systems, or require credentials.

Wait for approval before running mutating setup steps. After approval, execute the checklist in order and record command, exit status, relevant counts, test results, local URL, runtime evidence, failures, and limitations. Do not repair a failure until the baseline report distinguishes an existing defect from an environment problem.

========================================================================
CHAPTER 8 PROMPT BRAVO - Baseline and Boundary Prompt Sequence
ID: 8-bravo | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Before defining the boundary, ask me for the complete requested change. Instruct me to reply with `REQUEST=` followed by the complete request. Restate the request and wait for my confirmation.

Then turn the confirmed request into an explicit in-scope and out-of-scope boundary.

Identify affected users, repositories, components, data, roles, environments, external systems, and operational actions. State what may be read, what may be changed, what must remain unchanged, and what requires a separate human approval.

List assumptions and unresolved choices that could materially change the implementation. Do not silently choose among them. Provide a short boundary statement that can be copied into the flight log and pull request.

========================================================================
CHAPTER 8 PROMPT CHARLIE - Baseline and Boundary Prompt Sequence
ID: 8-charlie | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Write measurable acceptance criteria for the approved mission before code changes begin.

Cover expected behavior, accessibility, data integrity, authentication, authorization, validation, error handling, performance appropriate to the mission, observability, and rollback. For every privileged success path, include the corresponding unauthenticated, unauthorized, cross-boundary, malformed-input, missing-resource, and failed-dependency behavior when applicable.

Map each criterion to proposed automated tests, runtime checks, browser evidence, or human review. Identify criteria that cannot yet be tested and explain why. Do not implement the tests or redefine business policy without approval.

========================================================================
CHAPTER 8 PROMPT DELTA - Baseline and Boundary Prompt Sequence
ID: 8-delta | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Compare the local development environment with the intended test or production environment without changing either one.

Examine documented runtime versions, configuration names without secret values, data sources, identity provider, database, object storage, network exposure, domains, certificates, background jobs, logging, monitoring, scaling, and deployment process. Cite repository and approved environment evidence.

Report matches, known differences, unverified assumptions, and differences that could make local success misleading. Do not copy production data or credentials into local development. Recommend the minimum safe parity needed for this mission.

========================================================================
CHAPTER 9 PROMPT ALPHA - Flight 01 Prompt Sequence
ID: 9-alpha | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Take possession of my fork of `KnowCode-Academy-BasicWebSite` as a read-only first step. Confirm that `origin` points to my GitHub account, identify `https://github.com/BillHood/KnowCode-Academy-BasicWebSite` as the Academy source, and report whether an `upstream` remote is configured. Do not change any files, add or alter remotes, install undeclared software, create a branch, commit, or push.

Determine the documented local startup procedure and check whether its required runtime is already available. Start the unchanged website on an available local port, preferring the port documented by the repository. Verify the homepage and its local CSS, JavaScript, and image assets return successfully.

Give me the exact local URL to open. Explain what the current site looks like, what interactions it provides, and which behaviors I should test in the browser. Report the server command, port, response evidence, and any limitations. Keep the local server running so I can inspect the starting aircraft.

========================================================================
CHAPTER 9 PROMPT BRAVO - Flight 01 Prompt Sequence
ID: 9-bravo | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Inventory and review this website repository without changing it. Cite exact file paths.

Identify:

- the page entry point;
- every HTML, CSS, JavaScript, and image asset used by the page;
- how those files reference and affect one another;
- the current layout and responsive behavior;
- every user interaction and any browser storage it uses;
- accessibility strengths and weaknesses;
- external dependencies or network requests;
- the local startup procedure;
- the current Git branch, remotes, status, and recent baseline commit;
- obsolete, unused, or misleading files;
- risks or constraints that should shape a bounded transformation.

Distinguish verified facts from inference. End with a concise architecture summary and a proposed verification checklist. Do not edit, stage, commit, push, or create a branch.

========================================================================
CHAPTER 9 PROMPT CHARLIE - Flight 01 Prompt Sequence
ID: 9-charlie | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Prepare an isolated workspace for the approved website mission.

First confirm that the current working tree contains no uncommitted or untracked work that would be accidentally included. Confirm the current branch and its relationship to the repository’s default branch. If the worktree is clean and the baseline is correct, create and switch to a new feature branch named `codex/summit-tech-works`.

Do not change application files, commit, push, merge, or open a pull request. Report the previous branch, new branch, baseline commit, and final Git status. If the worktree is not clean or the baseline is uncertain, stop and explain the issue rather than hiding or discarding anything.

========================================================================
CHAPTER 9 PROMPT DELTA - Flight 01 Prompt Sequence
ID: 9-delta | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Transform this website into a responsive site for a fictional company named **Summit Tech Works**. Work only on the current feature branch.

Preserve the existing technology stack: plain HTML, CSS, and JavaScript. Do not add frameworks, package managers, build tools, analytics, external services, or new runtime dependencies.

The completed site must include:

- an accessible header and navigation;
- a hero section with a clear business promise;
- four technology services;
- an about section;
- two clearly fictional testimonials;
- a consultation call-to-action;
- one useful JavaScript interaction;
- responsive desktop and mobile behavior;
- semantic landmarks, logical headings, keyboard focus, sufficient contrast, and reduced-motion support;
- an honest disclosure if a demonstration form does not transmit information.

Before changing files, provide a bounded implementation plan identifying every proposed file change, obsolete asset treatment, accessibility criteria, interaction behavior, misuse or failure cases, and desktop/mobile verification. Wait for the exact words **“Pilot approves the Summit Tech Works transformation”** before implementing.

After approval, implement only that plan. Run syntax and reference checks, inspect the site in a browser at desktop and mobile widths, exercise every interaction, check for horizontal overflow and browser errors, and show the complete Git diff. Do not commit, push, merge, or open a pull request until separately instructed.

========================================================================
CHAPTER 10 PROMPT ALPHA - Flight 02 Prompt Sequence
ID: 10-alpha | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Take possession of my fork of `KnowCode-Academy-AuthenticatedWebSite` as a read-only first step. Confirm that `origin` points to my GitHub account, identify `https://github.com/BillHood/KnowCode-Academy-AuthenticatedWebSite` as the Academy source, and report whether an `upstream` remote is configured. Do not change application files, add or alter remotes, create identities, alter the database schema, create a branch, commit, or push.

Inspect the documented local setup procedure and identify the required Python version, virtual environment, declared classroom dependencies, database, migrations, static-asset step, test command, and server command. Use the repository’s isolated virtual environment. Do not install global packages.

Establish the unchanged baseline in the documented order: install only declared local dependencies when needed, inspect migration status, apply pending migrations, collect static assets when required, run Django’s system check, and run the complete test suite. Start the application on `127.0.0.1:8000` unless that port is unavailable.

Verify the public homepage and login page return successfully. Verify that an anonymous request to the employee dashboard redirects to login. Give me the exact URLs for the homepage, login, and Django Admin. Report versions, commands, migration state, test counts, response evidence, and limitations. Keep the server running so I can inspect the starting aircraft.

========================================================================
CHAPTER 10 PROMPT BRAVO - Flight 02 Prompt Sequence
ID: 10-bravo | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Inventory and review this Django repository without changing it. Cite exact files and line-level locations when useful.

Explain:

- project and application structure;
- URL routing from request to view;
- models, relationships, migrations, and SQLite persistence;
- forms, templates, static assets, and administrator registration;
- login, logout, sessions, password validation, and CSRF protection;
- the difference between `is_authenticated`, application permissions, `is_staff`, and `is_superuser` in this application;
- public, employee, manager, and administrator capabilities;
- how employee records are filtered to their owner;
- how manager records are limited to teams they manage;
- every protected direct URL and its enforcement point;
- tests for successful, redirected, forbidden, not-found, and cross-user behavior;
- current Git branch, remotes, status, and baseline commit;
- any gap where presentation hides a link but the server does not enforce the same rule.

Produce a role-and-route matrix containing the expected result for anonymous visitors, employees, managers, and administrators. Distinguish verified facts from inference. Do not edit, migrate, seed, stage, commit, push, or create a branch.

========================================================================
CHAPTER 10 PROMPT CHARLIE - Flight 02 Prompt Sequence
ID: 10-charlie | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Guide me through creating local demonstration identities for Summit Operations Portal without receiving, choosing, displaying, storing, or committing any password.

Use Django’s interactive `createsuperuser` workflow for the administrator and stop while I enter credentials privately in my visible terminal. After the administrator exists, explain how I can use Django Admin to create one employee, one manager, two teams, and several fictional work requests. Explain how to grant the manager only `operations | work request | Can manage requests for assigned team` without granting `is_staff` or superuser status.

Provide a manual verification checklist for public, employee, manager, and administrator sessions. Do not create hard-coded credentials, seed real personal information, weaken password validation, or place the local database in Git.

========================================================================
CHAPTER 10 PROMPT DELTA - Flight 02 Prompt Sequence
ID: 10-delta | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Prepare an isolated workspace for the authenticated-application transformation.

Confirm the complete baseline test suite passes, migrations are current, the current branch is based on the repository’s default branch, and the working tree contains no uncommitted or untracked work that would be accidentally included. Remember that the ignored local SQLite database may contain demonstration identities and must not be staged.

If the baseline is correct and the worktree is clean, create and switch to `codex/summit-equipment-exchange`. Do not change application files, generate migrations, commit, push, merge, or open a pull request. Report the previous branch, new branch, baseline commit, migration state, test result, and final Git status. If any prerequisite is uncertain, stop and explain it.

========================================================================
CHAPTER 10 PROMPT ECHO - Flight 02 Prompt Sequence
ID: 10-echo | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Transform Summit Operations Portal into a fictional employee equipment-checkout application named **Summit Equipment Exchange**. Work only on the current feature branch.

Preserve Python, Django, SQLite, session authentication, CSRF protection, password validation, Django Admin, explicit application permissions, database history, responsive accessibility, and the separation between business roles and `is_staff`.

Map the domain so that work requests become equipment checkouts, employees see only their assigned assets, equipment coordinators see only checkouts for teams they coordinate, and administrators govern identities, roles, teams, equipment, and assignments. Visitors may view available equipment but no private checkout records.

Before changing files, provide:

1. A file-by-file implementation plan.
2. The proposed model and relationship mapping.
3. Data-preserving migration operations and rollback considerations.
4. The exact permission codenames and enforcement locations.
5. A role-and-direct-URL matrix.
6. Misuse cases, including URL identifier changes, cross-team access, unauthorized POST requests, invalid dates, missing assets, and accidental administrator access.
7. Tests proving successful, redirected, forbidden, not-found, cross-user, cross-team, and unchanged-database behavior.
8. Desktop and mobile browser verification.
9. Explicit exclusions and limitations.

Do not implement until I say **“Pilot approves the Summit Equipment Exchange transition.”**

After approval, implement only the approved plan. Generate data-preserving migrations, run Django’s system check, verify there is no unrecorded migration drift, run the complete test suite, migrate the local database, collect static assets, and start the transformed application on the same local port. Test the four roles and direct protected URLs. Show the complete Git diff and report successful paths, denied paths, record counts, migration evidence, browser evidence, and limitations. Do not commit, push, merge, or open a pull request until separately instructed.

========================================================================
CHAPTER 10 PROMPT FOXTROT - Flight 02 Prompt Sequence
ID: 10-foxtrot | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Prepare this completed transformation for human review without merging it.

Re-run the system check, migration-drift check, complete tests, and targeted authorization tests. Confirm that no database, password, token, `.env` file, generated secret, or unrelated change is staged. Summarize the business transformation, authentication boundary, authorization boundary, data migration, successful paths, denied paths, browser verification, and limitations.

Show me the proposed commit scope and pull-request narrative. Wait for Pilot in Command approval before staging, committing, pushing, or opening a pull request.

========================================================================
CHAPTER 11 PROMPT ALPHA - Flight 03 Prompt Sequence
ID: 11-alpha | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Inspect this repository without changing it. Determine whether the site can be published by GitHub Pages as static HTML, CSS, JavaScript, and browser assets.

Identify its entry page, asset paths, build command when present, generated output directory, client-side routing, environment variables, server dependencies, secrets, forms, APIs, and features that cannot work on static hosting. Cite exact files and distinguish verified facts from inference.

Report READY FOR STATIC HOSTING, NEEDS A BOUNDED CHANGE, or NOT SUITABLE FOR GITHUB PAGES. Do not modify files, install dependencies, publish, or change repository settings.

========================================================================
CHAPTER 11 PROMPT BRAVO - Flight 03 Prompt Sequence
ID: 11-bravo | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Prepare a bounded GitHub Pages publication plan for this verified static website. Do not change files or GitHub settings yet.

Compare publishing from an approved branch with publishing through a GitHub Actions workflow. Recommend the simplest method supported by the actual repository. Identify the source branch, build command if any, output directory, base-path requirements, generated files, repository setting, public URL shape, verification checks, rollback, and evidence required.

List every file you propose to create or change. Exclude custom domains, paid services, external analytics, advertising scripts, and secrets. Wait for the exact words **“Pilot approves the GitHub Pages flight plan.”**

========================================================================
CHAPTER 11 PROMPT CHARLIE - Flight 03 Prompt Sequence
ID: 11-charlie | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Pilot approves the GitHub Pages flight plan. Create a feature branch and implement only the approved publication changes.

Preserve the current plain HTML, CSS, and JavaScript stack. Correct verified relative-path or base-path problems, add the smallest required Pages configuration or workflow, and keep generated output out of source control unless the approved method requires it.

Run the existing tests and build. Start the production artifact locally when possible and verify the homepage, navigation, images, styles, JavaScript behavior, responsive layout, keyboard access, missing-page behavior, and browser console. Report files changed, commands, checks, failures, and limitations. Do not commit, push, merge, or enable Pages yet.

========================================================================
CHAPTER 11 PROMPT DELTA - Flight 03 Prompt Sequence
ID: 11-delta | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Show the complete diff and explain every publication-related change. Confirm that no credentials, tokens, private files, synthetic input data, generated reports, caches, or unrelated changes will be committed.

After separate approval, stage only the approved files, show the staged diff, commit, and push the feature branch. Prepare the pull request and identify the exact human review boundary. Do not merge until I approve.

After the approved merge, guide me through enabling GitHub Pages through the repository's official settings or approved workflow. Pause whenever browser authentication or a repository-setting decision is required. Do not request or display credentials or authentication codes.

========================================================================
CHAPTER 11 PROMPT ECHO - Flight 03 Prompt Sequence
ID: 11-echo | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Verify the GitHub Pages site from its public HTTPS URL. Confirm the deployed repository and commit when evidence is available; homepage; navigation; styles; images; JavaScript; responsive behavior; keyboard operation; missing-page behavior; browser console; and absence of mixed-content or missing-asset errors.

Compare the public result with the approved local production artifact. Diagnose differences before changing code. Produce the public URL, deployed commit, verification evidence, limitations, rollback steps, and a concise flight-log entry.

Do not add a custom domain, change visibility, delete deployments, or declare success when the public page is stale or incomplete.

========================================================================
CHAPTER 12 PROMPT ALPHA - Evidence Board
ID: 12-alpha | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Review this authenticated application’s authorization boundaries without changing code first.

Identify every protected view and its direct URL, required authentication state, required permission or role, and permitted data scope.

Then propose and implement authorization tests that call the protected URLs directly rather than relying only on whether navigation links are visible.

For each protected URL, test:

- An anonymous visitor is redirected to login or denied.
- An authenticated user without the required permission receives `403 Forbidden`.
- An authenticated user cannot access another user’s private record by changing the URL identifier.
- A manager cannot access records belonging to a team they do not manage.
- A properly authorized user can access the view.
- A superuser can access the view when appropriate.
- Unauthorized POST requests do not change the database.
- Missing records return `404` without exposing unrelated data.

Keep template tests that verify role-appropriate links are displayed or hidden, but treat those as presentation tests only. Enforce authorization in the server-side view.

Before implementing, provide:

1. A protected-route inventory.
2. The expected result for each role and route.
3. The test files you propose to change.
4. Any authorization weakness discovered in the current views.
5. The exact database state that must remain unchanged after denied requests.

Wait for Pilot in Command approval before changing files. After approval, implement the tests, run the complete test suite, and report successful paths, denied paths, failures, and limitations.

========================================================================
CHAPTER 13 PROMPT ALPHA - Git to Know Git
ID: 13-alpha | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Inventory the Git repositories available inside my current authorized workspace without modifying them or searching outside that workspace.

For each repository, report:

- repository folder and likely project purpose;
- current branch and default branch when discoverable;
- clean, modified, staged, or untracked working-tree state;
- configured remotes and the GitHub owner/repository they reference;
- public or private visibility when it can be verified through my authenticated GitHub session;
- whether the local branch is ahead of, behind, or diverged from its tracked remote;
- most recent commit date and message;
- any obvious ownership, naming, or organization issue.

Do not fetch, pull, switch branches, stage, commit, push, rename, delete, or change visibility. Present the result as a concise portfolio table and distinguish verified facts from inference.

========================================================================
CHAPTER 13 PROMPT BRAVO - Git to Know Git
ID: 13-bravo | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Teach me Git using this repository’s current real state. Do not change anything.

Explain the relationship among the working tree, staging area, commit, branch, local repository, remote repository, and pull request. Then interpret the output of `git status`, `git branch`, `git log`, and `git remote` for this repository in plain language.

Use one small hypothetical file change to show what would happen during edit, stage, commit, push, pull request, review, merge, and local synchronization. Explain what is recoverable at each stage. Identify commands that are read-only, commands that change local state, commands that affect GitHub, and commands that could discard work.

Do not run destructive commands or imply that `git reset --hard`, forced push, or deleting a branch is a normal first response.

========================================================================
CHAPTER 13 PROMPT CHARLIE - Git to Know Git
ID: 13-charlie | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Help me deliver the current approved change through Git without taking shortcuts.

First inspect the current branch, status, diff, remotes, and relationship to the default branch. Identify exactly which changed files belong to this mission and flag unrelated work. If I am on the default branch, propose a clear feature-branch name and wait for approval before creating it.

After branch approval, show me the diff in reviewable sections, run the relevant checks, and propose a concise commit message. Wait for approval before staging. Stage only the approved files, show the staged diff, and wait again before committing. After the commit, report its identifier and remaining status.

Propose the push and pull-request title and body, including purpose, material changes, tests, denied paths when relevant, and limitations. Wait for separate approval before pushing or opening the pull request. Do not merge it.

========================================================================
CHAPTER 13 PROMPT DELTA - Git to Know Git
ID: 13-delta | VERSION: 1.0 | DESTINATION: Codex
========================================================================

My Git repository is not in the state I expected. Diagnose it without changing anything first.

Inspect status, current branch, recent commits, reflog when appropriate, remotes, tracking relationships, staged and unstaged diffs, untracked files, and any merge or rebase state. Explain what likely happened, which work exists only locally, which work exists remotely, and what could be lost by each recovery option.

Offer the least destructive recovery plan first. Prefer preserving work on a new branch or commit before any operation that could discard it. Do not run reset, restore, checkout over files, clean, rebase, force push, branch deletion, or conflict resolution until I approve the exact action and target.

End with a plain-language description of the expected repository state after recovery and the read-only checks that will prove it.

========================================================================
CHAPTER 13 PROMPT ECHO - Git to Know Git
ID: 13-echo | VERSION: 1.0 | DESTINATION: Codex
========================================================================

The pull request for this mission has been merged. Help me synchronize the local repository safely without discarding work.

Begin read-only: inspect the current branch, working tree, tracking relationships, merged pull request or remote evidence, and whether any local commit or untracked file exists only on this computer. Confirm the default branch and whether the feature branch was actually merged.

Propose the exact sequence to return to the default branch, update it without an unnecessary merge commit, verify the merged commit, and decide whether the local and remote feature branches may be retired. Wait for approval before switching, pulling, or deleting any branch. Never delete a branch that contains unmerged or unpushed work.

After approved synchronization, report the final branch, commit, cleanliness, and relationship to the remote.

========================================================================
CHAPTER 13 PROMPT FOXTROT - Git to Know Git
ID: 13-foxtrot | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Create a factual flight-log draft for this completed mission using the repository and pull-request evidence. Do not change Git history or invent missing decisions.

Report the starting commit, feature branch, approved scope, commits, files changed, material diff summary, tests and verification, denied paths, review decisions, pull-request link and status, merge commit, deployment version when available, limitations, and unresolved follow-up.

Distinguish facts recoverable from Git from human decisions that Git cannot prove. Flag missing evidence rather than filling it with plausible language. Produce a concise Markdown entry suitable for the repository's flight log, then wait for approval before saving it.

========================================================================
CHAPTER 14 PROMPT ALPHA - Security Is Part of the Flight Plan
ID: 14-alpha | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Conduct a read-only security inspection of this repository and its local configuration. Do not modify files, install packages, display secret values, or search outside the authorized workspace.

Look for accidentally tracked credentials, sensitive local files, unsafe defaults, overly broad permissions, insecure authentication or session settings, missing input validation, vulnerable dependency declarations, public-cloud exposure, and configuration that differs between development and production.

Separate confirmed findings from possible concerns. For every finding, identify the supporting file and location, plausible impact, existing control, recommended correction, and a safe verification test. If a value appears secret, report only its type and location—never its contents.

Finish with a prioritized preflight checklist. Wait for Pilot in Command approval before changing anything.

========================================================================
CHAPTER 14 PROMPT BRAVO - Security Is Part of the Flight Plan
ID: 14-bravo | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Inventory every user role and protected action in this application. Build an authorization matrix showing which roles may view, create, update, delete, approve, administer, or export each protected resource.

Trace enforcement through URLs, routes, views, APIs, services, templates, and database rules. Distinguish presentation controls from server-side enforcement. Identify ambiguous rules, missing denials, privilege-escalation paths, and actions protected only by a hidden button.

For every important permission, propose both an allowed-path test and a direct denied-path test. A denied test must attempt the protected route or API directly and prove that protected data and database state remain unchanged.

Do not change permissions or tests yet. Present the matrix, evidence, uncertainties, and proposed test files, then wait for approval.

========================================================================
CHAPTER 14 PROMPT CHARLIE - Security Is Part of the Flight Plan
ID: 14-charlie | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Review how this application obtains credentials, API keys, database connection information, signing keys, and environment-specific configuration. Do not print, copy, rotate, or transmit any secret value.

Classify each setting as safe for source control, local environment configuration, GitHub Actions configuration, an approved encrypted secrets manager, or private interactive entry. Identify tracked files that should be removed from future commits, but do not delete them or rewrite Git history without explicit approval.

Propose a bounded migration plan covering local development, automated tests, GitHub workflows when used, least privilege, rotation, failure behavior, and documentation. Include commands with placeholders only. Require the human to enter credentials through an interactive or approved secret-management workflow.

Wait for approval before making changes or creating cloud resources.

========================================================================
CHAPTER 14 PROMPT DELTA - Security Is Part of the Flight Plan
ID: 14-delta | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Create a practical threat model for the current mission. Begin with the business purpose, sensitive assets, users, administrators, external systems, trust boundaries, entry points, and data flows.

Identify credible misuse cases, including unauthorized access, privilege escalation, data leakage, prompt injection, malicious files, unsafe tool execution, dependency compromise, denial of service, audit-log tampering, and accidental operator error. Do not invent vulnerabilities that the evidence does not support.

For each credible risk, state the evidence, likelihood, business impact, existing controls, control gaps, recommended mitigation, verification method, and responsible human decision. Rank actions by practical risk reduction rather than dramatic wording.

End with residual risks and explicit go/no-go decisions that require Pilot in Command approval.

========================================================================
CHAPTER 15 PROMPT ALPHA - Give the Specialist a Flight Envelope
ID: 15-alpha | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Begin by centering this mission on the Git repository for the Advanced Website model, `KnowCode-Academy-AuthenticatedWebSite`. Take possession of that repository as a read-only first step. Do not change files, create a branch, install dependencies, start services, access external systems, or propose a new architecture yet.

Verify the repository owner, visibility, remotes, default and current branches, working-tree state, most recent commit, application purpose, users and roles, entry points, architecture, data model, authentication and authorization boundaries, protected routes, tests, local startup procedure, deployment documentation, and known limitations. Cite exact files and distinguish verified facts from inference.

Trace one public request, one authenticated employee request, one authorized manager action, and one deliberately denied direct request through the existing application. Identify which parts of this proven website model could become a starting surface for a specialist, knowledge system, or agent—and which parts must remain ordinary deterministic application logic.

End with a concise current-state brief, missing evidence, and the business questions that must be answered before selecting technology. Wait for Pilot in Command approval before proceeding to architecture analysis.

========================================================================
CHAPTER 15 PROMPT BRAVO - Give the Specialist a Flight Envelope
ID: 15-bravo | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Analyze this business requirement before proposing technology. Restate the desired outcome, triggering event, required inputs, decisions, actions, users, frequency, latency, risk, and definition of success.

Compare at least these implementation patterns: ordinary application logic, deterministic automation, SQL analysis, document retrieval, RAG, a tool-using agent, and a human-led workflow assisted by Codex. Explain which parts require reasoning and which should remain deterministic.

Recommend the simplest architecture that satisfies the requirement. Include tradeoffs, operational cost, security, observability, failure recovery, and human-review needs. Do not recommend an agent merely because the request uses the word agent.

========================================================================
CHAPTER 15 PROMPT CHARLIE - Give the Specialist a Flight Envelope
ID: 15-charlie | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Design a bounded specialist for the approved mission. Specify its authorized users, accepted inputs, required starting data, permitted tools, accessible systems, data boundaries, allowed actions, prohibited actions, output schema, evidence contract, time and cost limits, and audit events.

Identify every action that is read-only, reversible, consequential, or destructive. Place explicit human-in-the-loop approval before external writes, permission changes, deployments, deletions, financial commitments, communications, or other consequential actions.

Define behavior for missing data, ambiguous instructions, conflicting evidence, tool failure, expired credentials, partial completion, and attempted scope expansion. The specialist must state what it could not verify rather than filling gaps with plausible text.

Present the design for Pilot in Command approval before implementation.

========================================================================
CHAPTER 15 PROMPT DELTA - Give the Specialist a Flight Envelope
ID: 15-delta | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Design the knowledge layer for this use case. Inventory the authoritative sources, file types, databases, APIs, update frequency, access rules, retention requirements, expected questions, and citation needs.

Compare direct file access, SQL, keyword search, metadata filtering, vector retrieval, RAG, APIs, and MCP resources. Explain where structured querying is more reliable than semantic retrieval and where both should be combined.

Recommend an ingestion, indexing, retrieval, freshness, deletion, and access-control design. Include source identity, chunking only when appropriate, metadata, versioning, duplicate handling, citations, observability, cost, and tests for missing or stale material.

Do not create infrastructure yet. Distinguish verified requirements, assumptions, and questions requiring a human decision.

========================================================================
CHAPTER 15 PROMPT ECHO - Give the Specialist a Flight Envelope
ID: 15-echo | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Define the evidence contract for every answer or action produced by this specialist.

Require the output to report the selected scope; source files, tables, APIs, or tools used; passages or columns examined; filters, joins, grouping, and calculations; document or row counts when available; missing or conflicting evidence; assumptions; limitations; and the human approvals obtained.

Design a structured response format that supports both a readable explanation and machine-verifiable provenance. Include rules for neutral language, citations, incomplete results, unsupported conclusions, and refusing to cross the selected project or data boundary.

Provide one complete example, one example with missing evidence, and one example that must stop for human review.

========================================================================
CHAPTER 15 PROMPT FOXTROT - Give the Specialist a Flight Envelope
ID: 15-foxtrot | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Create a test plan for this specialist before production use. Cover expected requests, ambiguous requests, missing inputs, stale data, conflicting sources, malformed files, duplicate records, unauthorized users, cross-boundary requests, prompt injection, unsafe tool instructions, tool timeout, partial failure, excessive cost, and recovery.

For each scenario, define the input, authorized tools, expected evidence, expected output or refusal, required audit event, and whether human approval is required. Include tests proving that denied actions cause no external state change.

Separate deterministic automated tests, model-evaluation cases, security tests, integration tests, and supervised flight trials. Define measurable acceptance criteria and unresolved limitations.

========================================================================
CHAPTER 15 PROMPT GOLF - Give the Specialist a Flight Envelope
ID: 15-golf | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Review the completed agent run using its execution trace, tool results, evidence, approvals, timing, and cost. Do not rely only on the final narrative answer.

Separate retrieved facts, SQL or tool results, model-generated reasoning, human instructions, human approvals, external writes, failures, retries, and unverified claims. Determine whether the specialist stayed within scope, satisfied its evidence contract, handled missing information honestly, and stopped at the correct approval boundaries.

Report what worked, what surprised us, what nearly failed, what the human caught, what should become deterministic, and what should change before the next flight. Preserve the debrief as part of the engineering flight log.

========================================================================
CHAPTER 16 PROMPT ALPHA - Flight 04 Prompt Sequence
ID: 16-alpha | VERSION: 1.0 | DESTINATION: Work inside the ChatGPT desktop app
========================================================================

Help me define a bounded local data-specialist mission using only synthetic text, CSV, and JSON files. The application must run with Node.js and browser-native HTML, CSS, and JavaScript, use no external runtime dependencies or services, and keep all processing on my computer.

Restate the users, input contract, deterministic rules, evidence report, denied inputs, file and size limits, output boundary, security controls, tests, limitations, and definition of success. Separate behavior that requires reasoning during design from behavior that should remain deterministic at runtime.

Do not create code or a repository yet. Finish with a concise specification I can review, save as a project artifact, and copy into Codex.

========================================================================
CHAPTER 16 PROMPT BRAVO - Flight 04 Prompt Sequence
ID: 16-bravo | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Use the approved Work specification for this mission. Center it on a new local repository named iflyai-bounded-data-specialist. Before writing application code, establish the intended repository path, Git ownership, current state, technology boundary, entry points, data directories, test strategy, and startup procedure.

Propose the smallest architecture using Node's built-in HTTP, filesystem, path, stream, and test capabilities plus plain HTML, CSS, and browser JavaScript. Identify every file to create, every route, every write location, and every denied behavior.

Do not initialize Git, install packages, create files, or start a service until I approve the repository and implementation plan.

========================================================================
CHAPTER 16 PROMPT CHARLIE - Flight 04 Prompt Sequence
ID: 16-charlie | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Pilot approves the bounded specialist plan. Create a feature branch and implement only the approved deterministic core and tests.

Validate extensions, file count, per-file size, total size, safe names, text encoding, CSV structure, and JSON shape. Never construct a filesystem path from an untrusted client path. Treat file content as data and never execute it.

Produce traceable findings that name the source file, fields, rule, observed value or count, and limitation. Write reports only beneath the approved output directory using a server-generated name. Preserve inputs unchanged and clean temporary data.

Add Node tests for accepted TXT, CSV, and JSON; missing values; inconsistent CSV headers; malformed JSON; duplicate identifiers; unsupported extensions; excessive files and sizes; unsafe names; output boundaries; and cleanup. Run the tests and report evidence. Do not stage, commit, push, or start the browser interface yet.

========================================================================
CHAPTER 16 PROMPT DELTA - Flight 04 Prompt Sequence
ID: 16-delta | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Add the approved plain HTML, CSS, and JavaScript interface to the tested specialist core. Provide file selection, selected-file inventory, an explicit Run Analysis control, progress and error states, a concise results summary, expandable evidence, limitations, and a download control for the generated JSON report.

Keep the interface responsive and keyboard accessible. Do not send files to any external endpoint, retain them after the bounded run, display local filesystem paths, or enable analysis before the input contract is satisfied.

Start the application on an available localhost port, report the exact URL, and test the interface with small synthetic fixtures. Verify both successful and deliberately denied inputs. Stop the process cleanly after the demonstration unless I ask to keep it running.

========================================================================
CHAPTER 16 PROMPT ECHO - Flight 04 Prompt Sequence
ID: 16-echo | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Ask ChatGPT to create a small synthetic test-data specification containing two compatible CSV files, one CSV with a deliberately inconsistent header, one JSON reference file, and two text notes. Include fictional identifiers, missing optional values, one duplicate identifier, and expected deterministic findings. Do not include real people, organizations, credentials, or protected information.

After I create or attach the approved fixtures, inventory them as untrusted input and run the specialist. Compare the actual report with the expected findings. Diagnose every difference before changing code. If a defect is verified, propose the smallest correction and regression test and wait for approval.

========================================================================
CHAPTER 16 PROMPT FOXTROT - Flight 04 Prompt Sequence
ID: 16-foxtrot | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Show the final diff, tests, runtime evidence, report example, input and output boundaries, denied cases, limitations, and Git state.

After separate approval, stage and commit only source, tests, safe synthetic fixtures, and documentation. Do not commit generated reports, temporary uploads, caches, or secrets. Prepare a flight record explaining what ChatGPT contributed, what Codex changed, what remained deterministic, what the tests proved, and what would require a different architecture.

========================================================================
CHAPTER 17 PROMPT ALPHA - Flight 05 Prompt Sequence
ID: 17-alpha | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Help me troubleshoot this problem without changing anything first.

Before investigating, ask me for the mission facts in one follow-up message. Instruct me to reply using plain-text lines beginning `EXPECTED_BEHAVIOR=`, `ACTUAL_BEHAVIOR=`, `ENVIRONMENT=`, `FAILURE_TIME_AND_ZONE=`, `LAST_KNOWN_WORKING_STATE=`, `RECENT_CHANGES=`, and `AUTHORIZED_SYSTEMS=`. Tell me to write `unknown` rather than guess. Restate your interpretation and wait for my confirmation.

Inventory the application version, Git branch and commit, working-tree state, running processes, listening ports, relevant configuration names without secret values, dependency state, service health, and available logs. Capture the exact error and a minimal reproduction when safe.

Separate observed facts, user reports, assumptions, and missing evidence. Do not edit files, restart processes, clear caches, reinstall dependencies, change cloud resources, or delete anything. End with a concise baseline and the next safest diagnostic action.

========================================================================
CHAPTER 17 PROMPT BRAVO - Flight 05 Prompt Sequence
ID: 17-bravo | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Trace this reproducible failure from the user's action through the relevant user interface, route, request, middleware, authentication and authorization checks, service logic, database or file access, and response handling.

Use source code, tests, browser evidence, server logs, and request identifiers to identify where expected and actual behavior first diverge. Build a short sequence diagram in plain language. Rank no more than three hypotheses and cite the evidence supporting and contradicting each one.

Run read-only or non-mutating diagnostic checks first. If a temporary probe or additional logging is needed, describe its exact scope, sensitive-data treatment, performance impact, and removal plan. Wait for approval before modifying code or configuration.

========================================================================
CHAPTER 17 PROMPT CHARLIE - Flight 05 Prompt Sequence
ID: 17-charlie | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Diagnose this browser or API failure without weakening security controls.

Inspect the browser console and network request, URL, method, status, redirect chain, request and response headers with credentials redacted, CORS behavior, cookies, CSRF handling, token audience and expiration metadata without token contents, backend logs, and route authorization.

Distinguish authentication failure, authorization denial, malformed request, expired session, CORS rejection, CSRF rejection, incorrect endpoint, DNS or TLS failure, backend exception, and user-interface rendering failure. Explain why the returned status code and message are or are not appropriate.

Do not disable authentication, CORS, CSRF, TLS verification, or permission checks as a diagnostic shortcut. Propose the smallest correction and the allowed-path and denied-path tests required before implementation.

========================================================================
CHAPTER 17 PROMPT DELTA - Flight 05 Prompt Sequence
ID: 17-delta | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Diagnose this data or ingestion problem inside the selected project and data boundary. Do not reingest, republish, alter schemas, delete files, or run unbounded queries yet.

Trace each input through upload, file validation, storage, metadata discovery, schema discovery, catalog or table creation, indexing or synchronization, status calculation, query resolution, and result presentation as applicable. Report item counts and state transitions at every observable stage.

For SQL failures, inspect the resolved tables and discovered columns, then validate names, types, joins, filters, aggregation, ordering, null behavior, and row-count boundaries. Use a small read-only probe instead of `SELECT *` when possible.

Identify the first stage where expected and actual counts or states diverge. Distinguish still running, timed out, partially successful, stale status, missing metadata, unsupported format, malformed input, permission failure, and application defect. Propose recovery that preserves already successful work.

========================================================================
CHAPTER 17 PROMPT ECHO - Flight 05 Prompt Sequence
ID: 17-echo | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Diagnose this GitHub Pages or repository-deployment problem using the explicitly approved repository and public URL. Begin with read-only inventory. Do not publish, rerun workflows, change settings, modify DNS, change permissions, delete deployments, or rewrite Git history.

Compare the intended Pages source, repository settings, workflow definition when present, build artifact, deployment record, deployed commit, application paths, and current public result. Inspect relevant workflow status, build logs, artifact contents, Pages configuration, browser console, network failures, and HTTPS response within scope.

Build a timeline using Git commits, workflow timestamps, deployment evidence, and browser observations. Identify stale browser state, wrong branch, failed build, missing permission, path error, propagation delay, and actual source change as separate possibilities.

Propose the least disruptive diagnostic or corrective action, rollback criteria, and verification. Require separate human approval before every repository-setting change, workflow rerun, publication, rollback, or deletion.

========================================================================
CHAPTER 17 PROMPT FOXTROT - Flight 05 Prompt Sequence
ID: 17-foxtrot | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Based on the approved diagnosis, propose the smallest change that addresses the demonstrated root cause. Identify the exact files, settings, processes, records, or resources affected; expected result; risks; rollback; and tests. Do not combine cleanup, modernization, and unrelated improvements with the repair.

Wait for Pilot in Command approval. After approval, apply only that correction, preserve a reviewable diff and command record, and run the minimal reproduction followed by relevant regression, denied-path, health, and user-interface checks.

Compare before-and-after evidence. State whether the original failure is fixed, merely masked, intermittent, or still unexplained. Report side effects, remaining uncertainty, monitoring needs, and whether temporary diagnostics must be removed. Do not declare success solely because the error message disappeared.

========================================================================
CHAPTER 17 PROMPT GOLF - Flight 05 Prompt Sequence
ID: 17-golf | VERSION: 1.0 | DESTINATION: Codex
========================================================================

This failure is intermittent. Design an observation plan before proposing a fix.

Define the event to capture, correlation identifiers, timestamps, safe structured logs, metrics, traces, environment and version markers, input characteristics, concurrency, resource pressure, external dependencies, and retention window. Prevent secrets, personal information, and excessive payloads from entering diagnostics.

Compare successful and failed executions and look for the smallest distinguishing conditions. State how many observations are available and whether they support causation or only correlation. Propose a bounded experiment that changes one variable at a time.

Include an operational stop condition, data-removal plan, cost limit, and the evidence required before implementing a permanent correction.

========================================================================
CHAPTER 18 PROMPT ALPHA - Approve the Capstone Boundary Before Building
ID: 18-alpha | VERSION: 1.0 | DESTINATION: Work inside the ChatGPT desktop app
========================================================================

Define a bounded local equipment-request and approval application for the *I Fly AI Flight Manual*. It must use Node.js built-in modules and plain browser HTML, CSS, and JavaScript with no external runtime dependencies or services.

Specify the employee, coordinator, administrator, and anonymous boundaries; request fields and status transitions; local authentication and session behavior; password storage; authorization enforcement; JSON persistence; append-only audit events; input validation; concurrency and recovery limitations; accessibility; tests; startup; cleanup; and definition of success.

Treat this as a local teaching system, not production identity infrastructure. Use synthetic users and requests only. Do not create code yet. Produce a specification and misuse-case table for Pilot review.

========================================================================
CHAPTER 18 PROMPT BRAVO - Approve the Capstone Boundary Before Building
ID: 18-bravo | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Use the approved Work specification and misuse-case table for this mission. Center it on a new local repository named iflyai-request-approval-system. Establish its intended path, Git state, technology boundary, entry points, route map, service boundaries, data files, audit format, tests, startup command, and cleanup procedure.

Identify every proposed file and the purpose of each. Define which files are source, safe synthetic seed data, runtime data, generated evidence, or ignored. Explain how atomic writes, a single-process write queue, backups, and recovery will reduce corruption risk in the bounded JSON store.

Do not initialize Git, create files, install packages, or start a service until I approve the plan.

========================================================================
CHAPTER 18 PROMPT CHARLIE - Approve the Capstone Boundary Before Building
ID: 18-charlie | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Pilot approves the capstone plan. Create a feature branch and implement the approved local authentication, session, and authorization core before building the full interface.

Hash synthetic demonstration passwords using Node's built-in crypto capability with unique salts and an appropriate work factor. Use server-generated session identifiers, HTTP-only SameSite cookies, bounded expiration, logout invalidation, generic login failures, and no credentials in logs or Git.

Enforce authorization in server-side handlers. Reject role values supplied by the client as authority. Add direct-route and direct-request tests proving anonymous denial, employee isolation, coordinator scope, administrator access, invalid-session denial, logout, expired sessions, and unchanged data after denied writes.

Run the tests and report allowed and denied counts. Do not stage, commit, push, or add the remaining business workflow yet.

========================================================================
CHAPTER 18 PROMPT DELTA - Approve the Capstone Boundary Before Building
ID: 18-delta | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Implement the approved request model and transitions: employee submission; employee personal list and detail; coordinator assigned queue; coordinator approve, return, or deny with a required reason; administrator audit view; and deliberately denied cross-user and cross-role actions.

Validate all server-side input, generate identifiers on the server, preserve created and updated timestamps, perform bounded atomic persistence, and append an audit event for authentication, creation, attempted denied access, and every status decision without recording passwords or session secrets.

Add tests for valid transitions, invalid transitions, duplicate submissions when defined, malformed input, unknown identifiers, persistence recovery, audit completeness, and unchanged records after failure. Report evidence and limitations before adding the browser interface.

========================================================================
CHAPTER 18 PROMPT ECHO - Approve the Capstone Boundary Before Building
ID: 18-echo | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Add the approved responsive, keyboard-accessible interface using plain HTML, CSS, and browser JavaScript. Provide a public landing page, login, employee request form and personal list, coordinator queue and decision controls, administrator audit view, logout, loading states, validation messages, deliberate denial pages, and a visible local-training-data notice.

Start the application on an available localhost port and report the exact URL. Create synthetic demonstration identities through a bounded seed command that does not print passwords or commit runtime credential files. Pause so I can enter or set local passwords privately.

Fly one public request, one employee submission, one authorized coordinator decision, one administrator audit review, and one deliberately denied direct request. Capture runtime evidence without exposing credentials or session cookies. Stop the service cleanly after the demonstration unless I ask to keep it running.

========================================================================
CHAPTER 18 PROMPT FOXTROT - Approve the Capstone Boundary Before Building
ID: 18-foxtrot | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Conduct a bounded failure exercise without risking unrelated files. Back up the synthetic runtime data, identify the rollback, and then test one invalid JSON record, one interrupted write simulation, one occupied local port, one missing data directory, and one stale session.

Preserve the exact errors, diagnose before correcting, and prove that recovery does not silently lose an accepted request or rewrite the audit history. Keep all induced failures inside disposable synthetic fixtures.

Report expected and actual behavior, recovery time, remaining limitations, and changes required. Wait for approval before correcting a verified defect.

========================================================================
CHAPTER 18 PROMPT GOLF - Approve the Capstone Boundary Before Building
ID: 18-golf | VERSION: 1.0 | DESTINATION: Codex
========================================================================

Inventory the final repository and compare it with the approved mission. Run the complete tests and report counts for success, denial, invalid input, persistence, recovery, accessibility checks, and audit evidence.

Show the final diff and confirm that passwords, sessions, runtime records, generated logs, caches, and unrelated files are excluded from Git. After separate approval, stage and commit the approved source, tests, documentation, and safe synthetic seed definitions.

Prepare the pull request and a complete flight record: mission, branch, architecture, roles, routes, data model, authorization matrix, misuse cases, files changed, tests, runtime evidence, induced failure, recovery, commits, limitations, and next recommended mission. Do not merge until Pilot review.