Update the docs for a team of four

CONTRIBUTING.md

@@ -1,6 +1,6 @@
 # Contributing to IPO Lens
 
-Five of us are building this over two weeks, often on different parts at once. This file explains how we track who is doing what and keep anyone's work from being overwritten.
+Four of us are building this over two weeks, often on different parts at once. This file explains how we track who is doing what and keep anyone's work from being overwritten.
 
 ## The short version
 
@@ -107,9 +107,9 @@ If the change was worth keeping, redo it as an ordinary commit ending `Step: #<n
 
 ## Reviews without blocking each other
 
-Five people and one required approval can still leave PRs waiting for days. What keeps them moving:
+Four people and one required approval can still leave PRs waiting for days. What keeps them moving:
 
-- **Review buddies.** Each person's PRs go to the next person in the circle first: Divyansh → Sourav → Avi → Anay → Manish → Divyansh. If your buddy hasn't picked it up within 6 hours, anyone else can.
+- **Review buddies.** Each person's PRs go to the next person in the circle first: Divyansh → Sourav → Avi → Anay → Divyansh. If your buddy hasn't picked it up within 6 hours, anyone else can.
 - **Post the link.** When a PR is ready, drop it in the group chat with one line on what it does.
 - **Keep PRs small.** One step should take 10 to 15 minutes to review. If yours is much bigger, split the step.
 - **Review twice a day.** Check your queue once around lunch and once in the evening, before starting new work.
@@ -243,4 +243,4 @@ For the repo owner. Set these once.
 - Push protection: on
 
 **Settings → Collaborators**
-- All five of us with write access
+- All four of us with write access

README.md

@@ -113,6 +113,6 @@ flowchart LR
 
 ## Team
 
-Sourav · Avi · Anay · Manish · Divyansh
+Sourav · Avi · Anay · Divyansh
 
 Built for the [SerpApi India Hackathon 2026](https://serpapi.github.io/serpapi-india-hackathon-2026/), Commerce & Market Intelligence track.

docs/brief.md

@@ -126,7 +126,7 @@ Tick these off as they are met.
 - [ ] Track selected: Commerce & Market Intelligence
 - [ ] The tools disclosure for the form is written
 - [ ] "Project existed before the hackathon" is left unticked, since it didn't
-- [ ] All five team members meet the eligibility rules and are listed
+- [ ] All four team members meet the eligibility rules, have contributed, and are listed
 - [ ] "Submit project" selected before 5 Oct 2026, 23:59 IST
 
 ## Ambiguities to raise

docs/changes.md

@@ -33,3 +33,13 @@ Project-level decisions and the reasons behind them. Step-level detail lives in
 - Peers roughly triple the searches per brief, from about 15 to about 45, so the cache carries more of the load.
 - Divyansh takes the project skeleton, with the Play Store adapter as the reference the others copy. Sourav reviews that PR, and Divyansh reviews #4.
 - boAt's data gets captured before its IPO is expected to open on 27 Sep. Every signal shows when it was fetched, so a demo run from the cache still states the date of its data.
+
+## 2026-09-23
+
+- Manish has left the team, so there are four of us: Sourav, Avi, Anay and Divyansh. His parts get handed to the other four, and the split goes into the work plan when it's added to the repository. The review circle is now Divyansh → Sourav → Avi → Anay → Divyansh.
+- The submission form lists only people who contributed to the project. The Rules require that of every listed member, and a false team claim is grounds for disqualification.
+- Four free SerpApi accounts give 1,000 searches a month instead of 1,250.
+- Step #5 merged, so the skeleton is on `main` and the adapters can start. Every adapter copies `play_store.py`.
+- Three decisions from the review of #5 shape every adapter. Signals carry a stable `key`, because their names include a review count that differs between companies, and comparisons need something fixed to match on. An app can be pinned by its `product_id`, which the claims files hold, because a whole-word name match still can't tell boAt from another app with "Boat" in its title. The scrubber masks phone numbers and emails even in text that holds a link, because the fixtures and the demo snapshot are public.
+- `.python-version` pins 3.12, the version CI runs, and `.gitattributes` stores text files with LF endings. `docs/architecture.md` still has CRLF from #2 and gets renormalised when it's next edited.
+- On 22 Sep the `main` ruleset turned out to require linear history, which rejects merge commits and had blocked #4. It now allows merge commits only, requires `steps-guard` and `lint-and-test`, dismisses stale approvals and asks for approval of the latest push.

docs/progress.md

@@ -1,25 +1,29 @@
 # Progress
 
-_Updated: 2026-09-22_
+_Updated: 2026-09-23_
 
 The issue board shows who is working on what right now. This file holds the plan and the milestones. It changes in its own step when the plan changes, not as part of feature work.
 
 ## Now
 
-Project skeleton (Divyansh). `pyproject.toml` with uv, Ruff and pytest, a committed `uv.lock`, the SerpApi client with its file cache and credit budget, and the Play Store adapter with tests as the reference every other adapter copies. No other adapter can start until this lands, and `lint-and-test` stays idle until `pyproject.toml` exists.
+The skeleton is merged, so the parts run in parallel. Each adapter copies `src/ipolens/sources/play_store.py`.
+
+- boAt capture, before its IPO is expected to open on 27 Sep. It was Manish's, so it needs an owner now. It has to use exactly the parameters each adapter will use, because the cache finds a saved answer by its parameters, so Sourav fixes the Maps city list first. Decide before the capture whether a scrubbed `demo/` snapshot gets committed, since `cache/` stays on one laptop.
+- Adapters: Maps (Sourav), Trends (Avi), News and Jobs (Anay). App Store and Finance were Manish's and need owners.
+- Claims files for OYO, Atomberg and boAt, with each company's listed peers and its Play Store app id (Anay).
+- The comparison set: Divyansh drafts it, and the group agrees on it before `compare/` starts.
+- The app screen on sample data (Avi), until the adapters land.
 
 ## Next
 
-1. Repository settings (Sourav): turn off squash and rebase merging under Settings → General → Pull requests, turn off automatic code review, and mark `steps-guard` and `lint-and-test` as required checks. Both have run once now, so GitHub offers them in the picker. Finish the Ruleset list in `CONTRIBUTING.md`; "Restrict updates" and "Require linear history" stay off.
-2. Capture boAt before its IPO is expected to open on 27 Sep. The cache keeps raw responses, so this needs only the client: fetch boAt's seven sources now, and the adapters parse the saved responses once they exist. `cache/` is gitignored, so the capture stays on one laptop. Agree who records the demo.
-3. Write the claims files for OYO, Atomberg and boAt, with each company's listed peers copied from its filing.
-4. Settle the fixed comparison set and write it into `docs/architecture.md` before the comparison code starts.
-5. One source adapter per person, in parallel, each following the Play Store adapter. Each needs a scrubbed fixture in `tests/fixtures/` and a test.
-6. Signals and comparisons, then the brief, then the Streamlit UI, then the optional written summary.
-7. Licence: add MIT.
-8. Demo dry run on OYO and Atomberg once the adapters land, to confirm all seven sources return data for both.
-9. Submit a complete entry as soon as the app runs end to end. The website stamps the submission time at first submit and editing never resets it, so submitting early costs nothing.
-10. Feature freeze on 2 Oct. After that: test the README setup on a clean machine, record the demo, finish the description and the SerpApi usage explanation, submit.
+1. Repository: confirm automatic code review is off, which the API can't show, and add the MIT licence.
+2. `docs/architecture.md`: write in the 22 Sep data check for OYO and Atomberg, take `signals/` out of the tree, since each adapter has its own `signals()`, and store the file with LF endings.
+3. Comparisons (`compare/`) once the set is agreed and the adapters it uses have landed, then the brief with peer runs, then the app screen wired to real data.
+4. The written summary only if time allows. It has no owner and is the first thing to drop.
+5. The demo snapshot under `demo/`, scrubbed, so the app runs offline with no key.
+6. Demo dry run: the whole app on OYO and Atomberg once the adapters land.
+7. Submit a complete entry as soon as the app runs end to end. The website stamps the submission time at first submit and editing never resets it, so submitting early costs nothing.
+8. Feature freeze on 2 Oct. After that: test the README setup on a clean machine, record the demo, finish the description and the SerpApi usage explanation, submit.
 
 ## Done
 
@@ -30,7 +34,10 @@ Project skeleton (Divyansh). `pyproject.toml` with uv, Ruff and pytest, a commit
 - Step #2 merged on 2026-09-21. Rules, workflow, docs and both PR checks are on `main`.
 - Demo companies chosen on 2026-09-21: OYO and Atomberg, plus boAt if captured before 27 Sep
 - Product framing agreed on 2026-09-22: comparisons against the company's own numbers and against listed peers (see `docs/architecture.md`)
+- Repository settings applied on 2026-09-22: merge commits only, and the `main` ruleset requires `steps-guard` and `lint-and-test`, dismisses stale approvals and asks for approval of the latest push.
+- Data check on OYO and Atomberg on 2026-09-22: all seven sources returned data.
+- Step #5 merged on 2026-09-23: the project skeleton, the SerpApi client with its cache, budget and offline mode, the scrubber, and the Play Store reference adapter, with 27 tests. `lint-and-test` now runs for real.
 
 ## Blocked
 
-Nothing is blocked.
+Manish's parts wait on the team agreeing who takes them: the boAt capture, App Store, Finance, the demo snapshot and the README setup test. The boAt capture can't wait past 27 Sep.

docs/standards.md

@@ -2,7 +2,7 @@
 
 ## Principles
 
-Adapted from [webpro/programming-principles](https://github.com/webpro/programming-principles), picked for five people working in parallel for two weeks.
+Adapted from [webpro/programming-principles](https://github.com/webpro/programming-principles), picked for four people working in parallel for two weeks.
 
 **We follow:**
 - **Simplest thing that works (KISS).** Choose the plainest solution that meets the step's goal.

docs/steps/007-team-of-four.md

@@ -0,0 +1,31 @@
+# Step #7: Update the docs for a team of four
+
+- **Owner:** Sourav
+- **Builds on:** #2, #4
+
+## What was done
+
+- `CONTRIBUTING.md` says there are four of us, the review circle is Divyansh → Sourav → Avi → Anay → Divyansh, and the repository settings list gives write access to all four.
+- The README team line lists Sourav, Avi, Anay and Divyansh.
+- `docs/standards.md` says its principles were picked for four people.
+- The eligibility item in the `docs/brief.md` checklist says the listed members have to have contributed.
+- Added a 2026-09-23 entry to `docs/changes.md`.
+- Synced `docs/progress.md` now that step #5 is merged. Now lists the parts running in parallel, with the boAt capture first because of its date, and Next is renumbered. Manish's old parts appear without owners, because the team hasn't agreed who takes them. The 2026-09-23 entry in `docs/changes.md` also records the #5 merge, the review decisions every adapter inherits and the ruleset change from 22 Sep.
+
+## Changes to earlier steps
+
+These lines were written in #2. The dated history stays as it is: the 2026-09-20 entry in `docs/changes.md` and the decisions in `docs/architecture.md` still say five, because that was true when they were written.
+
+## Decisions
+
+- The submission form lists only people who contributed. The Rules require that of every listed member, and a false team claim is grounds for disqualification.
+- Manish had no access to the repository, so no settings needed changing.
+- The sync rides in this step instead of its own. Both edit the 2026-09-23 entry in `docs/changes.md`, so two PRs would conflict there, and a change to the team is a change to the plan.
+
+## Known weaknesses
+
+- The work plan that hands out Manish's parts isn't in the repository. Divyansh wrote it, so adding it is his call.
+
+## Follow-ups
+
+- Add the work plan to the repository, if the team wants it there.