Discovery index
Document TypeMirror Output
SourceAllianceCorp Confluence · PM Space
OwnerAdrian Bortignon
Generated2026-05-21

AllianceCorp Confluence Mirror.

A local snapshot of the Digital Transformation Confluence space — 43 nodes, 11 process whiteboards, every page body cleaned and frontmatter-tagged. Built so downstream agents can read it offline while we design the HubSpot solution.

01At a glance

43 nodes. 11 whiteboards. Zero failed fetches.

A single re-runnable Python build script reads cached API responses from _raw/ and assembles the mirror. Whiteboards captured via browser automation in a second pass.

The mirror covers the entire PM (Digital Transformation) space rooted at page 327789. Every page returned by getConfluencePageDescendants is represented — full markdown for the 16 actual pages, stub files for the 25 nodes the API can't serialise (whiteboards, embeds, databases), and PDF exports for all 11 whiteboard process maps.

43
Total nodes
incl. root page
16
Pages with full content
1 via ADF fallback
11
Whiteboards exported
~45 MB of PDFs
25
Stub files
11 wb · 8 embed · 6 db
3
Drafts skipped
empty titles
0
Failures

Repo location: /Users/adrianbortignon/Documents/GitHub/AllianceCorp/. The mirror itself sits at the repo root; cached API responses are in _raw/ (gitignore-eligible once this becomes a tracked repo).

02Structure on disk

Twelve section folders. One file per node.

Folder naming is {NN}-{kebab-section-title} derived from the Confluence page titles. File naming is {page-id}-{kebab-title}.md (or .stub.md, or .pdf for whiteboards).

Each markdown file starts with YAML frontmatter (id, title, parent_id, type, status, space, web_url, last_updated, last_synced) and is followed by the cleaned markdown body and any footer/inline comments rendered with date + author + anchor.

alliancecorp-confluence-mirror/
├── README.md                                  index + hierarchy + counts
├── WHITEBOARDS-MANUAL-EXPORT-NEEDED.md        capture log + recipe
├── build_mirror.py                            re-runnable builder
├── update_whiteboard_stubs.py                 stub-annotator
├── _raw/                                      cached API responses · 47 JSON files
├── 00-homepage/
│   └── 327789-welcome-to-your-digital-transformation-space.md
├── 01-marketing/
│   ├── 524289-1-marketing.md
│   ├── 10289166-marketing-process.pdf       2.2 MB
│   ├── 10289166-marketing-process.stub.md
│   ├── 28770305-leads-fields-this-is-a-common-page-for-pecs-and-dcs.stub.md
│   └── 63078401–63111175  ·  5× untitled-database stubs
├── 02-telesales-pecs/
│   ├── 8454239-2-telesales-pecs.md
│   ├── 8880130-leads-fields-(common page).md
│   ├── 73564161-aircall.md
│   ├── 10878979-telesales-pecs-process.pdf   3.6 MB
│   └── stubs · 1 whiteboard, 1 database
├── 03-discovery/
│   ├── 10125313-3-discovery.md
│   ├── 10584065-discovery-process.pdf        4.5 MB
│   └── stubs · 1 whiteboard, 1 embed  (+ 2 drafts skipped)
├── 04-pwp/                       15663105 + 23756801 + PWP Process PDF (6.2 MB)
├── 05-finalliance/               11534384 + FinAlliance Process PDF (3.9 MB) + embed stub
├── 06-acquisitions/              15138864 + 53739521 + Acquisitions Process PDF (5.7 MB)
├── 07-accounts/                  11468848 + Accounts Process PDF (3.6 MB) + embed stub
├── 08-pp-contract/               11534337 + PP Contract Process PDF (4.5 MB)
├── 09-settlement/                14712833 + Settlement Process PDF (4.5 MB) + embed stub
├── 10-membership/                11468895 + Membership Mgmt Process PDF (4.5 MB)
└── 11-broker-channel/            15138817 + Broker Process PDF (2.0 MB)

The full per-section index, with every node ID and clickable file link, lives in README.md at the mirror root.

