docs(phase-9-a): fill in real module READMEs, add CHANGELOGs, fix stale HANDOFF

- Replace the Phase-0 "content to be completed" placeholder Usage section
  in every community_* README.rst with the actual features built across
  Phases 1-6 (routes, crons, portal pages).
- Add CHANGELOG.rst (19.0.1.0.0) to every community_* module.
- Note independent-vs-bundled module relationships in the root README.
- Fix HANDOFF.md: Phase 8 was already committed (9a24691) and a git
  remote is configured, contrary to what it still said; record 9-A
  progress and the open gaps (missing banner.png assets, live
  --test-enable suite not re-run this session, no v1.0.0 tag yet).

HANDOFF.md

@@ -17,8 +17,8 @@ file is the "where things actually stand" companion to it.
 | 5 | `community_interac` (Interac e-Transfer payment provider) | ✅ Done, committed |
 | 6 | `community_theme_base` + `community_portal` | ✅ Done, committed |
 | 7 | `tncsc_deployment` (client config layer) | ✅ Done, committed |
-| 8 | TNCSC data migration scripts | ✅ Written and verified live, **not committed** — see below |
+| 8 | TNCSC data migration scripts | ✅ Done, committed (`9a24691`) |
-| 9 | Packaging for resale + production go-live | ⬜ Not started |
+| 9 | Packaging for resale + production go-live | 🟡 9-A in progress (see below); 9-B not started |
 
 Every phase 0–7 commit was verified against a **live** Odoo 19 + Postgres 16
 container before being committed — not just written and assumed to work.
@@ -27,9 +27,7 @@ documents what was built and how it was verified, including several real
 Odoo 19 API changes that don't match older docs/tutorials (see "Gotchas"
 below for the index).
 
-**No git remote is configured.** This repo only exists on this machine
+**Git remote is configured**: `origin` -> `https://git.metatroncube.in/admin/TNCSC_Odoo.git`.
-right now. Before handing off to a team, push it somewhere (GitHub/GitLab/
-etc.) — see "Handing off to a team" below.
 
 ## Resuming the dev environment
 
@@ -56,11 +54,10 @@ docker compose up -d
   ```
   This bit repeatedly during development — don't skip it when testing.
 
-## Phase 8 — exactly where it was left off
+## Phase 8 — done, committed (`9a24691`)
 
-All three migration scripts exist and have been verified against a **live**
+All three migration scripts exist, are committed, and have been verified
-Odoo instance, but **the work is not committed yet** (see "To pick this back
+against a **live** Odoo instance (see "How each was tested" below).
-up" below for why).
 
 - `scripts/_migration_common.py` — shared JSON-RPC helpers (auth, execute_kw,
   CSV normalization, a `MigrationReport` class) for the migration scripts.
@@ -146,19 +143,33 @@ before it's mistaken for anything resembling real data.
 
 ### To pick this back up
 
-The scripts work and are proven idempotent, but haven't been committed —
+Either wait for real TNCSC export samples to validate the assumed CSV
-do that first (a `feat: Phase 8 migration scripts` commit, following the
+schemas against, or move on to Phase 9.
-same "verified against a live container before committing" convention as
-every other phase), then either wait for real TNCSC export samples to
-validate the assumed CSV schemas against, or move on to Phase 9.
 
-## Phase 9 — not started
+## Phase 9 — 9-A in progress, 9-B not started
 
 Two sub-parts with very different risk profiles:
-- **9-A (productize)**: static description pages, READMEs, CHANGELOGs,
+- **9-A (productize)**: safe to do autonomously. Done so far — every
-  release tagging for the product modules. Safe to do autonomously.
+  `community_*` module has `static/description/index.html`, a real
-- **9-B (go-live)**: SSL, DNS cutover, firewall rules, backups on a **real
+  `README.rst` (Usage sections filled in past the Phase-0 placeholder),
-  production server**. This needs a human in the loop with actual server
+  and a `CHANGELOG.rst`; manifests pass `scripts/check_manifests.py`.
+  Still open:
+  - Every product manifest's `images` key points at
+    `static/description/banner.png`, but no module actually has that
+    file — the Apps-list/App-Store banner image doesn't exist yet. Needs
+    a real designed asset per module, not a placeholder.
+  - No `v1.0.0` git tag yet, and no release report — holding off on both
+    until the banner-image gap above is resolved and the full
+    `--test-enable` suite has actually been run against live Odoo (this
+    session had no Docker available, so only the static checks —
+    brand-leak grep, manifest completeness — were re-verified, not the
+    live module install/tests).
+  - No role guides (admin/treasurer/teacher/parent) written yet.
+- **9-B (go-live)**: not started. `deploy/odoo.conf` is still dev config
+  (`list_db = True`, `proxy_mode = False`, no `workers`) and
+  `deploy/nginx-communityos.conf` is an explicit "development skeleton" —
+  SSL, DNS cutover, firewall rules, and backups on a **real production
+  server** all remain. This needs a human in the loop with actual server
   access/credentials — don't let an agent run this unattended.
 
 ## Gotchas discovered this build (Odoo 19 API drift + environment quirks)
@@ -206,8 +217,8 @@ re-discovering it:
 
 ## Handing off to a team
 
-1. **Push this repo to a real remote** (GitHub/GitLab/etc.) — right now it
+1. Repo is already pushed to `origin` (see above) — confirm the team has
-   only exists locally.
+   access to `git.metatroncube.in`.
 2. Point them at `CommunityOS_Implementation_Plan_for_Claude_Code.md` (the
    plan) and this file (current status).
 3. They'll need Docker Desktop (or equivalent) to run `deploy/docker-compose.yml`

README.md

@@ -59,6 +59,19 @@ product code never changes.
 |---|---|
 | `tncsc_deployment` | TNCSC branding, tiers/prices, chart of accounts, email copy, website pages, user groups |
 
+### Independent vs. bundled
+
+Every product module installs standalone on a stock Odoo 19 CE with only
+its declared Community-core dependencies — none require another
+`community_*` module to function, with one deliberate exception:
+`community_benefits` hard-depends on `community_membership` (a benefit is
+entitled per membership tier, so the dependency is intrinsic to what it
+does). `community_school` and `community_classifieds` *soft*-detect
+`event_qr_ticketing`/`community_membership` when present and degrade
+gracefully without them. `community_portal` soft-detects all of the above
+and only renders cards for whichever are installed. This means each module
+can be sold and installed on its own, or bundled as the full suite.
+
 ## Local development
 
 ```bash

