23 Addendum — Collaboration, Security & Workflow Policies

Daily visibility: For every active task, share progress every workday even if messy or incomplete.
Start-of-task footprint: Create a GitHub Issue and Draft PR on Day 0 (empty repo/placeholder acceptable). Push work-in-progress commits frequently.
Proof of work: Link your Issue/PR in daily check‑ins; summarize what changed, what’s next, and any blockers.
No silent stretches: If stuck or context‑switching, post a short “I’m blocked on X; trying Y; ETA for next update Z” message in the project channel.

Issue → Branch → Draft PR → Review → Merge is the default flow.
Branch naming: issue-<short-slug> (e.g., issue-feather-dash-loader).
No direct pushes to main/prod.
PR hygiene: Make the message concise, do not just use AI to generate extensive content that the reviewer must read. If possible use a PR template (scope, screenshots, test notes, risks). Mark as a draft. Ask for reviews if guidance is required. When ready and CI tests have passed convert to ready for review and slack the reviewer.
Review SLA: 16 business hours for first review; pair if blocked > 24 hours.
Merge rules: 1+ approval for low‑risk, 2+ for high‑risk. Hotfixes allowed only with incident reference and follow‑up PR.

Record working meetings; attach an agenda/notes doc in the invite.
Post‑meet automation: Within 2 hrs, drop the recording + notes link in the project channel with a 3–5 line decision summary.
Default share: Ensure stakeholders (internal leads/clients named in SOW) have access to all notes/recordings.
Index & audits: Maintain a single Meeting Notes Index per project; permission‑check monthly.

Device security: Full‑disk encryption required; approved antivirus; OS auto‑updates on.
Google Drive for Desktop: Disallowed by default. If good device practices are used and demonstrated a request for access will be granted.
AI tools: Use only the approved list. Connecting Company/Client Google accounts or syncing confidential files to third‑party AI tools is prohibited without written approval. Do not paste client secrets or sensitive datasets into public models.
Data classification: Tag work artifacts as Client Confidential / Company Confidential / Internal / Public and handle accordingly.
Account provisioning: Don’t sign up for new SaaS with Company SSO without approval; request via IT ticket.

Week 0 (setup): Accounts, access, security posture, read the Handbook + project runbooks.
Week 1 (observe & mirror): Shadow meetings; follow the Collaboration norms; create Issues/PRs on a low‑risk starter task.
Week 2 (deliver WIP): Ship iterative PRs on a scoped task; practice daily check‑ins and post‑meet summaries.

Signal: Missed daily visibility, no WIP PRs, or unresponsive code sharing.
Step 1: Written feedback with concrete expectations and a 1‑week improvement window.
Step 2: If no improvement, re‑assignment or contract reconsideration.

Log bugs and UX issues (e.g., forms, clipboard, session state) as GitHub Issues with repro steps, expected vs actual, screenshots, and priority.
Owner & SLA: Assign an owner; P1s acknowledged same‑day and fixed or triaged within 12 hours.

Separation: Dev/Test data isolated from Prod; use least‑privilege IAM and secrets management.
Privacy‑preserving integrations: Prefer designs that avoid handling raw PII where feasible; enable audit logs and access trails.
Runbooks: Each deployment has a runbook (rollback, on‑call, RPO/RTO targets).

Each repo has a named Owner and Back‑up.
Operational SLAs: Critical production bug fix ETA ≤ 12 business hours unless agreed otherwise; communicate status in‑channel.

Document significant AI prompts/recipes used for specs, tests, or code generation.
Share useful prompts to the internal library; avoid including proprietary client data.

Maintain your working hours and time‑zone in your Slack profile.
Post planned OOO ≥ 1 business day in advance in the team channel and add to the shared Availability calendar.
During overlapping hours, prefer synchronous stand‑ups; outside overlap, rely on async updates.