03Whiteboards

The eleven process maps, recreated inline.

Each whiteboard below is a hand-rebuilt SVG approximation of the Confluence original — accurate enough for downstream agents to reason about the process flow without opening the PDFs. The high-fidelity capture lives in the section folder alongside the section's markdown page.

01 · Marketing
Marketing Process
Marketing START Online forms submission / WOMs / Telephone Lead Allocation STOP
02 · Telesales / PECs
Telesales / PECs Process
Telesales/PECS START Step 1: Lead Allocation Step 2: Perform Booking Call Step 3: Book Discovery Meeting STOP May (global resource) assigns database leads. Josh manually assigns majority of leads. In the following order: 1. Perform Booking Call 2. Book Discovery Session with DC 3. Perform Confirmation Call PECS follow rules: Reminder Call 3 days before session. Call 8 times before marking max calls. PECS organise discovery meeting using Google Calendar. Sends email via Salesforce template.
03 · Discovery
Discovery Process
Discovery START Step 1A: Allocation List - Allocating Wealth Planner before sitting with DC Step 1B: Discovery Session Sat Step 2: Registration Process Step 3: Finance Assessed Step 4: Strategy Session Completed (held by Wealth Planner) Step 1A: Peter does WP allocation manually on SF report by triangulating lead profile and allocation Spreadsheet on google sheets. Step 1B: Customer and DC meet to discuss property investing. SF generates fact find google sheet automatically for lead, moves to opportunity. DC starts working on a lead. DC presents fact find to client via shared screen, updates fact find in live with client during session, auto-updates to the CRM. Charges $200 via Stripe link, registers client, books a strategy session. Converts lead to Opportunity. DC sends Salesforce template email to broker (incl. FORD notes + fact find link). Lead Conversion only after Stripe payment. Edge cases sit through SS. DC books appointment with SMSF (optional), Broker, WP via Calendly. Broker meeting must be completed before Strategy Session. Provides Discovery consultant and PWP with client's financials. DC inputs fields into master opp re: SMSF consultant On SMSF. Broker uses Quickli + partner community; link sits in opp. DC calls the client (tuck in call) prior to Strategy Session to confirm meeting before the session. DC confirms tuck in call has been completed in master opp when the call is made.
04 · PWP
PWP Process
PWP START Step 1: Strategy Session Held by PWP Step 2: PP Session (Property Presentation) Booking Step 3: Stock Allocation and Property Hold Process Step 4: Property Selection & Equity through to Property Presentation Converted
05 · FinAlliance
FinAlliance Process
FinAlliance START Step 1: Leads (client file) allocation by DC Step 2: Finance Session - Managing Client files in Mercury Step 3: Customer Decision Point STOP This follows existing process - DC books meeting with external and internal brokers using Calendly. Capture client info, Opp info Fact Find, Borrowing Power Conversations around Policy Terms (Optional) Outcome - Finance Option Summary pdf. Member portal centre for uploading customer docs. External Broker (~12 staff) Scenario: 1. DC assigns Finance broker, books in Calendly. 2. Broker manually inputs preliminary time and other details both on Master opp and Settle Opp. EOI is in place - If yes - Initial application straight away for new loan. Do we capture it on opp for Fin Alliance metrics. It's also a good list to target marketing for future.
06 · Acquisitions
Acquisitions Process
Acquisitions START Step 1: Stock Management - Creation Stage Step 2: Stock Management - Available and allocated Stock Stages Step 3: Stock Management - PP Allocated STOP Acquisitions & Partner Manager 'APM' (George, Mitch, Jamie). APM manages the partner (builder or land supplier). Partner onboarding - New suppliers are onboarded as opportunities arise or stock is required after strict vetting and due diligence. Property reports created once stock is acquired (floor plans, pricing, DD). Stock uploaded into Salesforce for the PWPs to allocate and sell. Status: Aquisition - APM creates stocks as acquisition; not visible for PWPs. Available - Stock becomes visible to WP for allocation. PWP Allocations - PWPs are permitted to allocate 3 properties per viable purchase for each client. Stock Volume & Upcoming PP's - APMs must monitor stock volumes daily to ensure adequate stock volumes are held. PP Allocated stage - Means PWP/multiple PWP's have reserved the stock for a Property Presentation. First in best dressed basis with allocation no.1 having priority. PWPs submit EOI within 3 hrs. EOI/Recieved Stage - Stock is removed from list once EOI requirements met. Property Allocation Conflict and Priority: When multiple planners allocate same stock (PP allocated), a list shows priority. Stock can be marked lost by Acquisitions if supplier sells externally; notification sent to all pwps to find alternative.
07 · Accounts
Accounts Process
Accounts START Step 1: Client Invoice Step 2: Builder Invoice Step 3: Staff Commission Process (Managed outside CRM) Other Processes (Managed outside CRM except Stripe) STOP Post Purchase: Contract team sets in Sales won opp and inputs to deposits section that triggers actions for Accounts team. Action for Accounts - Add details to Client fees section - Memberships, Fees and Post-Purchase Fees. Current Process - Accounts uses SF dashboard to understand builder terms and captures commission details in SF and XERO. Post-Purchase Team adds deposit section on settlement opp once sales won. Stage 2 work - Commissions Management currently in Google Sheets (manually exported monthly from SF report on settlement opportunities). Commission Overview - WP received commissions based on drop value (top gun, premium, std), payable over sales won Part A and Part B milestones. Commission claw-back when deal is dropped after commission paid to WP. Stripe fee refund is managed by Accounts. These are updated in Salesforce and reported on weekly basis.
08 · PP Contract
PP Contract Process
PP Contract START Step 1: DCC Received (This will be a stage in Hubspot) Step 2: Contracts Ordered (This will be a stage in Hubspot) Step 3: Contracts Checking Step 4: Contracts Received Step 5: Contracts Sent (This will be a stage in Hubspot) Step 6: Contracts Signed (This will be a stage in Hubspot) Step 7: Contracts Executed STOP Step 1: PWP submits a SS in contracts inbox. Step 2: Sale Coordinator enters DCC submission and contracts requested with PCC. Step 3: SCC creates contract cover sheet and pages. Step 4: SCC sends contracts cover sheet to vendor for DCC payment. Step 1: SCC will send a notification to broker and email when offer is submitted "Contracts Ordered". Step 2: If PWP, SVP and team have SCC will issue an email notice. Step 1: If accepting time frame and contracts sent to client by vendor, CC will review the contracts received on the criteria. Step 2: If any error or missing data is found, contacts the vendor for missing fixes. Step 1: SCC will issue a checklist made of: client's commission letter, DOC-PWP receives the contracts to be reviewed before sending to clients. Step 2: If errors are recorded the contract is sent back to vendor. Step 1: SCC sets cover with contractor signature and forwards to client. Step 2: DC connects with the client over the signing. Step 3: If meeting confirmed, DC will walk client thru meeting in booked slot. Step 1: PWP contracts received from client. SCC will follow-up till the contracts are returned by signing timeline. Step 2: If contracts are not returned on time, SCC will keep customer alive via FUPS until contract is back. Step 1: All contracts are checked closely if vendor has executed closely if vendor has executed contract and deposit has been received. Step 2: PP records reset if contracts not executed.
09 · Settlement
Settlement Process
PP Contract & Settlement START Step 1: Settlement Opp Management Step 2: Contracting Process Step 3: Contract is executed Step 4: Settlement file management STOP Step 1: Contracts team initiates contract process when EOI signed. Action - Creates Settlement Opp HSL or Settlement Opp OTP based on the property type. Teams involved - 3 staff incl. global support. Contracts team updates contracts tab on opp. KPI - Target stipulates 14 days, currently tracking 30-45 days. Contracts logs customer email comms in audience. Documents sent off for signature based on land supplier/building supplier. Contract section fields are updated. All email activities logged in Salesforce EOI is set in doc as sign. WP sends the signed document to contract via email inbox. Settlement opp, Google folder, Email to broker, Email to Customer. KPI - About 250 files per person. Global support team updates following tab on a settlement opp, sent monthly updates to customer, manage customer. Support team email comms with customer: Deposit/Finance · Construction · Communication Issue/Red Flag · Discussed during weekly meeting Contracts Team responsible for contract section. EOI Received · Pending Replacement · Contract Ordered · Sent · Signed. Post Purchase Team next. Sales Won · HSL Land Settled · Under Construction OTP Settlement (not used anymore) · Closed Won.
10 · Membership
Membership Management Process
Membership Management START Allocation to Membership Team (Settlement Opps Sales Won) Portfolio Exploration Process Broker meeting booking STOP 1. Travis assigns person account manually to himself/team. 2. Performs a bit of research on account and opportunity. Membership - All looks after entire Portfolio. Touchpoint KPI - Around 80 EOI per person. GONG gives AI brief. Portfolio Exploration Process. Customer is called by membership team to Explore: Goals, buy Prop, Refinance ops. Main KPI - Portfolio Review EOI (PR EOI). Broker Meeting booking. Google Sheet for finance Assessment (Soft BC). If BC is good then strategy session goes ahead and follows the process. If BC is not good, Membership will give a call to customer saying we will connect later with WP. Books Strategy session with WP. Broker meeting booking. Broker call is booked - Another master opp (PR type) is created by Membership person and assigned to broker. WP is booked by Membership. GONG summary is based on conversations. 3 ways to become member. 1. Money Aclerator 2. Buyers advocacy fee. 3. Property wealth plan membership 4. Mortgage Accelerator program 5. Roll over Program 6. Vendor Advocacy
11 · Broker Channel
Broker Process
Broker Channel START TBC TBC STOP
04How the recipe works