addons/community_benefits/CHANGELOG.rst

@@ -0,0 +1,9 @@
+Changelog
+=========
+
+19.0.1.0.0 (2026-08-17)
+~~~~~~~~~~~~~~~~~~~~~~~~
+* Initial release: benefit centres/vendors, per-tier benefit entitlements,
+  and a redemption log verified against the membership QR-verify endpoint.
+* Member portal page at ``/my/benefits`` and a public directory at
+  ``/benefits``.

addons/community_benefits/README.rst

@@ -11,8 +11,14 @@ Install as any Odoo module.
 
 Usage
 =====
-Content to be completed as the module is built out (see project plan,
+* Admins register benefit centres/vendors (``community.benefit.partner``)
-Phase 4).
+  and the benefits they offer (``community.benefit``), each entitled to one
+  or more membership tiers.
+* Members see the benefits their tier entitles them to at ``/my/benefits``;
+  the public directory of participating centres is at ``/benefits``.
+* A benefit centre logs a redemption (``community.benefit.redemption``)
+  after confirming the member is active via the membership QR-verify
+  endpoint, giving a verifiable usage trail per member/benefit.
 
 Credits
 =======

addons/community_classifieds/CHANGELOG.rst

@@ -0,0 +1,9 @@
+Changelog
+=========
+
+19.0.1.0.0 (2026-08-17)
+~~~~~~~~~~~~~~~~~~~~~~~~
+* Initial release: public classifieds board, member-gated posting
+  (soft-detects ``community_membership``), admin moderation queue.
+* Auto-expiry, 7-day expiry warning, and new-submission notification
+  crons.

addons/community_classifieds/README.rst

@@ -10,8 +10,15 @@ Install as any Odoo module.
 
 Usage
 =====
-Content to be completed as the module is built out (see project plan,
+* Public board at ``/classifieds`` (list, filter, search); detail page at
-Phase 4).
+  ``/classifieds/<id>`` increments a view counter.
+* Posting at ``/classifieds/new`` requires portal login, and an active
+  membership if ``community_membership`` is installed (soft-detected).
+* Submissions start ``pending_review``; admins publish or reject from the
+  moderation queue. Listings auto-expire on a configurable number of days
+  after posting, with a 7-day expiry warning email and an admin
+  notification on every new submission. Posters manage their own listings
+  and renew them at ``/classifieds/my`` and ``/classifieds/<id>/renew``.
 
 Credits
 =======

