QA Onboarding — Cara / Pinley Mechanical¶
Welcome. This section is your living reference for testing Cara (full name "Cara Construction Intelligence") — the construction platform built for Pinley Mechanical / HVAC Construction Inc. — ahead of the July pilot and September rollout. The product and the AI assistant inside it are both called Cara; if you see "Kara" or "Kera" in older tickets or notes, that's the same product (see the naming note in the Product & Domain Primer).
You are an expert QA engineer but new to this product, this domain (construction + insurance compliance), and this codebase. These docs explain what each feature is, how it's supposed to work, and how to test it — in plain language, no developer background assumed. When a doc isn't enough, you have a second, always-available reference: me (Claude Code, in this repository). Section 03 explains how to use me.
What you're testing, in one paragraph¶
Cara is an all-in-one platform for a mechanical/HVAC construction company (HVAC Construction Inc.). It runs the whole lifecycle of a job: winning work (bids → estimates → proposals), then running the awarded project (daily logs, RFIs, submittals, change orders, billing), with an AI assistant (Cara) layered throughout. There's also an insurance-compliance side (certificates of insurance, indemnity) that is mostly out of scope for the July pilot. Your first job is the July pilot: a small real-data test with two Pinley employees (Alex and Jim) before July 29, 2026, leading to a full company rollout in September.
The single most important thing to read first¶
02 — Module Test Charter tells you what is in the July pilot vs. what is September scope / not built yet. Filing bugs against unbuilt or being-redesigned features wastes everyone's time. When in doubt about whether something is "supposed to work yet," check that doc or ask me.
The docs¶
| # | Doc | What it gives you |
|---|---|---|
| 01 | Product & Domain Primer | What Cara is, who the users are (roles + what each can see), the end-to-end workflow, and the immutability rules you must respect. |
| 02 | Module Test Charter | Priority-ordered, per-module: what it does, happy path, high-risk edge cases, role/permission checks, data-integrity checks. July scope vs. September scope clearly marked. |
| 03 | How to Test in This Setup | Getting the staging URL + role logins, how to use me (Claude Code) to answer "how is X supposed to behave?", and how to tell a real bug from intended behavior before filing. |
| 04 | Linear QA Workflow | Exactly how you log, label, and track every bug — the fast way with the /qa-report skill, plus the manual template as fallback. The rule about what belongs in the launch cycle vs. the backlog. |
| 05 | Conor Sync Prep | Questions to ask Conor (the client CEO) in your first meeting, and a short summary of your testing approach to share with him and in the weekly QA sync. |
| 06 | Test Files & Walkthroughs | Where to download realistic test files (drawings, PDFs, estimates, photos) from the shared Drive, and where the click-by-click feature walkthroughs live. |
| 07 | Glossary | Construction, insurance, and Cara-specific terms in plain language, alphabetical. Bookmark this — new terms get added here as testing surfaces them. |
Fastest possible start (day one)¶
- Read 01 (product primer) end to end — ~20 min. It gives you the mental model.
- Skim 02 (charter) and note which modules are July-scope. Don't try to test everything at once.
- Get environment access and role logins — see 03 (staging + dev URLs and the role-switcher; ask Marko if anything's missing).
- Read 04 so your very first bug is logged correctly — easiest is to run
/qa-reportin Claude Code, which handles the cycle,qalabel, priority, and assignee for you and stops for your OK before filing. - Log in, pick one July-scope module (Bids or Daily Logs are good starters), and walk its happy path while watching for the edge cases in 02. Realistic test files (drawings, PDFs, estimates, photos) are in the shared Drive folder — see 06.
Who's who¶
- Conor Halpin — client CEO (Pinley/Cara). Owns product vision — he generated the specs and prototype himself and thinks deeply about workflow. Prefers direct, decisions-first communication; lead with the point, no hedging. His top pilot worry: the first weeks getting consumed by file/access friction rather than genuine bug-fixing, so he wants the experience to feel seamless enough that Alex and Jim trust the system. He values a professional QA eye precisely because he knows he and the devs skip edge cases — he expects you to find what they miss.
- Marko Plesa — engineering + program lead on our side. Reviews your bug assignments daily and reassigns as needed. Your go-to for staging access and "who owns this."
- Marijana Berket — QA engineer running hands-on testing across every July-pilot surface. Verifies every fix on staging and keeps the
qaLinear queue moving. Ask her what's already been tested and verified, what's a known gap vs. a real bug, and how a specific flow actually behaves in the current build before assuming something's broken. - Ivan Smirnov (Ivan S) — architecture / client liaison; helping onboard you.
- Devs: Ivan Bukovac (Ivan B) — bids, estimating, projects, imports; Artem — drawings, project detail, PDFs; Mateo — Cara AI + UI/UX (part-time, on holiday in August).
Ground rule¶
You are doing manual + exploratory QA only. You never change code. When you suspect a bug, you investigate and report — you don't fix. (I can help you investigate; I also don't change code for you during QA.)
Last updated: 2026-07-07. Maintained as a living reference — ask Claude Code to update any doc as the product changes.