Three commands. One catch.

Built around the Atlassian MCP for page fetches and Claude-in-Chrome for whiteboard exports. Python composes the markdown files.

Pages and comments — Atlassian MCP

Run getConfluencePageDescendants against the root page 327789 at depth 10. That yields the 43-node manifest. For every node with type: page (and non-empty title), three calls:

  1. getConfluencePage(pageId, contentFormat: "markdown") — wraps the page in content.nodes[0]; body is a markdown string for most pages, a JSON-stringified ADF document for the auto-generated root.
  2. getConfluencePageFooterComments(pageId, includeReplies: true) — straight array; comments use top-level authorId, createdAt, and body (string, same custom-tag shape as the page bodies).
  3. getConfluencePageInlineComments(pageId, includeReplies: true) — same shape; the anchor text is in properties.inline-original-selection (use that, not the marker-ref UUID).

All responses cache to _raw/. The Python builder reads them, applies the cleanup pass below, and writes the section folders.

Cleanup transforms

Confluence's markdown export leaves a handful of custom HTML tags that downstream agents stumble on. Strip them all:

  • <custom data-type="emoji">:hospital:</custom>:hospital:
  • <custom data-type="status">MUST HAVE</custom>**MUST HAVE**
  • <custom data-type="mention">@Name</custom>@Name
  • <custom data-type="date">3/6/2026</custom>3/6/2026
  • <custom data-type="smartlink">https://…</custom> → bare URL
  • <custom data-type="placeholder">…</custom> → dropped
  • ![](blob:…)*[Image: embedded in original Confluence page]*
  • U+200C zero-width non-joiners → stripped

