# Contribution: isolated workspaces, meaningful tests, reviewed release

> Checked · 20 October 2026 · Wiki version 2026.10.20.2

A safe change begins by verifying the remote target, then uses an isolated worktree outside the installed project. It is tested, submitted as a pull request, and reviewed before a person releases it.

## Purpose
Turn the access contract into a careful contribution route that protects the installed runtime, avoids shared-account assumptions, and preserves human review.

## Diagram text alternative
Verify the remote target, create an isolated worktree outside the installed project, run baseline and targeted tests, submit a PR, then obtain review and a separately approved release. There is no automatic deployment.

## Current / proposed status
- Current: Checked — every proposed change follows the documented test and review process.
- Proposed: Shesh reviews and merges initially. Follow the review process for every change, then agree the release separately.

## Safe example
### 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 id="safe-start"></a>

## Verify the target before creating a workspace

**Status:** Checked

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 / proposed status**
- Current: Checked — the contract is documented and must be verified for each actual session.
- Proposed: 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.

**Meaningful tests**
- Check contextual drafts include hostname, path, alias, user, and fingerprint.
- Check no draft contains an automatic remote command or an execution API.

<a id="isolated-worktree"></a>

## A separate worktree protects the installed runtime

**Status:** Checked

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 / proposed status**
- Current: Checked — the separation requirement is explicit in the approved contribution contract.
- Proposed: 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.

**Meaningful tests**
- 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.

<a id="tests-and-pr"></a>

## Baseline and targeted regressions turn intent into reviewable evidence

**Status:** Checked

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 / proposed status**
- Current: Checked — baseline tests, focused checks, and PR review are required.
- Proposed: 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.

**Meaningful tests**
- Run baseline plus scope-specific checks before opening the PR.
- For UI, capture browser and mobile evidence; for connectors, keep duplicate/failure/freshness fixtures.

<a id="review-release"></a>

## Review and release remain separate decisions

**Status:** Checked

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 / proposed status**
- Current: Checked — release safeguards are explicit in the contribution contract.
- Proposed: 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.

**Meaningful tests**
- 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.

## Related pages
- [Personal access: choose the least-privileged path](/contribution/access/) — Most staff should use approved dashboard access. Technical operators use their own Tailscale identity and SSH key to reach the office mini only after owner approval.
- [SOP learning: turn observations into a better next step](/workflows/sop-learning/) — Learning connects incidents, reports, and repeated exceptions to a reviewed procedure. It prevents a useful lesson from being stranded in a one-off conversation.
- [Service directory: approved destinations, not shared access](/reference/service-directory/) — This directory names the approved service destinations used around Co.Property. Every destination requires an existing authorised account or approved auth; the wiki never stores tokens, credentials, or private logs.

## Source pointers
- Handoff / pages/access.html
- Handoff / pages/infrastructure.html
- Handoff / START-HERE.html

## Context export
- Page context: ./exports/contribution--workspace-and-pr.context.json