Management Hub — sơ đồ vận hành & kế hoạch tích hợp

Status: design-locked (Option B) · architecture 2026-05-31, build backlog reconciled with the per-flow walkthrough 2026-06-02 · author: Claude session (decisions in §7 still hold; the real-data mount P1–P5 is not yet built). This revision folds in everything the per-flow walkthrough surfaced so §8 is a start-ready build list. Companion to: _system/notes/management-hub-workflows-walkthrough-2026-05-31.md (the end-to-end operating detail + per-flow Gaps — the source for §8), _system/notes/management-hub-mockup-handoff-2026-05-31.md, _system/plans/donor-and-finance-subplan.md, _system/plans/story-archive-subplan.md, memory project_management-hub-integration-plan. The live mockup is v2.1+ at https://hmt-media-review.pages.dev/management-hub/ (Quản lý học sinh tab expanded 2026-06-02) and the walkthrough at …/management-hub-workflows/.

This doc answers two asks:

• Workflow sketch — every built-out area, its data + services, and the hub

panel it maps to.

• Integration plan — how to bring the existing build under one hub

(Option B: one app, one login, mounted sub-apps), in de-risked phases.

Phase A is untouched throughout: the hub reads and routes; every sensitive action (approve-with-dignity, watchlist escalation, thank-you send) stays in its own surface behind the login. No auto-publish; no channel-publisher cron.

**Update 2026-06-02 (workflow reshape, administrator-confirmed — reconciled

with the per-flow walkthrough).** The mockup + walkthrough (`management-hub-

workflows`) evolved past the v2.1 panel set captured below. The Option-B

architecture and phase ordering (§3, §7) are unaffected; what changed is the

per-workflow build backlog, now catalogued in §8. Net changes:

- Media is on-demand, not auto-drafted. Bringing an activity into the Hub

(folder + photos + watch-job row) is its own workflow that ends at the Hub;

the daily pipeline narrows to ingest + sanitise only. Story drafting

fires on a per-activity "Yêu cầu viết bài" button, taking a **direction

box + an optional user-selected photo set. Not yet decoupled** — today

the daily pipeline still runs straight through cull→retouch→caption. (§8-A.)

- **Finals archive to the EXISTING 10_Cau-chuyen/ story band — the

09_Mang-xa-hoi/ band is NOT provisioned** (decision revised the same day,

2026-06-02). The social-final vs story-record distinction is carried by

registry.post tags, not a separate Drive band. (Supersedes the earlier

"new 09_ band" note. story-archive-subplan.md, walkthrough §2/§4.B.)

- The registry.post writer is the single most important unbuilt gap. There

is no INSERT INTO post anywhere; the manual-publish loop ends at

publish.yaml + posted_id and never back-fills registry.sqlite, so the

Presence read-view + content-plan suggestions read zeros until it exists.

Added to P2. (§8-B, walkthrough §7/§10.)

- A human-gated self-improve summary of the admin's edits is sent for review

before anything is applied to prompts/few-shot (not auto-optimize's own

cadence). (§8-A.)

- New Khảo sát (survey & selection) workflow — a #survey hub panel + a

candidate survey-Form → restricted 11_Khao-sat/ band → a **candidate

register (own store until admission) → human "admit"** → mints

journey-NNNN → hands to Care. Internal-only; never a published post. Entirely

unbuilt. (§8-D, walkthrough §1b.) Care panel renamed Quản lý học sinh.

- Email-link-back (the new-folder link emailed to the form submitter) is a

new unbuilt step shared by both the activity intake (§1) and the survey intake

(§1b). (§8-A/D.)

- Donor/Finance split into two panels — **#donors (Tài trợ — engagement &

communications) and #finance (Tài chính — transparency & distribution)**;

plus a standalone donor-engagement mockup. A scoped relaxation lets the

transactional thank-you + receipt auto-send (receipts only; newsletters +

appreciation stay human-approved) — recorded in .claude/rules/autonomy-phase.md.

The bank-credit trigger is unbuilt (today: manual NCB-CSV); candidate under

review is the SePay Open-Banking webhook (§8-E). (workflows-doc §4 / §5;

donor-and-finance-subplan.md 2026-06-02 block.)

- The old presence/community/about hub panels from v2.1 were folded/dropped in

the current mockup; the operating-loop framing is unchanged.

