LIVE UPDATE — automatic posting enabled September 17, 2026

This section supersedes the earlier rollout/checkpoint notes below.

@shymkent_plans (Kazakh) and @astana_plans (Russian) are now connected to @citysitter_bot, enabled, and set to reviewRequired=false. Global sending is allowed (kill=0) and automatic collection remains enabled. No individual event approval or native-review checkbox is required. Other new channels remain disabled; the original Almaty app was not changed.

The existing three scheduled workers collect, translate, and publish. Daily digest time remains 10:00 Asia/Almaty. Automatic event digests select up to five unposted, current events in the next 14 days; empty or invalid candidates are skipped. Translation prioritizes active automatic channels within the unchanged 12-attempt daily cap. Missing dates/times/venues, expired/cancelled events, unresolved duplicates, stale source facts, invalid translations and rejected records never auto-publish. Unknown price/language are labelled unknown, not invented. The automatic path does not forge human approvals: stored review may remain draft, with validation performed at delivery.

The owner explicitly requested automatic posting in this conversation. enable_automatic_channels.ts performed the one-time activation and launched the first real digests through the durable publication queue: Shymkent message 3 (three events), Astana message 3 (one event). This was an explicit initial run, not an observed future scheduled send. The registered publisher cron remains active at */15 * * * * UTC and only queues during each channel's daily window. Repeated runs do not duplicate the launch.

Source basis: Sxodim's published terms were rechecked at https://sxodim.com/polzovatelskoe-soglashenie . The source status attributed_noncommercial records its credited, non-monetized reuse permission, not a commercial licence or fabricated owner approval. Every event links back to the source; no copied articles/photos, advertisements or affiliate links were introduced. Obtain a suitable basis before monetizing this source's content.

Verification: 37 new automatic-posting checks passed. The prior 35-check delivery/security suite passed separately; the first five suites also passed in the combined run, which then encountered a database HTTP 429. This is runtime test evidence, not GitHub CI or static type-check evidence. Pre-change rollback point is main version 56; automatic code merged at version 57. The pre-activation feed settings are saved in rollback:auto-events:2026-09-17. Rollback requires stopping these sends first; never erase delivery history or alter the original Almaty system.


Telegram City Network

Current deployment — September 17, 2026

The shared multi-city collector, translations, channel routing, owner controls and gated publisher are deployed in this Val Town app. This is not a launched network of new Telegram channels.

Log in with the owning omriluz Val Town account. /admin now opens the whole network. The old event review screens remain available through /admin?tab=review&city=.... Anonymous admin requests are denied. The val's code is public on the current account; editorial records, jobs and draft controls are owner-only. A complete human browser OAuth login was not exercised during this implementation.

What is automatic now

Five city event collectors: Almaty, Shymkent, Astana, Karaganda and Aktobe. One public employer job collector routes vacancies into the matching city. Ten default feed configurations exist: Events and Jobs for each city. These are configurations, not newly created Telegram channels.

Additional Nightlife, Free, Family and Classes feeds can be created in the control panel. They filter the same event records instead of scraping the same source again. Jobs use separate records and moderation. Unreleased cities and jobs remain off the public website.

network:collection=1 and six collectors are enabled for private collection. The global sending kill switch remains ON; all new feed publishing flags remain OFF. The external Almaty Events feed cannot publish from this app, even with different settings. The original omriluz/almaty-expats-events system was not modified.

Initial live validation at 09:27 UTC found:

CityCurrent event occurrencesCurrent jobs
Shymkent90
Almaty22
Astana20
Karaganda30
Aktobe20

This is bounded initial ingestion, not comprehensive city coverage. Performances on different dates are distinct occurrences. An older ambiguous Shymkent record remains held separately. Jobs currently cover only AccorHotel's public feed; the two observed vacancies were in Almaty. Zero elsewhere means no matching vacancy observed, not that no jobs exist there.

Sources and permitted scope

Sxodim event listing/detail pages were fetched successfully for all five cities. Its user agreement permits attributed non-commercial reuse: https://sxodim.com/polzovatelskoe-soglashenie . This rollout is a private, unmonetized metadata-validation stage with source links. Public/commercial reuse is NOT automatically approved. Runtime access continues to honor robots.txt, bounded requests, caching and access failures. Public event reuse decisions remain in the old Sources review screen.

Jobs use the documented SmartRecruiters Posting API for public AccorHotel listings, filtered to Kazakhstan. Only title, employer, city/location, posting URL, release date and employment type are stored as normalized job metadata. Salary remains unknown unless explicitly supported. No applicant contacts or resumes are collected. Public API accessibility is not treated as a commercial redistribution licence; public job reuse remains pending an owner-recorded basis.

Official API reference: https://developers.smartrecruiters.com/docs/posting-api-overview . The existing Food & Package Fair organizer draft remains available but is not part of the newly enabled recurring collectors. Ticketon access gates are not bypassed. No competitor Telegram or Instagram scraping was added.

