03 — How to Test in This Setup¶

How to get access, how to use me (Claude Code) as your standing "how is this supposed to work?" reference, and how to tell a real bug from intended behavior before you file.

0. Your testing philosophy, in brief¶

Six habits that guide everything else in this doc:

Test against intent, not guesswork. Before you file anything, confirm how a feature is supposed to behave — check the product spec, the approved prototype, or ask me to trace the feature in the code. If it matches intent, it's not a bug. (§3 below is the full before-you-file checklist.)
Stick to July-pilot surfaces first. Bids and bid invites, the estimate sheet, projects, daily logs, RFIs, submittals, change orders, login, Cara, and SharePoint import/sync. Don't file functional bugs against things being redesigned or built for September — check doc 02's scope legend.
Prioritize by real-world impact, not by whatever you happen to find first. Blockers are data loss, wrong money numbers, broken core workflows, and anything that stops Alex or Jim from getting their work done. Polish and nice-to-haves go to the backlog, not the launch cycle.
Go deep on edge cases and data integrity — empty states, bad inputs, two people editing the same thing, and the append-only records (estimate, proposal, insurance revisions) that must never silently change. This is where the bugs a real user hits later tend to hide.
Every bug you log should be reproducible — exact steps, the role you were using, a screenshot or recording — so the developer can fix it fast. Verify every fix on staging yourself before closing it (see doc 04).
Bring the current bug picture to each weekly sync, in a standing structure people can rely on:
1. Blockers/Urgent open right now (headline first).
2. Fixed + verified since last time (reassurance that the list moves).
3. Decisions you need from stakeholders (is X a bug or intended? scope calls).
4. Where you're focusing next.
This mirrors the report structure the team already uses for exec updates: status reassurance → honest problem list → what's next → the specific decisions needed. Use it for any recurring stakeholder sync, not just one specific meeting.

1. Getting access¶

Environments¶

Two environments in play — pick the right one for what you're testing:

Staging — https://pinley-staging.cdn.codilas.link/. The default for most testing. Do not test on production; the pilot cutover to real data happens late July.
Development — https://pinley-development.cdn.codilas.link/. Use this instead of staging specifically for BuildingConnected (BC) sync — it doesn't currently work on staging. If a flow you're testing touches BC sync, switch to dev; note in your bug report which environment you were on either way (it belongs in the Env: line of the bug template, doc 04).

There is no separate QA Slack channel — for access, environment questions, or anything you can't resolve yourself, ask Marko directly.

Test credentials for different roles¶

You need to test the same feature as different roles (Owner, PM, Estimator, Field User, etc.) because what a user can see/do changes by role. The sanctioned way to do this is the dev role-switcher: a role chip in the top bar (non-prod builds only) that re-logs you in as any of the 14 seeded role accounts ({role}@codilas.com) with real server-side permissions. Full details, known gotchas, and the fallback (manual per-role logins) are in the Login walkthrough §5 — don't re-derive this from scratch, that doc is the source of truth.

Two Pinley employees — Alex and Jim — will also be testing on real data during the pilot. You may see their accounts/data; coordinate with them so you're not stepping on each other.

2. Using me (Claude Code) as your reference¶

I'm running inside the actual product codebase, plus the client-approved prototype and all the project history. That means I can answer, precisely and on demand, "how is feature X supposed to behave?" — which is exactly what you need to decide whether something is a bug. I do not change code during QA; I read and explain.

Good things to ask me¶

"Trace how [feature] is supposed to work, from the backend to the screen." e.g. "Trace how RFI status changes work — what transitions are allowed, and who gets notified?" I'll read the proto/service/frontend and tell you the intended rules, so you know what "correct" looks like.
"What does the client prototype say the UX for [feature] should be?" The client-approved prototype (at /Users/markoplesa/Projects/codilas/pinley/AI-prototype/) is the source of truth for intended look/flow/copy. Ask me to read the relevant workflow doc or prototype page and describe the intended experience. Caveat: the prototype's look and rules are authoritative, but its underlying data/backend is a mockup — for actual system behavior I check the real codebase, not the prototype's fake data.
"Is [field/permission/feature] actually built for the July launch, or is it September scope?" This is the highest-value question you can ask me. Before filing "X is missing" or "role Y can see Z," ask me to confirm X/Z is in the current build. (Remember: field masking and the full role matrix are September — see doc 01 §2 and doc 02.)
"What should the exact values / statuses / options be here?" e.g. "What are the valid submittal decision options?" or "What trades should appear in the Daily Log dropdown?" I can pull the authoritative list so you can check the UI against it.
"Has this been a known bug before?" I have the project history. Some things (e.g. a daily-log data-loss bug, PDF text encoding, HeroUI dropdown width) were fixed already — I can tell you if what you're seeing is a regression of a known issue, which strengthens your bug report.

Deep-dive bug investigation — the `/debug` skill¶

When you have a specific suspected bug and want a structured root-cause investigation (still analysis-only — no code changes), ask me to run the /debug skill. Give me: - the exact steps you took, - what you expected, - what actually happened, - the role you were logged in as, - the staging URL and, if you have it, the build/version.

/debug produces a structured investigation of why it's happening, which you can paste into (or link from) your Linear ticket to make the developer's job much faster. It will not modify code.

How to phrase things so I'm most useful¶

Name the module and role ("As an Assistant PM on the Project Budget tab…").
Tell me whether you want intended behavior (spec) or a root-cause investigation (/debug).
Paste the exact on-screen text/error — I can search the codebase for it.

3. Telling a real bug from intended behavior (do this BEFORE filing)¶

A quick triage before every ticket. This keeps the launch cycle full of real bugs and saves developer time.

Step 1 — Check scope. Is this feature even in the July pilot? Cross-check doc 02's scope legend. If it's 🚫 September/not-built, it's not a launch bug — capture it as a backlog idea instead (doc 04). When unsure, ask me.

Step 2 — Check intent. Does the behavior match what the product is supposed to do? - Check the prototype (ask me to read the relevant workflow/page), and/or - Ask me to trace the feature and state the intended rule. - Remember the deliberate design decisions that look like bugs but aren't, e.g.: - Assistant PM can't see the Budget tab — intended. - A PM can see a profit/margin number — not a bug in July (masking is September). - Cost code isn't on the submittal create form — intended (it's edit-only). - SharePoint sync doesn't happen automatically in real time — intended for the pilot; it's a manual sync button, not live two-way sync (that's September). A missing button, or the button doing nothing, IS a bug — see doc 02 §10.

Step 3 — Reproduce it. Can you make it happen again from a clean start? Note the exact steps, role, and data. A bug you can reproduce is worth 10× one you can't. If it's intermittent, say so and capture as much as you can (screenshot, time, what you'd just done).

Step 4 — Decide severity (drives Linear Priority — see doc 04): - Blocker (Urgent): data loss, corruption, can't-log-in, a core pilot workflow is completely broken, wrong money numbers, a confidential-money leak that is in July scope, an immutability violation. - Major (High): an important feature is broken or gives wrong results but there's a workaround. - Minor (Medium): small functional issue, awkward but usable. - Cosmetic (Low): visual/copy/polish only.

Step 5 — File it per doc 04 (current launch cycle, qa label, Priority = severity, no assignee, use the bug template).

Rule of thumb¶

In scope + doesn't match intent + reproducible = file it. Out of scope, or matches intent, or purely an idea = backlog it (or drop it). Not sure = ask me first. One 30-second question to Claude Code beats a bounced ticket.

Next: 04 — Linear QA Workflow for exactly how to log, label, and track.