1. The four areas (what is actually built)

Three SQLites, split by privacy boundary, never ATTACH-joined — any cross-area read (e.g. a benefit funded by a specific donor) happens at the application layer. Areas 3 + 4 share so-tai-chinh.sqlite (the contribution table) but are split into two hub panels. The candidate register (1b) stays separate from so-dang-ky.sqlite until admission, then the admitted candidate becomes a journey-NNNN in the care store.

2. Workflow sketch — the operating loop and where each surface lives

            FIELD                EDITORIAL              AUDIENCE            RESOURCES
   ┌────────────────────┐  ┌──────────────────┐  ┌──────────────┐  ┌──────────────────┐
   │ brief-form submit  │  │ content plan     │  │ approved post│  │ donor gives      │
   │  → event folder    │  │  (12mo + 3mo)    │  │  → FB + web  │  │  cash / in-kind  │
   │ photos to Drive    │  │  ↑ pulls from    │  │              │  │  → thank-you +   │
   │  → ingest-watch    │  │  trips, holidays,│  │ presence:    │  │    receipt       │
   │  → registry.sqlite │  │  milestones,     │  │  cadence,    │  │  → transparency  │
   │                    │  │  journey miles   │  │  80/20,      │  │    report        │
   │ pipeline:          │  │                  │  │  petal cover │  │                  │
   │  sanitise→triage→  │  │ orphan-trip flag │  │              │  │ community:       │
   │  retouch→caption→  │──┼─▶ feeds plan     │  │ comments →   │◀─┤  "where it went" │
   │  QC (gate 1)       │  │                  │  │  replies     │  │   follow-ups     │
   │  → awaiting-approval│ │ queue: approve   │  │  (Op1)       │  │                  │
   └─────────┬──────────┘  │  with dignity_ok │  └──────┬───────┘  └────────┬─────────┘
             │             └────────┬─────────┘         │                   │
   CARE (parallel, field-driven):   │                   │                   │
   intake→promote→profile+benefits  │                   │                   │
   +watchlist  ──── journey miles ──┘                   │                   │
                                                         ▼                   ▼
                                              everything closes the transparency loop

Area → hub panel map

So the hub is 3 mounts (care, review, finance — finance serving both the #donors and #finance panels) + 3 new read-views (trips, presence, overview) + 2 new surfaces with their own data (content plan, survey/candidate register) + 1 placeholder (community).

3. Target architecture (Option B)

One Cloud Run Service management-hub, one login, this route layout:

app/hub.py  (new parent — owns login + session middleware)
  /                     → Overview        (native; action strip = 3 DB reads)
  /trips                → Trip ledger     (native read-view; orphan-trip flag)
  /survey               → Candidate survey & selection (native; new register store)
  /plan                 → Content plan    (native; new content-plan.yaml store)
  /presence             → Social presence (native read-view; needs post-row writer)
  /community            → placeholder     (native static)
  /login /logout        → parent-owned (care_auth session)
  /care/*    → mount  app.main:create_app(...)            auth OFF (parent gates)
  /review/*  → mount  app.review_main:create_app(...)     auth OFF (parent gates)
  /finance/* → mount  app.finance_dashboard:create_finance_app(...)  → serves both
               the #donors (Tài trợ) and #finance (Tài chính) panels

/survey is a native light read/write surface over the care bucket (the candidate register), not a mount — it shares the care DB connection but writes to a register store kept separate from so-dang-ky.sqlite until a candidate is admitted. #donors and #finance are two views of the one mounted finance app, not two services.

Single login. All three apps already import tools/care_auth.py and already expose factories (create_app, create_app, create_finance_app). The parent owns /login + the @app.middleware("http") session check; Starlette runs that middleware around mounted sub-apps too, so each sub-app is built with password_hash=None (auth_off) and trusts the parent gate. One secret pair (care-password-hash, care-session-key) already shared by review + care.

Two buckets, one service. This is the part the "50 lines" estimate missed:

• review + the trip/presence read-views need bundles bucket (registry.sqlite,

Sandbox/posts/, _system/runs).

• care + finance need care-db bucket (so-dang-ky, so-tai-chinh).

gcsfuse can mount both in one container at different paths (e.g. /data for bundles, /care-data for the care-db bucket); each sub-app's env points at its own path. This is a Cloud Run deploy-config change (two volume mounts), not app code. The single service account already has object-admin on both buckets.

4. The real wrinkles (honest scoping)

• Template absolute links break under a mount prefix. review/care/finance

templates use literal href="/bundle/...", /children/..., /donors/.... Mounted at /review etc., those point back at the parent root. Fix: switch the handful of cross-page links to request.url_for(...) (Starlette includes the mount prefix) or root-relative-to-mount. This is the main effort in the mount step — a template audit per app, not a rewrite.

• Colliding /static + /login + /healthz across sub-apps. Harmless once

mounted (each lives under its prefix, e.g. /review/static), but the parent must own the canonical /login; sub-app logins become dead routes (leave or strip).

• Content-plan has no data store, and planning is now split from drafting.

/plan is the panel whose data does not exist yet — no content-plan.yaml on disk, no board, Knowledge/Brand/facts.md missing (a prerequisite). The walkthrough §6 splits the role: a new content-strategist agent _plans_ (proposes/refreshes content-plan.yaml slots as status: idea on a monthly anchor + weekly flag-refresh cadence), while the existing content-calendar _drafts_ one Editor-confirmed slot. The Editor promotes idea → planned slot-by-slot (same human-tick discipline as dignity_ok); an unconfirmed slot cannot be drafted. The self-flagging "editorial intelligence" (orphan trips, petal gaps, 80/20 drift, observance countdown) is computed at read time, not stored — and most flags read zero until the post-row writer (#6) exists.

• Template/static resolution. Three independent Jinja2 trees + a fragmented

static/. The parent gets its own template dir; sub-apps keep theirs. Shared CSS can stay one file served by the parent.

• **Overview/Trips/Presence need live reads of two buckets + the Dashboard

Sheet. The Sheet read needs the service account creds the pipeline already uses; cache it (it changes slowly). The Overview action strip stitches three independent DB reads in Python (bundles by iterating Sandbox/posts/*/STATUS.md; care + finance each via a separate read-only connection) — never** an ATTACH-join across the files.

