colonelpanic8/dotfiles/submit-t3code-change

Submit a T3 Code Change

Carry one change through two linked deliverables:

1. A focused, ready-for-review PR against pingdotgg/t3code:main.
2. A manifest entry in the personal assembly, rebuilt and activated.

Read /srv/dotfiles/dotfiles/agents/project-guides/t3code-assembly.md first for locations and safety invariants. The PR is the canonical standalone implementation; the assembly is the durable personal integration. Create the PR before integrating it.

1. Establish clean repository state

1. Read the applicable AGENTS.md files in both repositories.
2. Run git status --short --branch, git remote -v, and

git worktree list in T3 Code; git status --short in /srv/dotfiles. Preserve every unrelated change. Verify gh auth status.

1. Fetch origin/main and the relevant fork refs.
2. Work in the current T3 Code worktree when it already owns the intended

branch and is safe; otherwise use a clean worktree or create one under the T3 Code repo's .worktrees/. Do not alter a dirty worktree to make it usable.

1. Base the new branch directly on current origin/main. Keep each PR

independently applicable to main; never base it on another unmerged PR or on the assembled branch.

2. Implement a focused upstream change

Keep the PR narrow; do not mix cleanup or adjacent features merely because upstream may decline the contribution. Follow existing T3 Code architecture and repository instructions. Add tests that exercise behavior, not implementation details.

For UI changes: capture clear before/after images, a short video when motion or timing matters, and exercise the real interaction in the app, not only unit tests.

3. Validate and publish the PR

Run focused tests while iterating. Before publishing:

vp check
vp run typecheck

Plus vp run lint:mobile for native mobile changes and the relevant vp test ... for changed behavior. Then:

1. Review the full diff and commit it as a coherent change.
2. Push the branch to fork.
3. Create a ready-for-review PR against pingdotgg/t3code:main — no draft,

no agent prefix in the title. Use the template headings (What Changed, Why, UI Changes when applicable, Checklist), include exact validation commands, and attach required visual evidence.

1. Verify PR number, URL, base, head branch, and full head OID with

gh pr view.

Do not start the integration until the published head matches the locally validated commit.

4. Integrate into the assembly

Follow `BUILDING.md` in the `t3code-assembly` repository, sections "Inspecting and changing the stack" through "Landing a rebuild". Re-read manifest.toml first — another session may have changed the assembly while the PR was being prepared. Do not claim success from a source build alone.

5. Report

• PR URL and head OID.
• Manifest entry added.
• Conflicts resolved during the rebuild.
• New integration rev and tag; tree changed or unchanged.
• Build and activation result; T3 Code and dotfiles commits.