Answer
How a partner's feedback, a QA finding or Param's own test becomes a fix for every brand, and how the person who raised it hears that it is live.
Today
Where feedback comes from
| Source | How it arrives | Source |
|---|---|---|
| Sai's QA sheet | The Feed QA Master, Bug Tracker tab. 49 bugs fixed on 19 Oct and checked again on 20 Oct. | memory brew-qa-sweep-2026-10-19 |
| Audits by Claude sessions | Read only auditors across brands. About 86 findings on 20 Oct. | memory brew-qa-audit-2026-10-20 |
| QA reports Param approves | Round 2 report of 23 Oct, approved by section, fixed 24 Oct, re-checked on production 25 Oct night. | memory brew-qa-round2-2026-10-24 |
| Param's screenshots | Arata jam screenshots on 26 Oct led to five root causes fixed the same night. | memory brew-jam-rca-2026-10-26 |
| Partners in the product | Hiding a card or saying fewer from an agent teaches the feed. | brew/public/app.js:1930-1931, 2538 |
| Partners dropping files | Drop anything goes through learnings and can rewrite the Plays it touches. | brew/public/app.js:5693; memory brew-drop-learnings |
| Partners by email | The Help row opens an email to hello@joinsquareup.com. Terms ask them to tell us when things break. | brew/public/live.js:339; brew/legal-pages.js:40 |
The rules a fix follows
- Every fix works for every brand, every card, every widget and every view, and saved data heals. memory feed-for-all-brands
- Every bug is fixed in code, with a test or audit that would have caught it. A hand patch to one brand is only a stopgap and is said so. memory fix-as-product
- Phased work gets an exhaustive quality and verification round after each phase, and three more before closing. memory brew-qv-process
- After a change, deploy so Param can test on the live address. memory always-deploy-to-test
What is missing
- No step tells the partner who raised it that the fix is live. Nothing in the sources records closing back.
- Feedback by email has no tracker. QA sheets and reports live in Drive and artifacts.
Tomorrow
| Version | Tag | Item |
|---|---|---|
| v1 | New | One path for all feedback: it lands in Next with its source, the brand and a screenshot. |
| v1 | New | Close back: when a partner's issue is live, the person who raised it gets a short reply from a named person. |
| v1 | Stays | Fix as product, for every brand, with a test and a heal. |
| v1 | New | A weekly founder note to partners that names what changed because of them, without numbers that go stale. |
| v2 | New | A Report a problem row in the account menu that sends the screen, the brand and the card with the message. |
How we do it
Write the feedback into Next: who raised it, the brand, the screen, a screenshot, the date.
Find the shared cause. Ask where else it happens: other brands, card kinds, widgets, views, saved data.
Fix it in brew code, add a test in
test/or an audit intools/, and heal saved reads and workspaces on load.Deploy to staging, check on several brands, then promote to production with
tools/promote.sh.cd /Users/param/Documents/ChatGPT/brew && tools/promote.shMark it done in Next and remove it from known issues.
Tell the person who raised it, in the same thread they used, that it is live.
Numbers
| Metric | Definition | Where measured | State |
|---|---|---|---|
| Time to fix | Days from the report to the fix live on production | Next, against git log | Proposed |
| Closed back share | Share of partner reports where the partner was told it is live | Next | Proposed |
| Repeat bugs | Bugs that came back on another brand after a fix | Next, tagged repeat | Proposed |
| Feed teaching | Hides and fewer from taps per partner per week | feed state per workspace | Proposed |
Open
- Where does all feedback live? Proposal: Next, with one row per report, linked from the QA sheet and reports.
- Who closes back to partners? Proposal: the partner's owner from partner onboarding.
- Do we send a weekly founder note? Proposal: yes during the design partnership, signed by Param, naming one thing that changed because of a partner.