• No registry.post writer — the AUDIENCE leg has no data (the #1 gap).

posts_published: 0; there is no INSERT INTO post anywhere. The manual-publish loop ends at publish.yaml + a typed posted_id and never back-fills registry.sqlite, so Presence and the content-plan suggestions read zeros indefinitely until a post-row writer is built (hooked on posted_id recording, alongside the 10_Cau-chuyen/ archive write, carrying tags activity_type · petal · program · school · journey_id · theme · observance, with petal_anchor validated against the 8 canonical petals). This is not strictly "hub plumbing," but it gates a hub read-view, so P2 owns it.

• **The headless cloud pipeline runs only gate 1 + records a "gate-8 pending"

finding — agent gates 3–7 (brand-voice, dignity, claims, platform-fit) are not invoked in the cloud path, so the human approval is the real substantive QC**. Fine under Phase A (nothing posts without /approve), but worth stating: the hub surfaces the bundle for human review precisely because automated QC upstream is thin.

Honest effort: not 50 lines. Realistically 3–4 focused sessions for the hub shell itself: (a) parent shell + login + finance mount, (b) trip + presence read-views + the post-row writer, (c) content-plan artifact + plan surface, (d) review + care mount with template-link audit + the two-bucket deploy. The "~50 lines" was just the finance mount+auth. The per-workflow build items (media decoupling, survey subsystem, email-link-back, bank-credit trigger, finance lift) are separate tracks catalogued in §8 — several are independent of the hub shell and can start in parallel.

5. Phased plan (de-risked order — each phase ships something usable)

Phase 0 — decide & freeze the contract (no code). Confirm the route layout in §3 and the panel map in §2. Confirm Editor is fine with one combined public URL replacing the separate app URLs.

Phase 1 — parent shell + login + finance mount. Lowest risk: finance is the newest, simplest templates, not yet deployed, and the mount path is already designed for. Build app/hub.py (login + middleware + a static Overview reading mock numbers first), mount finance at /finance, audit finance templates for absolute links. Deploy locally; verify one login reaches finance.

Phase 2 — trip ledger + presence read-views (native, real data) + the post-row writer. No mount risk (new code). Read Dashboard Sheet + registry.sqlite for the trip ledger and the presence aggregation; wire the Overview today-strip + tiles to real numbers; orphan-trip + petal-gap computed here. Prerequisite for Presence to show anything: build the registry.post writer (§4 wrinkle 6 / §8-B) — without it Presence reads zeros. This is the single highest-value gap and is not in the original v1 phase list.

Phase 3 — content-plan: content-strategist (plans) + content-calendar (drafts) + /plan surface. Create Knowledge/Brand/facts.md (missing prerequisite); add the content-strategist agent that emits/refreshes content-plan.yaml (idea slots only); build the /plan reader + per-slot promote (idea → planned) + computed flags; add the external-photo lane (a sanitised, provenance-tagged source/ drop for Stream-B reuse). content-calendar still drafts a picked slot. This is the genuinely new product surface; can lag if the Editor wants to ship the mounts first.

Phase 4 — mount review + care; two-bucket deploy. The heaviest: template-link audit for both, build the management-hub Dockerfile, mount both GCS buckets, move the env to per-app paths, deploy as one Cloud Run Service, retire (or alias) the separate review + care-dashboard services. Verify Phase-A approve flow end to end through the mounted review app.

Phase 5 — community. Only when Op1 is actually built; the placeholder holds the slot meanwhile.

De-risking option for Phase 4: if the template audit proves fiddly, an interim is to keep review + care as their own services but share the session cookie + secret so the single login works across them and the hub deep-links (closer to A for those two, full-B for finance + the native views). Ship that, finish the true mount later. Stated here so it is a deliberate choice, not drift.

6. Phase-A invariants (non-negotiable, carried through every phase)

• Hub Overview / Trips / Presence are read + route only.
• Approve-with-dignity_ok, watchlist escalation, reject, thank-you send stay in

their own surface behind the login (gate-8 unchanged; safeguarding.md §3a).

• No channel-publisher cron; nothing posts to Facebook from the hub.
• Two buckets, one service account, fail-closed login (no secrets → locked).
• Beneficiary + donor data never leaves the workspace; the combined service is

still private-by-login (the public Pages mockup stays mock-only, noindex).

7. Decisions — LOCKED (Editor, 2026-05-31)

• Build path = Option B. One app, one login, mounted sub-apps + native

read-views. Route layout per §3.

• Phase ordering = §5 order (recommended). Finance mount → Trips/Presence

read-views → Content-plan → review/care mount. Each phase ships usable; the two-bucket mount + template audit comes last.

• Content-plan data store = agent-generated, not hand-edited. Refined

2026-06-02 (walkthrough §6): the role splits into a new content-strategist agent that _plans_ (proposes/refreshes content-plan.yaml — 12-month themes + 3-month board from VN observances + the orphan-trip feed + journey milestones + facts.md — as idea slots), and the existing content-calendar that _drafts_ one Editor-confirmed slot. Splitting keeps synthesis (no vision) apart from drafting (Opus vision). The Editor promotes slots idea → planned one at a time; the hub reads the artifact and computes flags. (Decision intent unchanged from the lock; the agent split is an implementation refinement.)

• Deploy target = replace the existing services. The combined

management-hub Service replaces the standalone review + care-dashboard (and absorbs the not-yet-deployed finance-dashboard) in Phase 4. One service, one URL, one login. (Cut-over is a single switch — mitigate by verifying the full Phase-A approve flow on the new service before retiring the old ones.)

Resulting build backlog — hub shell (the Option-B mount track)

• P1 app/hub.py: login + session middleware + Overview (mock numbers) +

mount finance at /finance (serving both #donors + #finance) + finance template-link audit + finance auth-param wiring (the "~50 lines").

• P2 Trips + Presence native read-views (Dashboard Sheet + registry.sqlite);

wire Overview today-strip/tiles to real numbers. Add: the registry.post writer (§8-B) — without it Presence/AUDIENCE has no data.

• P3 content-strategist agent emits/refreshes content-plan.yaml (idea

slots; content-calendar still drafts a picked slot); build /plan + per-slot promote + computed flags + the external-photo lane; create the missing Knowledge/Brand/facts.md.

• P4 Mount review + care (template-link audit each); management-hub

Dockerfile; two-bucket gcsfuse deploy; replace the old services after the approve-flow smoke test passes.

• P5 Community surface, when Op1 is built.

The per-workflow build tracks (media on-demand decoupling, the survey/selection subsystem, email-link-back, the bank-credit trigger + SMTP auto-send, the finance lift) are catalogued in §8 with maturity flags + dependencies. Several are independent of the hub shell and can be picked up in parallel.

8. Per-workflow build backlog (reconciled with the walkthrough)

Concrete, start-ready items distilled from the Gaps lines of each flow in management-hub-workflows. The hub-shell track (P1–P5 above) builds the parent app + mounts; these tracks build the workflow gaps underneath it. Tracks A–F are largely independent of the shell except where noted, so they can run in parallel.

Maturity legend (from the walkthrough): 🟢 deployed-live · 🟡 deployed · 🟠 built-not-deployed · 🔵 new read-view (unbuilt) · 🟣 new surface + new data (unbuilt) · ⚪ placeholder.

Phase-A holds across all of §8: the only auto-send is the donor transactional thank-you+receipt (scoped relaxation; never a post/newsletter/appreciation); nothing posts without /approve; gate-8 dignity is a human action; no channel-publisher cron.

A. Media — on-demand drafting reshape 🔵🟣 (walkthrough §1/§2)

Today the daily 09:00 pipeline Job auto-drafts every bundle with photos. Target: the daily Job stops at sanitise; drafting is on-demand.

• A1. Narrow the daily pipeline Job to ingest + sanitise only (stop the

automatic cull→retouch→caption chain). 🔵

• A2. Add the "Yêu cầu viết bài" trigger (per-activity, and later per

planned content-plan slot) that runs cull→retouch→caption on demand. 🔵

• A3. Feed caption_draft two new inputs: a direction box (free prose

steer) + an optional user-selected photo set (overrides auto-cull). 🔵

• A4. Email-link-back (shared with D): event-folder Service (or

onFormSubmit.gs, which already holds the submitter email) emails the new folder link to the submitter so they know where to upload. 🟣

• A5. On approval, write the approved final to 10_Cau-chuyen/<slug>/

(reuse the existing story archive; no 09_ band). 🟣

• A6. Human-gated self-improve: a periodic summary of the admin's caption

edits sent for review before anything is applied to prompts/few-shot.yaml (distinct from auto-optimize's own cadence). 🟣

• Depends on: nothing in the shell (pipeline-side). Pairs with B (the post-row

writer fires on the same approval/posted_id hook).

B. The registry.post writer — #1 gap 🟣 (walkthrough §7/§10; = P2 add)

• B1. INSERT INTO post on posted_id recording (hooked from

decisions_core, alongside the 10_Cau-chuyen/ archive write). 🟣

• B2. Add the tag columns `activity_type · petal · program · school ·

journey_id · theme · observance; validate petal_anchor against the 8 canonical petals (also fixes the free-text petal_anchor in brief.yaml`). 🟣

• B3. Three read-only features fall out once rows exist: "related stories" at

draft time, plan suggestions for under-covered petals/activities, and the reminders/follow-up countdown on the Overview.

• Unblocks: Presence read-view, content-plan intelligence flags. **Highest

value; do early.**

C. Content plan 🟣 (walkthrough §6; = P3)

• C1. Create Knowledge/Brand/facts.md (the agent's fact base — **missing

prerequisite**). 🟣

• C2. New content-strategist agent: propose/refresh content-plan.yaml

(directions block + roadmap_12mo + board_3mo slots as status: idea), monthly anchor + weekly flag refresh. 🟣

• C3. /plan route + reader + per-slot promote (idea → planned) + the

computed flags (orphan trips, petal gaps, 80/20 drift, observance countdown). 🟣

• C4. External-photo lane for Stream-B/reuse: an "Đính kèm ảnh" action that

drops files into source/, mandatorily runs media_sanitise (gate 2) + writes a provenance sidecar (origin · supplied_by · license_basis · attribution_required); claim-checker already blocks un-sourced third-party media. 🟣

• Depends on: B (most flags read zero without post rows) and the P2 trip/presence

read-views.

D. Khảo sát — survey & selection subsystem 🟣 (walkthrough §1b)

Entirely unbuilt; the mockup #survey panel exists but nothing backs it.

• D1. Phiếu khảo sát Form (candidate/family survey, distinct from the §1

activity brief-Form) + onSurveySubmit.gs. 🟣

• D2. New restricted Drive band 11_Khao-sat/ + its tighter permissions

(decided 2026-06-02: a new band, kept separate from the beneficiary store until admission). 🟣

• D3. survey-folder Service (the §1 event-folder pattern re-pointed at

11_Khao-sat/): make <date>__ung-vien-<NNNN>/{anh}, write phieu-khao-sat.yaml, append a candidate register row state=cho-xet-chon. Slug is a non-identifying case id (ung-vien-NNNN), reserved alongside journey-NNNN so the two never collide. 🟣

• D4. Survey watch/sanitise Job (EXIF/GPS fail-closed; internal-only,

never enters the media pipeline) → Hub/register upsert. 🟣

• D5. Admission → Care handoff: the "admit" button mints a new

journey-NNNN, creates 10_Ho-so-thu-huong/Ho-so/journey-NNNN/, seeds the profile from phieu-khao-sat.yaml (a beneficiary_promote-style first Block-3 note), stamps the candidate register state=da-chon with the journey-id link. No candidate→care promote exists today. 🟣

• D6. Email-link-back (shared with A4). 🟣
• Depends on: the care store (live). Feeds the Quản lý học sinh ledger + the

Overview "khảo sát chờ xét chọn" chip. Internal-only — does not feed media.

E. Donor + Finance 🟠 (walkthrough §4/§5; donor-and-finance-subplan.md)

• E1. Bank-credit trigger. Today = manual NCB CSV import. **Candidate under

review (2026-06-02, not decided): SePay Open-Banking webhook — a contribution_webhook endpoint verifies HMAC-SHA256**, adapts the payload to the shape contribution_import_statement already emits, then runs donor_match → contribution_promote (idempotent on bank_txn_ref; SePay id = dedup key). Confirm: Foundation owns the SePay account + bank link (third-party processor → external legal/data handling), NCB supported, webhook pricing. 🔓

• E2. SMTP send path for the scoped transactional thank-you+receipt auto-send

(receipts only; arms the relaxation in autonomy-phase.md). Currently inert — nothing auto-sends without it. 🔓

• E3. Newsletter + appreciation send (human-approved; recipient lists are

opt-in metadata only today). 🟠

• E4. Finance lift/deploy: finance_dashboard.create_finance_app needs **auth

params** (the literal "~50 lines"); management-hub Dockerfile + the two-bucket mount (= P4); so-tai-chinh.sqlite provisioned. 🟠

• **E5. Initial financial-position input + a general financial-statement

extractor** (today extract = NCB-CSV only). 🟣

• E6. Drive band 08_Quan-he-nha-tai-tro/ provisioning + code-path alignment

(donor/finance tool code still emits the pre-decision 02_… string — a tracked follow-up). Receipt PDFs need weasyprint + GTK; receipt issuer block (reg number + signature image) still placeholder. F-zero/D-zero hand pilots before scale. 🟠

• Depends on: E4 overlaps P1/P4 (the finance mount). E1/E2 are independent.

F. Cross-cutting hygiene

• F1. Care path-literal drift — tools/literals vs the live care band; align

on 10_Ho-so-thu-huong/ and retire stale 01_ references. (naming-convention.md.)

• F2. build_drive_tree.py does not yet create 08_Quan-he-nha-tai-tro/

(parked) or 10_Ho-so-thu-huong/ (trial reads the GCS bucket mirror); add to TREE when the finance lift ships / Care moves to the Shared Drive.

• F3. report_child/cohort/school.py are CLI-only, wired into no Job (the

care /reports page only lists pre-generated markdown) — wire to a Job if on-demand report generation is wanted from the hub.

• F4. video_edit is orphaned from the daily photo-only chain (invoked

separately) — fold into the on-demand path (A2) if videos should draft too.

Suggested start order

• B (post-row writer) — unblocks the most downstream value, pure

registry.sqlite work, no shell dependency.

• A (media on-demand reshape) — pipeline-side, high day-to-day impact, pairs

with B on the same approval hook; includes the shared email-link-back.

• Hub shell P1 (parent + login + finance mount) in parallel — unlocks the

single login and the finance panels.

• D (survey subsystem) — self-contained field workflow; the Foundation can

start using candidate intake independently of the rest.

• E1/E2 (bank-credit trigger + SMTP) once the Foundation confirms SePay (or

an alternative) and the bank/account decision.

• C (content plan) after B (its flags need post rows) and P2.