Archived case · VK parser and content pipeline

WTG

WTG is a VK parser and content pipeline. It collects posts and related material through VK API and Playwright, stores raw evidence, queues OCR and classification and presents the result for operator review, labeling and publication decisions. The case records the interface, architecture, code map and measurements.

Documentation →Source code ↗

Development and evidence period: June–July 2026. The archived case was prepared on 8 September 2026.Version 2184148730 interface screenshots

Collection and processing schedules

01 / The task

Publication collection, OCR and classification. Archive

The task was to combine VK content collection, image and text processing and operator review in one observable flow. Every stage had to leave a verifiable result and support retries without losing the original evidence.

Use case: Collecting publications and manually reviewing processed results.

Work done

Collection, queues, processing and the operator review screen.
Admin interface, data models and code map.

02 / Implementation

What sets the implementation apart

Raw evidence is stored separately from derived data. Queues separate collection, OCR, classification and editorial decisions; the operator sees the source and intermediate results before publishing. The code map connects screens and APIs to modules, tables and checks so a change can be traced end to end.

Screenshots

Screens, forms, errors

Screenshots, diagrams and source evidence retain their original language; captions and descriptions are translated.

03 / Technology

Stack

Shares use Git application-file bytes at pinned revisions. Each file belongs to one subsystem under scripts/generate-stack-share.mjs rules; tests, assets, dependencies and generated files are excluded. Rounded to 0.1%. This describes code composition, not proficiency.

Python / FastAPI / Jinja

Operations admin interface, JSON API and orchestration.

PostgreSQL / SQLAlchemy / Alembic

Publications, jobs, decision versions, materials and migrations.

PaddleOCR

Separate OCR sidecar and worker.

Docker / Nginx / systemd

Former deployment of seven services and background jobs.

04 / Decisions

How the project works

Collection and long-running processing are separate jobs with leases and heartbeats.
OCR is separate from the web service, with its own queue, statuses and attempts.
Source publications, intermediate decisions and final materials have different roles.
The public archive contains anonymized images, documentation and aggregate measurements without user identifiers.

05 / Verification

What has been preserved

Browse anonymized schedules, groups, pipeline and materials.
Match a screen to its code-map entry and data diagram.
Open queue/history aggregates and read the measurement date and limitations.

Check results

30 meaningful screenshots of the actual interface retained.
Each screenshot includes its date, scenario and code revision.
527,718 publications and 29,092 OCR jobs recorded; these are different entities, not quality metrics.

Limitations

The archived case has no live demo link; anonymized screens, diagrams and aggregate measurements document its behavior.
Job statuses and confidence values are not measurements of OCR or model accuracy.
Legacy noVNC and unavailable sections are not presented as working features.
Observed web-process memory growth is reported as a measurement; its code-level root cause was not established.

Technical notes

Modules, API, data model, setup and check results.

Documentation →Materials ↓