addons/community_interac/CHANGELOG.rst

@@ -0,0 +1,9 @@
+Changelog
+=========
+
+19.0.1.0.0 (2026-08-17)
+~~~~~~~~~~~~~~~~~~~~~~~~
+* Initial release: Interac e-Transfer ``payment.provider`` for the Odoo 19
+  payment framework, with configurable instructions email.
+* Treasurer "Pending Interac" admin view with one-click confirmation, and
+  an auto-cancel cron for unconfirmed transactions.

addons/community_interac/README.rst

@@ -11,8 +11,18 @@ Install as any Odoo module.
 
 Usage
 =====
-Content to be completed as the module is built out (see project plan,
+* Registers as a standard Odoo 19 ``payment.provider``/``payment.method`` —
-Phase 5).
+  select "Interac e-Transfer" at any checkout that uses the payment
+  framework (membership renewal, event registration, school fees).
+* Choosing it sets the transaction to ``pending`` and emails configurable
+  instructions (recipient e-transfer address, amount, reference code
+  ``REF-{tx}``, deadline) — recipient address, org name, and copy all come
+  from the provider configuration, never hardcoded.
+* Treasurers confirm receipt from the **Pending Interac** admin view with a
+  one-click "Payment received," which marks the transaction ``done`` and
+  confirms the linked order/registration/invoice.
+* An unconfirmed transaction auto-cancels (with a notification email) after
+  a configurable window, via a scheduled cron.
 
 Credits
 =======

addons/community_membership/CHANGELOG.rst

@@ -0,0 +1,12 @@
+Changelog
+=========
+
+19.0.1.0.0 (2026-08-17)
+~~~~~~~~~~~~~~~~~~~~~~~~
+* Initial release: configurable membership tiers, ``res.partner`` extension
+  (member ID, tier, state, family grouping, volunteer hours), and
+  membership settings.
+* Renewal automation: daily cron, configurable email templates, draft
+  renewal invoices.
+* QR membership card (QWeb PDF), public verification endpoint, and
+  self-service member portal at ``/my/membership``.

addons/community_membership/README.rst

@@ -15,8 +15,19 @@ Settings > Members > Membership Settings.
 
 Usage
 =====
-Content to be completed as the module is built out (see project plan,
+* Define tiers under **Members > Configuration > Tiers** (name, code, price,
-Phase 1).
+  period). Each tier auto-creates its membership product.
+* A partner's ``membership_member_id`` is generated on activation using the
+  format string configured in Membership Settings (default
+  ``MEM-{year}-{seq}``).
+* A daily cron moves members to ``renewal_due`` at the configured reminder
+  offsets and to ``expired`` on expiry, sending the matching email template
+  and creating a draft renewal invoice for review.
+* Members self-serve at ``/my/membership`` (status, tier, expiry, renew,
+  download card) and can be verified publicly, without exposing personal
+  data, at ``/membership/verify/<member_id>``.
+* The QR membership card is a QWeb PDF report (85mm x 54mm) whose QR code
+  encodes the verification URL.
 
 Credits
 =======

addons/community_portal/CHANGELOG.rst

@@ -0,0 +1,8 @@
+Changelog
+=========
+
+19.0.1.0.0 (2026-08-17)
+~~~~~~~~~~~~~~~~~~~~~~~~
+* Initial release: unified member dashboard at ``/my`` that soft-detects
+  whichever Community OS product modules are installed and renders only
+  their cards.

addons/community_portal/README.rst

@@ -11,8 +11,14 @@ Install as any Odoo module.
 
 Usage
 =====
-Content to be completed as the module is built out (see project plan,
+* Renders a member dashboard at ``/my`` that soft-detects whichever product
-Phase 6).
+  modules are installed and shows only their cards: membership status (if
+  ``community_membership``), upcoming registered events/tickets (if
+  ``event_qr_ticketing``), a child's schedule/attendance at ``/my/school``
+  (if ``community_school``), entitled benefits (if ``community_benefits``),
+  and a member's own classifieds (if ``community_classifieds``).
+* Uninstalling any one of those product modules removes its card without
+  breaking the rest of the dashboard.
 
 Credits
 =======

