CK Codex Deployment

CampKitchen intake, testing, approval, deployment, tooling, fallback, and publishing workflow.

Start checklist
Normal workflow: use Fast Project Intake for raw requests, formalize only when ready, let Codex commit and push completed builds, and use manual Git commands only as optional confirmation or fallback.
01

CK Codex Deployment

CampKitchen build, intake, testing, deployment, and recovery checklist.

02

1. Start a CampKitchen Work Session

Open PowerShell and go to the active CampKitchen repository:

powershell
Set-Location "C:\GitHub\CampKitchen"

Confirm the repository state:

powershell
git status -sb

A clean synchronized result normally looks like:

text
03

main...origin/main

text

Start the repository workflow:

```powershell
.\ck.ps1 start

Do not begin a new build when Codex or Git reports unexplained local changes.

04

2. Open CampKitchen in Codex

Open the CampKitchen repository in Codex:

text
C:\GitHub\CampKitchen

Start a new Codex chat for the specific feature, bug, tooling task, or documentation task.

Use this repository-driven prompt:

text
CampKitchen build task: [WORK-ITEM ID and requested change].

Read and follow AGENTS.md, AI-WORKFLOW.md, docs/Chat-Workflow.md, docs/Product-Backlog.md, the relevant specification, docs/Master-Build.md, and the affected source files.

Use the repository's risk-based testing, deployment-approval, documentation, intake, and versioning rules.

Do not deploy production without clear product-owner approval after test review.

At the end, provide a completed Tracker Handoff Summary.
05

3. Repository Workflow Rules

The authoritative workflow belongs in the CampKitchen repository:

  • AGENTS.md contains short non-negotiable rules.
  • AI-WORKFLOW.md contains the complete workflow.
  • docs/Chat-Workflow.md explains how Codex and the tracker chat work together.
  • docs/Intake-Inbox.md contains unformalized project intake.

Reusable prompts should defer to these repository instructions instead of repeating the entire workflow.

06

4. Fast Project Intake

Use Fast Project Intake for bugs, features, enhancement requests, general requests, feedback, ideas, questions, and other observations.

Natural-language examples:

text
bug report: The CampKitchen logo does not display on the Super Admin page.
text
feature request: Allow groups and menu items to be archived and restored.
text
feedback: The date arrows work, but they are difficult to notice.
text
idea: Add a weekly dashboard showing meals, guest counts, and major prep needs.
text
request: Add a way for an administrator to cancel a pending invitation.
text
question: Should archived menu items still appear in historical prep lists?

Fast intake should:

  1. Assign the next INTAKE-### identifier.
  2. Add one concise entry to docs/Intake-Inbox.md.
  3. Preserve the original wording.
  4. Run only lightweight intake validation.
  5. Commit and push the intake entry.
  6. Return a short receipt.

Fast intake should not create a full specification, assign a final work-item prefix, update every planning document, investigate root cause, run full repository validation, or deploy.

PowerShell Intake Command

General form:

powershell
.\ck.ps1 intake -Type Bug -Title "Title" -Summary "Summary"

Supported types:

text
Bug
Feature
Enhancement
Request
Feedback
Idea
Question
Other

Bug example:

powershell
.\ck.ps1 intake -Type Bug -Title "Super Admin logo missing" -Area "Super Admin" -Actual "The CampKitchen logo does not display." -Expected "The approved CampKitchen logo displays."

Feature example:

powershell
.\ck.ps1 intake -Type Feature -Title "Archive groups" -Summary "Allow old groups to be archived instead of permanently deleted." -RequestedOutcome "Users can restore archived groups later."

Preview an intake entry without changing files:

powershell
.\ck.ps1 intake -Type Feedback -Title "Date controls are hard to notice" -Summary "The controls work but are visually easy to miss." -WhatIf

List open intake:

powershell
.\ck.ps1 intake-list

Filter the list:

powershell
.\ck.ps1 intake-list -Status "Needs Triage"
07

5. Formalize an Intake Item

Formalization is the separate step that converts raw intake into official project work.

Examples:

text
Formalize INTAKE-012.
text
Formalize INTAKE-012 as a bug.
text
Formalize INTAKE-013 as a user-interface feature.

During formalization, Codex may:

  1. Inspect relevant source and documentation.
  2. Select the correct official prefix, such as BUG, UX, ADM, KIT, INF, or SHR.
  3. Assign the next official identifier.
  4. Create the complete specification.
  5. Update required planning and project records.
  6. Run normal repository validation.
  7. Mark the intake entry as formalized.
  8. Commit and push the formalization.

An intake item may instead be merged, answered, closed as informational feedback, or deferred.

08

6. Testing Approval Options

Codex should stop before test deployment and ask which option you prefer.

Option A: Extended Codex Testing

Use for high-risk work or deeper browser and workflow testing:

text
Choose Option A. Deploy to test and perform extended Codex testing.

Option B: Fast Test Deployment

Use for most low-risk visual, branding, print, navigation, or backward-compatible UI work:

text
Choose Option B. Deploy to test, confirm the deployment and current assets, then stop for my manual testing.

Codex should verify the test deployment, confirm the current assets, then provide a short manual test list.

Option C: Do Not Deploy Yet

text
Choose Option C. Do not deploy yet.

Minimum repository, source-completeness, security, and relevant build checks still apply. Option B skips extended testing, not minimum safety checks.

09

7. Report the Manual Test Result

Passing result:

text
Testing passed.

Failed result:

text
Testing failed.

Expected:
[expected behavior]

Actual:
[actual behavior]

Steps:
[steps that produced the failure]

Correct the implementation and update the test deployment.

Passing testing does not authorize production by itself.

10

8. Production Approval

After test review, Codex should ask whether the tested version is approved for production.

No exact phrase is required. Clear approvals include:

text
Production approved.
text
Actual site approved.
text
Yes, deploy it to production.
text
Go live with this version.
text
Push this change live.

When approval is unclear, Codex should ask:

text
Do you approve deploying this tested version to production?

To pause:

text
Do not deploy production yet.
11

9. Normal Codex Completion

After clear production approval, Codex should normally:

  1. Commit the exact tested files.
  2. Push the commit to origin/main.
  3. Deploy the exact pushed commit.
  4. Perform the risk-appropriate production smoke check.
  5. Finalize approved release records.
  6. Return the final Tracker Handoff Summary.

When Codex reports that it committed and pushed, do not run .\ck.ps1 save afterward.

12

10. Normal Final Steps

Optional Repository Confirmation

This is optional when Codex already reports a successful commit and push:

powershell
git status -sb

Expected clean synchronized result:

text
13

main...origin/main

text

### Create the Dropbox Backup

```powershell
.\ck.ps1 backup