Whiteboards — Claude-in-Chrome

The Atlassian API doesn't expose whiteboard content as text. Confluence renders them in a same-origin iframe via WebGL. Three things have to be true for the export to fire:

  1. The page's document.hidden must be false — Chrome pauses WebGL in backgrounded tabs, and the MCP automation tab runs backgrounded by default.
  2. The iframe's document.hidden also has to be false — the spoof needs both, because the canvas lives inside.
  3. A full canvas frame has to have rendered before the Export dialog will enable. Shift+1 (zoom-to-fit) is the cleanest way to force one.

The working sequence per whiteboard:

navigate → wait 3s
cmd+R reload → wait 5s
JS: defineProperty document.hidden=false + visibilityState='visible' (parent + iframe)
JS: dispatch visibilitychange on both
wait 15s for WebGL to draw

click in canvas → focus
press Shift+1 → zoom-to-fit (forces full render)
wait 3s

open More-actions → click Export menu item
wait 3s for dialog to populate
if "Export area" defaulted to "Selected area", change to "Entire board"
click blue Export button
wait 10–30s for "Exporting…" → file in ~/Downloads
mv to {section-folder}/{id}-{kebab-slug}.pdf

That recipe captured all 11 boards. Two of them (PP Contract, Membership) needed a second pass — the Export dialog opened with everything greyed out on the first try and required a dismiss → zoom-fit → reopen cycle before the blue button activated.