Architecture

  • core.ts, sources.ts, store.ts, engine.ts: city metadata, event parsing/provenance, conservative occurrence deduplication, existing event review and translation.
  • network_store.ts: migration 2, collectors, feed definitions, separate job records, destination reservations and durable delivery records.
  • network_collect.ts: bounded collection batches, per-source due times, live employer API parsing, job updates and failure isolation.
  • network_content.ts: city/type routing, private/public-ready previews, job translation and round-robin translation across cities and content types.
  • network_delivery.ts: verified channel permissions, protected Almaty destination, separate private-test keys, atomic claims, bounded retries and uncertain-delivery reconciliation.
  • network_admin.ts, network_controls.ts, web.ts, ui.ts: authenticated English-language control panel, working collection switches, feed creation/settings, job review, previews and activation.

The new scheduled publisher replaces the old Shymkent-only scheduled entrypoint in this app. Legacy public activation directs the owner to City Network. It does not affect the original Almaty app. Content, source and feed approvals remain separate.

Schedules, caps and cost assumptions

Cron expressions are UTC; feed times use each city's IANA timezone. The three registered triggers are:

TriggerCronBehavior
ingest.interval.ts*/15 * * * *Up to two due collectors per tick; each targets roughly hourly collection, with batching or failures able to defer it
translate.interval.ts5,20,35,50 * * * *At most one pending event/job translation per tick, rotating cities and content types
publish.interval.ts*/15 * * * *Checks configured publishing windows and durable queue; kill switch currently blocks sending

Default feed publishing time is 10:00 local. Event feeds use a Friday weekend window instead of an ordinary daily window. Empty or unapproved feeds skip, and expired queue items do not catch up in a burst. Up to five items fit in a bounded message; up to five queued deliveries are attempted in one publisher tick.

The existing cap remains 12 attempted translations per UTC day across the new app, with failed attempts counting. No subscription or billing-limit change was made. At the 09:27 checkpoint, measured production usage was 3 requests / 549 tokens, including the earlier prototype request. Both a Russian-to-Kazakh event title and an English job-provider path were verified. Original-language fallback appears only in clearly marked private drafts, never in public-ready output.

Three quarter-hour triggers mean 288 scheduled invocations per day before HTTP/manual traffic. Current official limits allow 15-minute cron intervals and ten cron files per free val; this app has three. Account-wide traffic, database and AI allowances remain separate: https://www.val.town/limits . No monthly dollar forecast is inferred from a few sample requests.

Verification and outstanding setup

The six runtime suites passed: core 55, existing integration 36, existing HTTP/security 48, original destination safeguards 11, network collection/routing 27, and network content/delivery/HTTP 35 — 212 total. On the final combined run, the first five suites passed and the final suite hit a database HTTP 429; rerunning that suite separately passed all 35 checks. Fixtures use disposable namespaces and mocked external transports; no production Telegram send is made by those tests. All six live collectors also succeeded when invoked for deployment validation.

An actual unattended collection tick was observed at 09:30:04–09:30:12 UTC on September 17. Its log reported zero due collectors because the manually validated sources were still within their hourly delay; it did not re-fetch them. The scheduled publisher also ran at 09:30 and remained paused with zero sends. This verifies registered automatic execution without presenting manual source fetches as unattended fetches. The original Almaty app was rechecked: main version 19, last code change September 13, and its original hourly cron remains active at 0 * * * *.

Use network_status.ts for current safe counts and credential-presence checks. It does not print secrets. prepare_network.ts is an owner-invoked initial private-collection rollout step, not a cron or public endpoint. AGENTS.md documents safe continuation.

The new app has no CITY_TELEGRAM_BOT_TOKEN or CITY_TEST_CHAT_ID binding at the verified checkpoint. No real private Telegram delivery or new public post has been performed. To launch a new channel, create its Telegram destination, grant the intended bot Post Messages rights, bind the bot securely in this val, review the content/source basis, save the feed destination, perform the explicit private test, and activate that feed. The global sending switch is independent. None of these steps is needed to keep the already-enabled private collection running.

The requested private GitHub repository remained inaccessible through the connected tools. Source is preserved in Val Town, but GitHub commits, CI, lint/format/type-check gates and automatic GitHub deployment are NOT completed. Runtime assertion tests are not a substitute claim for those gates. No GitHub commit SHA is reported.

Rollback

The pre-network rollback point is Val Town main version 43. The feature branch network-automation-20260917 merged into main version 44; subsequent history contains deployment diagnostics and documentation. Before rollback, stop new-app collection and sends, restore this val's code from history, then inspect its schedules separately. Database migrations, collected records, review decisions, credentials and delivery history are not reverted by code rollback. Do not delete delivery history or target the original Almaty val.

Final verification addendum

The translation cron also ran unattended at 09:35:04 UTC on September 17 and completed an Astana event translation (network_translation_tick, ready). Anonymous access to /admin/network was verified to return HTTP 401. The interrupted rate-limited test left one isolated fixture namespace; its exact 23 test tables were removed after the successful rerun, and a read-back confirmed zero leftover test tables. Production source and publication tables were not removed. Event source changes now also invalidate pending new-feed deliveries and flag already-sent ones through their delivery-history reason; changed job details use the same alert path.