Record the Build in the Tracker Chat

Paste the actual handoff into the tracker chat:

text
Record this build:

[actual Tracker Handoff Summary from Codex]

This is chat text, not a PowerShell command.

A separate Mark deployed tracker message is optional when the handoff already includes the commit, production deployment, and verification record.

14

11. Optional Commit Confirmation

Use these only when independently confirming Codex's commit and push.

powershell
git log -5 --oneline --decorate
powershell
git fetch origin
powershell
git status -sb
powershell
git rev-list --left-right --count origin/main...HEAD

Expected synchronized result:

text
0       0

These are optional confirmation commands, not routine requirements.

15

12. Manual Save Fallback

Use this only when Codex did not commit and push.

First check:

powershell
git status

Save only when Git shows expected modified or untracked files:

powershell
.\ck.ps1 save -Message "WORK-ID: concise description"

When prompted:

text
SAVE

Do not run save when the working tree is clean. A clean tree means the changes are already committed or there is nothing new to save.

16

13. Review and Troubleshooting Fallback

Use these only for review, troubleshooting, or when Codex has not already completed the same step.

powershell
git status
powershell
git diff --stat
powershell
git --no-pager diff
powershell
.\ck.ps1 verify
powershell
.\ck.ps1 deploy test

Manual production deployment requires clear production approval:

powershell
.\ck.ps1 deploy production -ConfirmProduction DEPLOY
17

14. Self-Configuring Deployment Tooling

CampKitchen deployment tooling should not depend on whichever PATH a PowerShell or Codex process happens to inherit.

The repository should provide:

powershell
.\ck.ps1 doctor

The doctor command should report absolute paths and versions for:

  • Git
  • GitHub CLI
  • Node.js
  • npm
  • project-local Wrangler
  • Python
  • Cloudflare configuration and authentication readiness