05Lessons

The false-empty trap, and why the user saved this run.

Documented here so the same pattern doesn't bite the next time a whiteboard-heavy space goes through this pipeline.
Original (wrong) finding

"9 of 11 whiteboards are empty placeholders." — I'd opened each in the MCP automation tab, waited 15+ seconds, watched the canvas remain blank, and observed that the Export dialog rendered with the submit button disabled. I read that as "Confluence is telling me there's nothing to export" and recorded it as a verified-empty result in WHITEBOARDS-MANUAL-EXPORT-NEEDED.md.

What actually fixed it

Adrian sent a screengrab of the Marketing whiteboard from his own Chrome tab — clearly full of content. That single screenshot invalidated the "empty" verdict and forced a re-test. Without it, the mirror would have shipped with the wrong story about 9 of the 11 process maps.

Three lessons worth keeping

Absence of evidence isn't evidence of absence — especially for WebGL.

The Page Visibility API is silent. Chrome doesn't warn you that it's throttling rendering. A blank canvas in an automation tab is consistent with both "empty whiteboard" and "Chrome paused WebGL because the tab is hidden." The next time I see a blank canvas in an automated browser, the default hypothesis should be rendering-paused, not content-empty.

A disabled Export button isn't a content signal — it's a render-state signal.

I assumed Confluence was telling me "there's nothing to export" when actually it was telling me "the canvas hasn't finished drawing yet, so the export pipeline isn't ready." The two states look identical from outside the React app.

Iframes carry their own visibility state.

When the parent document is spoofed visible but the iframe isn't, the WebGL inside the iframe stays paused — even though the parent looks fine. Spoof both. This is the kind of thing that's obvious once you know but easy to miss when you're moving fast through the parent document's console.

What I did right (worth keeping)

  • Retracted the wrong finding the moment the screengrab arrived. Updated every stub, the README, the whiteboards index, and the raw status notes — not just the headline. Future-me reading the mirror six months from now sees the retraction in every relevant place.
  • Kept the recipe in WHITEBOARDS-MANUAL-EXPORT-NEEDED.md, including the bits that didn't work. So the next person (or me, next time) can re-run this against a different space without rediscovering the iframe gotcha.
  • Cached the raw API responses in _raw/ before parsing them. When the page-builder script needed fixes (comment field shapes were different than I expected), I could re-run the build in seconds without re-paying the API call cost.
06What downstream agents get

A clean local snapshot. Nothing more, nothing less.

The mirror is the input for HubSpot solution-design work. It is deliberately not opinionated about that work yet.

This artefact captures what AllianceCorp has documented, not yet what AllianceCorp should build. The next pass — turning these 11 process flows + the 16 page bodies into a HubSpot foundation design — is a separate job for downstream agents reading this mirror as input.

Things they'll find useful out of the box:

  • Every page's frontmatter carries the Confluence web_url — agents can deep-link back to the source when they need to verify a field name.
  • Comments are preserved with author IDs + dates + anchor text. Useful for catching disagreements that were captured inline but might be missed by a glance at the page body.
  • The whiteboard PDFs are vector — agents that read PDFs can extract text directly, no OCR needed.
  • The SVG diagrams above are inline in this doc. Downstream agents reading this HTML can parse them programmatically to reason about the flow structure without touching the PDFs at all.