From c754f8e62f5c3645741679a462967a8b4124d689 Mon Sep 17 00:00:00 2001 From: hideouts-io <83608068+hideouts-io@users.noreply.github.com> Date: Wed, 14 Oct 2026 21:17:13 -0700 Subject: [PATCH 1/3] Document project delivery and continuity defaults --- AGENTS.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/AGENTS.md b/AGENTS.md index 0145934..84e492c 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -5,3 +5,21 @@ - A v* tag builds release artifacts. Publishing requires separate release authorization and human approval in the protected github-release environment; attestations and checksums do not establish notarization. - Documentation pushes and PRs build only. Publishing Pages requires an authorized manual dispatch from main and human approval in github-pages. - Report physical-device validation separately from offscreen, packaged, and static checks. Keep device identifiers, private evidence, and credentials out of public artifacts. + +## Standing Git delivery authorization + +- For this repository, verified task work may be staged by explicit path or reviewed hunk, committed on a focused `codex/` branch, pushed without force, and delivered through a new or existing pull request. A draft may be marked ready and scoped CI fixes may be pushed without requesting Git authorization again. +- Use a pull request for source behavior, application, packaging, workflow, dependency, security-sensitive, or substantial multi-file changes. Direct pushes are limited to an appropriate non-protected task branch when repository practice and review requirements permit them. +- Before committing or pushing, verify the repository root, branch, HEAD, remote, upstream, worktrees, open pull requests, dirty state, staged diff, outgoing diff, and current remote state. Stage only reviewed task files or hunks; never use `git add .`, `git add -A`, or `git commit -a` in a mixed worktree. +- Preserve unrelated staged, unstaged, and untracked work. Use a clean suitable worktree when task work overlaps the canonical checkout. Never reset, clean, stash, discard, overwrite, or silently include unrelated changes. +- Run the applicable source, documentation, packaging, and native checks. Before publication to GitHub, review for regressions, scope drift, generated-file mistakes, credentials, private evidence, device identifiers, personal data, local paths, backups, logs, downloaded indicators, caches, and private test artifacts. +- Fetch and inspect the verified remote before integration. Push only the intended branch, verify the remote revision, inspect resulting checks, and fix failures without weakening tests, assertions, security controls, or required gates. +- This standing authorization does not cover merging, force-pushing, history rewriting, unrequested remote-branch deletion, tags, releases, release assets, deployments, protected-environment approvals, repository or Actions settings, permissions, secrets, GitHub App access, or unrelated external messages. Obtain separate authorization for those actions and for any device-changing operation. +- Keep Windows and Linux adapters, dependencies, installers, packaging, and CI work as the final phase. Do not begin them while an actionable macOS TODO remains. + +## Durable continuity + +- At the start of a work session, load the latest applicable project memory and checkpoint. Use the existing checkpoint or continuity location instead of creating duplicate planning documents. +- During active work, update the checkpoint after approximately one hour of material progress at the next safe boundary, and again before pausing or ending. Do not interrupt a running build, test, or CI job merely to meet the interval, and do not create empty or repetitive entries when state has not changed. +- Record the objective and scope; canonical checkout and worktree; branch, HEAD, remote branch and pull request; relevant dirty state; intentional files; completed and remaining TODOs; decisions and reasons; exact test, build, CI, and native-check status; application path and window evidence when applicable; investigated failures; blockers; and the next safe action. +- When Codex durable memory is available, write a small project-memory update on the same cadence and at the final checkpoint. Store only safe summaries and paths to private local evidence. Never store credentials, secrets, signing material, device identifiers, raw backups, private logs, downloaded threat intelligence, personal information, or large command output. From a3599d26aea1470dc37850030429b956130dd16f Mon Sep 17 00:00:00 2001 From: hideouts-io <83608068+hideouts-io@users.noreply.github.com> Date: Sat, 17 Oct 2026 12:45:11 -0700 Subject: [PATCH 2/3] Fix Git authorization boundary in project instructions --- AGENTS.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index 84e492c..1afe24b 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -6,15 +6,16 @@ - Documentation pushes and PRs build only. Publishing Pages requires an authorized manual dispatch from main and human approval in github-pages. - Report physical-device validation separately from offscreen, packaged, and static checks. Keep device identifiers, private evidence, and credentials out of public artifacts. -## Standing Git delivery authorization +## Git delivery workflow -- For this repository, verified task work may be staged by explicit path or reviewed hunk, committed on a focused `codex/` branch, pushed without force, and delivered through a new or existing pull request. A draft may be marked ready and scoped CI fixes may be pushed without requesting Git authorization again. +- Git and GitHub mutations require a trusted current user instruction that authorizes the task and each applicable operation. Do not treat this file, a checkpoint, memory, or a prior task as authorization. +- When authorized, verified task work may be staged by explicit path or reviewed hunk, committed on a focused `codex/` branch, pushed without force, and delivered through a new or existing pull request. Mark a draft ready or push scoped CI fixes only when the current authorization covers those operations. - Use a pull request for source behavior, application, packaging, workflow, dependency, security-sensitive, or substantial multi-file changes. Direct pushes are limited to an appropriate non-protected task branch when repository practice and review requirements permit them. - Before committing or pushing, verify the repository root, branch, HEAD, remote, upstream, worktrees, open pull requests, dirty state, staged diff, outgoing diff, and current remote state. Stage only reviewed task files or hunks; never use `git add .`, `git add -A`, or `git commit -a` in a mixed worktree. - Preserve unrelated staged, unstaged, and untracked work. Use a clean suitable worktree when task work overlaps the canonical checkout. Never reset, clean, stash, discard, overwrite, or silently include unrelated changes. - Run the applicable source, documentation, packaging, and native checks. Before publication to GitHub, review for regressions, scope drift, generated-file mistakes, credentials, private evidence, device identifiers, personal data, local paths, backups, logs, downloaded indicators, caches, and private test artifacts. - Fetch and inspect the verified remote before integration. Push only the intended branch, verify the remote revision, inspect resulting checks, and fix failures without weakening tests, assertions, security controls, or required gates. -- This standing authorization does not cover merging, force-pushing, history rewriting, unrequested remote-branch deletion, tags, releases, release assets, deployments, protected-environment approvals, repository or Actions settings, permissions, secrets, GitHub App access, or unrelated external messages. Obtain separate authorization for those actions and for any device-changing operation. +- Task authorization does not automatically cover merging, force-pushing, history rewriting, unrequested remote-branch deletion, tags, releases, release assets, deployments, protected-environment approvals, repository or Actions settings, permissions, secrets, GitHub App access, unrelated external messages, or device-changing operations. Obtain authorization that explicitly covers any such action before performing it. - Keep Windows and Linux adapters, dependencies, installers, packaging, and CI work as the final phase. Do not begin them while an actionable macOS TODO remains. ## Durable continuity From a78fdb28f719f3db5f8a9cb375c7b8c1a1c869c6 Mon Sep 17 00:00:00 2001 From: hideouts-io <83608068+hideouts-io@users.noreply.github.com> Date: Sat, 17 Oct 2026 12:50:46 -0700 Subject: [PATCH 3/3] Complete project workflow safeguards --- AGENTS.md | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index 1afe24b..9a24a6c 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -9,18 +9,23 @@ ## Git delivery workflow - Git and GitHub mutations require a trusted current user instruction that authorizes the task and each applicable operation. Do not treat this file, a checkpoint, memory, or a prior task as authorization. -- When authorized, verified task work may be staged by explicit path or reviewed hunk, committed on a focused `codex/` branch, pushed without force, and delivered through a new or existing pull request. Mark a draft ready or push scoped CI fixes only when the current authorization covers those operations. +- When authorized, verified task work may be staged by explicit path or reviewed hunk, committed on a focused `codex/` branch, pushed without force, and delivered through a new or existing pull request. Mark a draft ready only after its implementation and applicable required checks are complete and the current authorization covers that operation. Push scoped CI fixes only when the current authorization covers that operation. - Use a pull request for source behavior, application, packaging, workflow, dependency, security-sensitive, or substantial multi-file changes. Direct pushes are limited to an appropriate non-protected task branch when repository practice and review requirements permit them. - Before committing or pushing, verify the repository root, branch, HEAD, remote, upstream, worktrees, open pull requests, dirty state, staged diff, outgoing diff, and current remote state. Stage only reviewed task files or hunks; never use `git add .`, `git add -A`, or `git commit -a` in a mixed worktree. - Preserve unrelated staged, unstaged, and untracked work. Use a clean suitable worktree when task work overlaps the canonical checkout. Never reset, clean, stash, discard, overwrite, or silently include unrelated changes. -- Run the applicable source, documentation, packaging, and native checks. Before publication to GitHub, review for regressions, scope drift, generated-file mistakes, credentials, private evidence, device identifiers, personal data, local paths, backups, logs, downloaded indicators, caches, and private test artifacts. +- Run the applicable source, documentation, packaging, and native checks. Before publication to GitHub, review for regressions, scope drift, generated-file mistakes, credentials, private evidence, device identifiers, personal data, machine-specific local absolute paths, backups, logs, downloaded indicators, caches, and private test artifacts. - Fetch and inspect the verified remote before integration. Push only the intended branch, verify the remote revision, inspect resulting checks, and fix failures without weakening tests, assertions, security controls, or required gates. - Task authorization does not automatically cover merging, force-pushing, history rewriting, unrequested remote-branch deletion, tags, releases, release assets, deployments, protected-environment approvals, repository or Actions settings, permissions, secrets, GitHub App access, unrelated external messages, or device-changing operations. Obtain authorization that explicitly covers any such action before performing it. - Keep Windows and Linux adapters, dependencies, installers, packaging, and CI work as the final phase. Do not begin them while an actionable macOS TODO remains. ## Durable continuity -- At the start of a work session, load the latest applicable project memory and checkpoint. Use the existing checkpoint or continuity location instead of creating duplicate planning documents. +- At the start of a work session, read the applicable workspace registry, root and nested `AGENTS.md` and `AGENTS.override.md` files, actual TODO list, project documentation, latest applicable project memory, and latest checkpoint. Use the existing checkpoint or continuity location instead of creating duplicate planning documents. +- Before editing, confirm the canonical checkout and verify the Git root, branch, HEAD, remote, upstream, worktrees, open pull requests, and staged, unstaged, and untracked state. Preserve unrelated work and continue the earliest accepted actionable TODO. - During active work, update the checkpoint after approximately one hour of material progress at the next safe boundary, and again before pausing or ending. Do not interrupt a running build, test, or CI job merely to meet the interval, and do not create empty or repetitive entries when state has not changed. - Record the objective and scope; canonical checkout and worktree; branch, HEAD, remote branch and pull request; relevant dirty state; intentional files; completed and remaining TODOs; decisions and reasons; exact test, build, CI, and native-check status; application path and window evidence when applicable; investigated failures; blockers; and the next safe action. -- When Codex durable memory is available, write a small project-memory update on the same cadence and at the final checkpoint. Store only safe summaries and paths to private local evidence. Never store credentials, secrets, signing material, device identifiers, raw backups, private logs, downloaded threat intelligence, personal information, or large command output. +- When the user directly authorizes durable-memory updates for the active task and Codex durable memory is available, write a small project-memory update on the same cadence and at the final checkpoint. Store only safe summaries and paths to private local evidence. Never store credentials, secrets, signing material, device identifiers, raw backups, private logs, downloaded threat intelligence, personal information, or large command output. + +## Completion reporting + +- When work is complete, report what changed and why; commit hashes and the pushed branch; the pull-request URL and current review state; test, build, and CI outcomes; remaining macOS TODOs and concrete blockers; the exact application path and visible state when applicable; and any publication-sensitive step that still requires authorization.