All ck.ps1 commands and child deployment scripts should share one resolver that:

  1. Resolves absolute executable paths.
  2. Prefers the project-local pinned Wrangler version.
  3. Repairs the current process PATH.
  4. Passes the repaired environment to child processes.
  5. Runs deployment preflight before lengthy validation.
  6. Fails quickly with a specific correction when a tool is unavailable.
  7. Never silently downloads an unexpected latest Wrangler version.
  8. Does not permanently modify the Windows system PATH.
  9. Can safely resume a pre-upload deployment failure when the validated commit and target remain unchanged.

Codex Tooling Task

text
CampKitchen tooling task: INF-003, make deployment tool discovery self-configuring and reliable.

Read AGENTS.md, AI-WORKFLOW.md, ck.ps1, package.json, all PowerShell helper scripts, all deployment scripts, and the Wrangler configuration.

Do not change CampKitchen application behavior.
Do not deploy production.

Consolidate tool discovery into one shared resolver used by every ck.ps1 action and child deployment process.

Resolve absolute paths for git.exe, gh.exe, node.exe, npm.cmd, npx.cmd, project-local Wrangler, and python.exe.

Prepend resolved directories to the current process PATH, pass the repaired environment to child processes, prefer a locally pinned Wrangler version, add .\ck.ps1 doctor, run deployment preflight before lengthy validation, fail fast with actionable messages, and add a safe resume mechanism for failures that occur before upload.

Test normal PowerShell, a reduced-PATH child process, the named deployment path, doctor, and a test deployment.

A test deployment is authorized.
Production deployment is not authorized.

Update the relevant workflow documentation, commit and push the tooling fix, and return a completed Tracker Handoff Summary.
18

15. Version Numbering

CampKitchen uses MAJOR.MINOR.PATCH.

Patch

Use 2.3.2, 2.3.3, and so forth for bug fixes, small corrections, performance improvements, accessibility fixes, and backward-compatible adjustments.

Minor

Use 2.4.0, 2.5.0, and so forth for backward-compatible new features, screens, workflows, reports, or meaningful feature bundles.

Major

Use 3.0.0 only for breaking or incompatible changes, major workflow replacement, or an explicitly approved next-generation release.

Test deployments do not increment the public version. Codex may recommend a version. The product owner approves MINOR and MAJOR changes.

19

16. Documentation-Only Update

Use this prompt when only repository records need to change:

text
Apply the latest CampKitchen tracker updates to the repository documentation.

Update the Product Backlog, relevant specifications, Product Roadmap, Changelog, Development Journal, Master Build, and other affected records.

Do not change application code.
Do not deploy.
Run repository validation once.
Commit and push the documentation update.
Return a completed Tracker Handoff Summary.

No test or production deployment is required for documentation-only work.

20

17. Update and Publish This Checklist

This checklist is a separate static Cloudflare Worker project:

text
C:\GitHub\CK-Codex-Deployment

Replace the deployed page with the updated HTML:

powershell
Copy-Item "D:\Downloads\CampKitchen-Clickable-Checklist.html" "C:\GitHub\CK-Codex-Deployment\public\index.html" -Force

Review changes:

powershell
git --no-pager diff

Run the site's self-check:

powershell
.\site.ps1 doctor

Preview locally:

powershell
.\site.ps1 dev

Deploy the site:

powershell
.\site.ps1 deploy

Commit and push the site update:

powershell
git add .
powershell
git commit -m "SITE: update CK Codex Deployment checklist"
powershell
git push

Production address:

text
https://build.campmenutool.com
21

18. Full Fast Routine

  1. Run .\ck.ps1 start.
  2. Open CampKitchen in Codex.
  3. Use Fast Project Intake for raw bugs, features, requests, feedback, ideas, and questions.
  4. Formalize an intake item only when it is ready for official project work.
  5. Give Codex one specific build task.
  6. Codex runs minimum safety checks.
  7. Choose testing Option A, B, or C.
  8. For most low-risk work, choose Option B.
  9. Manually test the test deployment.
  10. Report whether testing passed or failed.
  11. Codex asks for production approval.
  12. Approve or decline in clear ordinary language.
  13. Codex commits, pushes, deploys, verifies, and returns the handoff.
  14. Optionally confirm repository synchronization.
  15. Run .\ck.ps1 backup.
  16. Paste the Tracker Handoff Summary into the tracker chat.