# Environment facts What each surface in your setup can and cannot do, learned the expensive way. Read this when a session reports a block, when choosing between surfaces, or before writing a prompt that fetches from outside your repo host. This file ships as a template. The facts below are the shape a real version takes; replace them with what you actually learn about your own accounts, connectors, and blocked domains as you hit them. That practice of writing down a limit the first time it costs you something is the point, more than any single fact here. ## Accounts - Personal account: where HQ runs. Has none of your work connectors. Do not action client tasks here; write the prompt for the work account instead. - Work account: your coding sessions (web or cloud), your browser-capable sessions, and connectors for your repo host, call recorder, task tracker, email, file storage, database, deploy target, and chat tool read access. ## Coding sessions (cloud) - A web UI that requires a repo attached to start a chat, even for repo-less work, needs a placeholder repo attached with a note not to touch it. - Sessions get an assigned branch name. Asking for a specific branch name sometimes works and sometimes does not; do not fight it, note the actual branch in the handoff. - Note your own egress proxy blocks as you hit them: specific domains, PDF mirrors, attachment-download hosts. Anything a session "reads" from a blocked domain came from search-indexed text and is unverified. Attach the file in the chat instead. - Force-push (`git push --force*`) is often denied outright by an auto-mode permission classifier. Switch the chat out of auto mode or approve the rule when prompted, then the session retries. This is the one place a prompt is welcome; keep it prompting for every rebase. - A stop hook may flag uncommitted changes at the end of a turn. Committing locally is fine and reversible; the approval gate is on push and PR, not on commit. Tell sessions "commit locally, do not push" if the hook nags. - Sessions can read connected transcripts, tasks and chats, and repo history through connectors. They cannot drive a browser. - Note your repo's actual default branch name; docs sometimes lag a rename. - A plain `git rebase` drops merge commits, which can silently drop a folder rename. After a rebase, have the session check for duplicate imports and switch cases (three-way merges produce invalid code that git does not flag) and for renames that lived only in merge commits. ## Browser-capable sessions - A cloud session with no browser and no computer link cannot open analytics dashboards, search console, or blocked-domain PDFs. It will ask for CSV exports; do not do them. - A desktop session with the computer linked and your browser logged in can open those same tools. Use it for verification passes, analytics baselines, and any read that needs a real browser. - These sessions typically do not commit to repos. When one produces a file that belongs in a repo, attach it to the next coding session for that project, which commits it under `docs/`. - File attachments to a task tracker from any Claude surface go through base64 and eat context. Drag the file onto the task yourself. Sessions draft the comment; you post it. ## Repo host and deploy target - Your reviewer merges, if you have one. You open PRs, rebase, and force-push to your own PR branches. Pushing to someone else's PR branch is done only when they have flagged the conflict themselves, with `--force-with-lease`, and your reply tells them what changed. - A repo linked to your deploy target usually builds a preview for every PR push. That preview URL is how a reviewer checks a page before merging; production picks up the merge. - Root directory mismatches are a common reason a page "does not show." Check the project settings before rebuilding anything. - Note any project-specific structural quirks here as you find them (duplicate apps under one path, a folder that needs cleanup) so the next session doesn't rediscover them. ## Task tracker conventions - One task per piece of client work on that client's list. Internal tooling on its own internal list. Never a task with no home list. - Pick a comment format and hold it, for example: `Completed: . Equivalent work: about Nh.` `Still needed: .` `Time: [your logged minutes] logged today` - If you log attention time, keep it as attention minutes, never machine hours; put the equivalent-work figure in the Completed sentence. - Keep a running note of any task IDs or list IDs you reference often, so prompts can name them directly instead of describing them. ## Chat tool conventions - Updates to your reviewer: bold section titles per client or repo, real URLs everywhere, a "From you" list at the end with a link on every ask. - Any automation that posts results to a shared channel should use an app-scoped webhook (one permission, one channel), never a shared human login. - Passwords never go in chat. Point at your password manager. ## People and lanes Keep your own short list here: who merges or approves, who runs delivery, who covers what, who is out and when, and the client or project contacts you deal with most. Update the date whenever you touch it, so a stale entry is easy to spot.