addons/community_school/CHANGELOG.rst

@@ -0,0 +1,14 @@
+Changelog
+=========
+
+19.0.1.0.0 (2026-08-17)
+~~~~~~~~~~~~~~~~~~~~~~~~
+* Initial release: terms, configurable levels, classes, students,
+  enrollment, and attendance models.
+* Teacher attendance portal at ``/school/attendance`` with batch save and
+  configurable absence emails; admin attendance pivot report and
+  at-risk flag.
+* Multi-step parent registration at ``/school/register`` with automatic
+  waitlisting, and ``website_slides`` LMS glue (auto channel creation and
+  enrolment).
+* ``scripts/migrate_classroom.py`` for bulk-importing existing assignments.

addons/community_school/README.rst

@@ -11,8 +11,21 @@ Install as any Odoo module.
 
 Usage
 =====
-Content to be completed as the module is built out (see project plan,
+* Admins define terms, levels (e.g. Beginner..Advanced, or Grade 1-12 —
-Phase 3).
+  entirely configurable), and classes; teachers are ``res.partner`` records
+  flagged ``is_teacher``.
+* Parents register at ``/school/register`` in three steps (parent -> student
+  -> class + payment), which creates the child contact, student record, an
+  enrollment, and a fee invoice. Full classes fall back to a waitlist that
+  is notified automatically when a seat frees up.
+* Teachers take attendance from ``/school/attendance`` (today/this week
+  roster, batch Present/Absent/Late/Excused save); an ``absent`` mark
+  queues a configurable email to the parent. Admins get an attendance
+  pivot report and an "at-risk" flag below a configurable threshold.
+* Each class auto-creates a ``website_slides`` channel; enrolling/
+  withdrawing a student enrols/unenrols them from it automatically.
+* ``scripts/migrate_classroom.py`` bulk-imports existing assignments (CSV of
+  title + Drive/YouTube URL) as slide records.
 
 Credits
 =======

addons/community_theme_base/CHANGELOG.rst

@@ -0,0 +1,8 @@
+Changelog
+=========
+
+19.0.1.0.0 (2026-08-17)
+~~~~~~~~~~~~~~~~~~~~~~~~
+* Initial release: brand tokens (colours, logo, fonts) exposed via
+  settings and injected as CSS variables across the website, member
+  portal, and PDF reports. Neutral default layout, no client colours.

addons/community_theme_base/README.rst

@@ -16,8 +16,14 @@ Settings > Website > Community OS Theme.
 
 Usage
 =====
-Content to be completed as the module is built out (see project plan,
+* Set primary/secondary/accent colours, logo, and heading/body fonts once
-Phase 6).
+  under Settings > Website > Community OS Theme.
+* Those tokens are injected as CSS variables across the public website, the
+  member portal, and PDF reports (e.g. the membership card), so a new
+  deployment can rebrand entirely with data — no SCSS edits required.
+* Ships with a neutral default navbar/footer layout and no client colours
+  in code; a fresh install looks generic until a deployment module (or an
+  admin) sets its own brand tokens.
 
 Credits
 =======

addons/event_qr_ticketing/CHANGELOG.rst

@@ -0,0 +1,10 @@
+Changelog
+=========
+
+19.0.1.0.0 (2026-08-17)
+~~~~~~~~~~~~~~~~~~~~~~~~
+* Initial release: signed QR ticket per event registration, attached to the
+  standard CE registration confirmation email.
+* Staff check-in / verification screen at ``/event/checkin``, with
+  duplicate and forged-token guards, and a per-event registered vs.
+  checked-in dashboard.

addons/event_qr_ticketing/README.rst

@@ -11,8 +11,15 @@ Install as any Odoo module.
 
 Usage
 =====
-Content to be completed as the module is built out (see project plan,
+* Every ``event.registration`` gets a unique ``ticket_ref`` and a QR code
-Phase 2).
+  encoding a per-database-signed token, attached automatically to the
+  standard CE registration confirmation email as a PDF ticket.
+* Staff check attendees in at ``/event/checkin/<event_id>`` (camera scan or
+  manual ticket-ref entry, restricted to the Event User group). The scan
+  endpoint verifies the token signature and rejects forged or already
+  used tickets.
+* A per-event dashboard on the same page shows registered vs. checked-in
+  counts in real time.
 
 Credits
 =======