p24-infra Docs

pinbox24-w4-active-offices-analysis

6 min read

Pinbox24 W4 — Active Offices Analysis (retention-policy source of truth)

Data analizy: 2026-08-08 (dokument), dane bazowe z 2026-07-01 Autor: Claude Code (sesja p24-infra, dev-coder) Status: BEST-EFFORT — zbudowany z istniejącego dokumentu, NIE z nowego live query (patrz §4 Ograniczenia) Powiązane: docs/pinbox24-w3-migration-analysis.md §2 (W3 odpowiednik, źródło prawdy wskazane w #2710), docs/pinbox24/system-analysis.md §2 (dane źródłowe tego dokumentu), issue #2710 (retention policy, decyzja 2026-08-07), issue #2709 (Wasabi replication repair).

0. Dlaczego ten dokument istnieje

Issue #2710’s finalized retention policy (2026-08-07) names docs/pinbox24-w3-migration-analysis.md §2 as the W3 active-offices source of truth and states “W4 does not have an equivalent formal list yet.” That statement is only partly accurate: docs/pinbox24/system-analysis.md §2 (created 2026-07-01, five weeks before the policy decision) already contains a W4 active-clients breakdown computed from the same source field (w4_db.regRecords.createdAt) — just not in the same table shape as the W3 doc, and not cross-referenced from #2710. This document reformats that existing data into the W3 doc’s format so it can be compared apples-to-apples, and explicitly flags where it falls short of a fresh query against the policy’s exact criteria.

1. Aktualnie aktywne biura w4_db (reformatted from system-analysis.md §2, computed 2026-07-01)

1.1 Aktywność na podstawie regRecords (18-miesięczne okno styczeń 2025 – czerwiec 2026)

Metodologia różni się od W3 doc: W3’s table sums exactly 2 calendar years of regRecords. The only underlying data available for W4 is an 18-month monthly pivot (01/25–06/26) in system-analysis.md §2. The totals below are the row-sums of that pivot — an 18-month total, not a 24-month total — flagged explicitly per office. Given W4’s v42-prod container itself is only ~3 months old and Eco-Trans’s May/Jul 2025 bulk-import spikes dominate the total, a live 24-month query would very likely change these numbers materially, especially the ranking below the top 2.

BiuroofficeIdregRecords (18 mies., proxy dla “2 lata”)Trend / status z system-analysis.md
Eco-Trans5c752bbca20da35ca1b99083301,390Aktywny — własny klient (operator); zawiera 2 anomalie bulk-import (maj’25: 157,156; lip’25: 23,843)
Keller5d36ccf9903f5002cca1e47413,605Aktywny, stabilny 18 mies. (~750 rek./mies.)
ZPK5ebb7e06cc4fa94598071c7c6,326Aktywny, stabilny 18 mies. (~370 rek./mies.)
MOW Malbork5d40241715ec4a5764c2f9143,525Aktywny, stabilny 18 mies. (~195 rek./mies.)
Bibus Menos5d3ad60615ec4a5764c2d6312,208Spadek — ~150/mies. → 37/mies. od kwietnia 2026 (nadal ma rekordy w 2026, więc NIE spełnia kryterium “brak regRecords w 2026”)
Zhonghua5d400a2415ec4a5764c2f321969Prawdopodobny churn — ostatni rekord marzec 2026 (34); brak kwiecień–czerwiec 2026
Valmont5e2afb12ee340301e3453833663Odchodzi — spadek do 8/mies. czerwiec 2026, ale nadal ma rekordy w każdym miesiącu 2026

Inne biura widoczne w danych (2026-07-01), NIE liczone jako aktywne klienci:

BiuroOkres aktywnościOcena
orgFlow24.comsty–mar 2025 (413 rek. szczyt)Pilot, nie przeszedł do regularnego użycia; brak od kwi’25
Lib2 / Library Mgmt Systemgrudzień 2025 (383 + 24 rek.)Pilot jednorazowy
dfdfdfdfdfgrudzień 2025 (83,346 rek.)Load/stress test środowiska — nie prawdziwy klient
~36 biur o losowych nazwach (gjfjcvdf, utfbtyfd itp.)1–2 miesiące, 2025–2026Konta testowe onboardingu/demo

1.2 Wniosek (analogicznie do W3 §2.3)

  • Aktywnie rejestrujące dane w ciągu ostatnich 18 miesięcy: 7 biur (vs. 4 dla W3).
  • Dominujący klient: Eco-Trans — ale to wewnętrzne biuro operatora (excluded, always, per #2710’s finalized policy — nigdy nie ruszane niezależnie od żadnego sygnału).
  • Spośród pozostałych 6 realnych klientów zewnętrznych, 3 wykazują aktywny spadek (Bibus Menos, Zhonghua, Valmont) — kandydaci do bliższej obserwacji, ale (patrz §1.1) część z nich nadal technicznie spełnia “ma regRecords w 2026” nawet przy silnym spadku wolumenu.
  • Nie znaleziono w tym repo łącznej liczby biur w w4_db.offices (odpowiednik W3’s “882 total offices”) — patrz §4 Ograniczenia. #2710’s own Top-20-by-file-count comment (2026-07-05) found 34 unique offices in that partial file-count scan, which is a lower bound, not the true total (a query by regRecords presence, not files presence, would very likely surface more historical/ dormant offices with zero files but some old records — same pattern as W3’s 878 dormant offices).

2. Kryterium logowania (drugi warunek AND-logiki #2710)

Confirmed field: w4_db.pinbox.profiles.lastLoginTime (per docs/playbooks/pinbox24-w4-user-office-workspace-provisioning.md — “safe to read for diagnostics” list, pinbox.profiles is a literal-dot collection name inside w4_db, not a separate database). This field exists and is documented as safe to read, but no live query was run against it in this pass (see §4) — so no per-office “last login” data is included in §1’s table. The policy’s second AND-condition (“no login in trailing 12 months”) is therefore not yet evaluable from this document alone; it needs a fresh pinbox.profiles.lastLoginTime aggregation grouped by office, joined against §1.1’s office list.

Gap found: no equivalent field was located anywhere in this repo’s docs for W3 login tracking (w3_db has no documented lastLoginTime-equivalent). If the retention policy’s login criterion is meant to apply symmetrically to W3 offices too, that field needs to be identified first — flagging as an open item, not resolved here.

3. Cross-reference with #2710’s original Top-20-by-file-count (2026-07-05)

#2710’s own first comment ranked offices by file count, not regRecords — a different axis that surfaces some offices absent from §1.1 above (e.g. zintegrowana, zawarci, cargo24, nexcon, transportland, atrax, akwintal, fleetmaster, toplogistic, and 10 more, none of which appear in the regRecords-based §1.1 list). This is expected — high file count and high regRecords recency are different signals (an office could have uploaded many files years ago and gone fully dormant since, which is exactly the profile the retention policy is trying to catch). A.Kwintal (akwintal, marked “active/billable” in that comment) does not appear in §1.1’s regRecords-based active list — worth reconciling before the retention script ships, since one source says “billable/active” and the other (more recent, regRecords-based, which is what the finalized policy actually keys off) does not show it in the top 7. Not resolved here — flagging for the live-query follow-up.

4. Ograniczenia tego dokumentu (READ BEFORE USING FOR THE RETENTION SCRIPT)

This document was produced by a dev-coder-role session with no SSH access to bms-1/bms-2/bms-3/ bms-4 and no SOPS decrypt access (both are outside this role’s boundary — see CLAUDE.md §Role Enforcement). It could not:

  1. Run a fresh w4_db.regRecords query for the exact policy window (calendar year 2026 to date, not the 18-month proxy used above).
  2. Query w4_db.offices for a true total office count (W3’s “882 total” equivalent).
  3. Query w4_db.pinbox.profiles.lastLoginTime for the second AND-condition at all.
  4. Confirm or refresh any of the above against live data — everything in §1–§3 is reformatted from a document that was already 5+ weeks old relative to the 2026-08-07 policy decision.

Recommendation: before the soft-delete script is designed/built, dispatch a sys-admin (SSH

  • read-only w4_app/w3_app Mongo users, per docs/w3-w4-stack-operations.md) or a request through the already-deployed pinbox-mongo-proxy service (docs/pinbox-mongo-proxy-operations.md — POST /records against w4_db.regRecords, requires the PINBOX_PROXY_SHARED_SECRET from secret-manager, W4-only, no W3 equivalent exists) to run:
// w4_db — offices active per the exact policy window
db.regRecords.aggregate([
  { $match: { createdAt: { $gte: ISODate("2026-01-01T00:00:00Z") } } },
  { $group: { _id: "$officeId", count2026: { $sum: 1 } } }
])
// + db.offices.countDocuments() for the true W4 total
// + db.pinbox.profiles.aggregate([{$group:{_id:"$officeId", lastLogin:{$max:"$lastLoginTime"}}}])

and the w3_db equivalent (via SSH — pinbox-mongo-proxy is W4-only) once a W3 login-tracking field is identified (§2 gap).

Graph View