Verify the target before creating a workspace
Before any remote work, verify the hostname, project path, and repository status.
Read the details
Before any remote work, verify the hostname, project path, and repository status. The target is the office mini project at `/Users/coproperty/Projects/coproperty-office-os`, reached as user `coproperty` through the owner-confirmed `coproperty-office` SSH contract.
This first check prevents a familiar alias, stale terminal, or shared account from becoming an unexamined assumption. It is read-only orientation, not permission to change the installed project.
- Current
- Checked — the contract is documented and must be verified for each actual session.
- Proposed next state
- Stop and ask an owner when hostname, path, fingerprint, or status do not match the expected contract.
- Expected outcome
- A contributor knows exactly which machine and project they are looking at before making a worktree.
Checks to include when changing this section
- Check contextual drafts include hostname, path, alias, user, and fingerprint.
- Check no draft contains an automatic remote command or an execution API.
A separate worktree protects the installed runtime
Create the task worktree outside the installed project.
Read the details
Create the task worktree outside the installed project. Do not edit, install into, or otherwise modify the installed runtime. A separate worktree reduces accidental interference between tasks. Because teammates share a Unix account, it is not a security boundary: processes and permissions remain shared. Keep development paths, test ports, configuration, and installed services distinct.
This rule gives the contributor a reversible place to test a change and keeps a currently installed service from being altered as a side effect of development.
- Current
- Checked — the separation requirement is explicit in the approved contribution contract.
- Proposed next state
- Use a fresh, named isolated workspace for each bounded task and remove it only through the normal reviewed process.
- Expected outcome
- Development work does not alter the running installed project.
Checks to include when changing this section
- Check a PR diff has no changes to installed runtime paths or generated local state.
- Check a new task begins from a verified clean isolated worktree.
Baseline and targeted regressions turn intent into reviewable evidence
Run the baseline tests that protect the existing surface and focused regressions for the change.
Read the details
Run the baseline tests that protect the existing surface and focused regressions for the change. UI work needs browser and mobile checks. Connector work needs duplicate, failure, and freshness fixtures. A successful happy path alone is not enough to establish safe operational behavior.
Every change goes through a PR with test evidence. Shesh reviews and merges initially. The team must follow this process consistently.
- Current
- Checked — baseline tests, focused checks, and PR review are required.
- Proposed next state
- Include expected outcome, test evidence, and known limitation in every PR description.
- Expected outcome
- Reviewers can see what changed, how it was tested, and what remains unverified.
Checks to include when changing this section
- Run baseline plus scope-specific checks before opening the PR.
- For UI, capture browser and mobile evidence; for connectors, keep duplicate/failure/freshness fixtures.
Review and release remain separate decisions
A PR is a request for review, not an automatic deployment.
Read the details
A PR is a request for review, not an automatic deployment. No automatic deployments, LINE sends, credential changes, or runtime installs are part of this contribution path. A separately approved release should be planned only after review and the appropriate operational checks.
The contextual work panel can draft an “Implement and submit PR” request, but it cannot submit the PR or release anything. That boundary is intentional.
- Current
- Checked — release safeguards are explicit in the contribution contract.
- Proposed next state
- Seek explicit approval for any action that crosses from reviewed code into external or runtime effect.
- Expected outcome
- A code change is not confused with a deployment, message, credential, or operational action.
Checks to include when changing this section
- Check preparing a draft performs no work, while submitting an implementation request permits source-only work and a PR.
- Check user text cannot remove the no-deploy, no-message, no-credential constraints from the generated prompt.
Apply with care
A concrete safe example
Example, responsibilities & checklist
A bounded documentation change
After verifying host, path, and repository status, create a separate task worktree outside the installed project. Update only the documentation source there, run the baseline and targeted checks, open a PR, and wait for review. Do not deploy, message LINE, or alter a credential.
Responsibilities
- The contributor verifies target, creates the isolated worktree, writes tests, and submits a PR.
- The installed project remains untouched throughout normal change preparation.
- Shesh reviews and merges initially; every change needs review.
- Release, deployment, messages, credential changes, and runtime installs require separate explicit approval.
Checklist
- Verify hostname, project path, and repository status before any technical work.
- Create an isolated task worktree outside the installed project; shared Unix account is not isolation.
- Run baseline plus focused regressions before PR submission.
- Do not deploy automatically, send LINE messages, change credentials, or install runtime components.
A contributor can prepare a bounded change without modifying production/runtime surfaces or assuming an automatic deployment.
Traceability without sensitive material
Source pointers and exports
This page expands the approved handoff into plain-language guidance. It does not include runtime logs, credentials, databases, private evidence, internal QA artifacts, or developer planning history.
Documentation references
- Handoff / pages/access.html
- Handoff / pages/infrastructure.html
- Handoff / START-HERE.html