Roadmap

Chinaski grows slowly and deliberately: the same philosophy that keeps the shipped surface small applies to what gets added next. This page collects the improvements currently in planning, grouped by the pillars they serve. Everything listed here is a proposal: the “what exists today” statements are accurate descriptions of the current software, and the rest is intent, not implementation.

Forms Maturity

The forms module works (submissions, notifications, webhooks, spam protection), and four refinements are being planned to take it to production-hosting-grade:

Spam quarantine instead of silent discard. Today the honeypot and the markup/link filters keep bots from learning; they see the same “thank you” screen real people see, and the submission is never stored. The cost: a false positive (a real person who pastes URLs into a message, for instance) vanishes with no trace and no way to check the filters are calibrated well. Planned: quarantined submissions an administrator can review, release, or verify.
Delivery health on the form itself. Webhook delivery logging with retries already exists and is browsable in the webhooks admin, but form-triggered webhooks don’t record which form they belong to, so a form’s edit screen has nothing to show about its delivery health. Planned: link form-triggered deliveries back to their form so each form’s edit screen surfaces its own webhook status.
Per-language labels and messages. Form labels, placeholders, the success message, and the submit-button text are single strings today, a hard wall for multilingual sites. Scoped first step: cover the form-level strings only, reusing the existing translations machinery rather than building a parallel per-language system.
Double opt-in for newsletter-style forms. A submission counts the moment it’s stored; there’s no confirmation gate before a contact is treated as subscribed. Planned as a hygiene option for signup-style forms so lists stay clean.

SEO Discovery

Helping search engines find fresh content faster: today the sitemap and robots.txt are correct but entirely passive:

Custom robots.txt directives and sitemap index support: robots.txt is currently built from a fixed template with no way to add directives (crawl-delay and similar), and each language publishes a single sitemap file with no index file, so a language crossing the 50,000-URL sitemap ceiling has no split path.
A search-engine ping subsystem: today there is no notification mechanism at all (the build webhook pings your own systems, not search engines). Planned: Google Indexing API / Bing URL Submission support with retries and submission visibility, so you can see what was submitted and when.
IndexNow protocol support: the precursor: proactively notify participating engines which URLs changed on every build, instead of relying on organic crawl discovery. Same maturity target as the line above: retries and a visible submission record.
Full taxonomy management: categories are flat today (no parent/child nesting), and tags are a plain comma-separated text column with no synonym support (“CMS” and “Content Management System” don’t recognize each other). Planned: tag hierarchy, synonyms, and the archive pages that make taxonomy browsing useful.

Access Control

The permission model today is deliberately simple, two roles plus coarse per-user content/language restrictions, and the planned additions give growing teams more precise control:

A Manager role between admin and editor: for team leads who need to publish and invite users without full destructive access (the role set is currently exactly two).
API keys with scoped permissions: the existing API keys carry read or write; planned: finer-grained scopes so service-to-service integrations don’t need full access.
Service accounts: non-human accounts with their own permission matrix, IP allowlists, and expiration/rotation for automation that shouldn’t ride a person’s credentials.
A unified capability table: replacing “these pages only / these forms only” conventions with one capability system that supports both per-entity and global grants.
Page-level permissions: restricting a specific page or post (to an owner, or to designated roles) for multi-team sites and embargoed drafts; today restrictions exist at the entity-type and language level only.
Field-level access control: gating SEO-critical fields (canonical URL, noindex, structured data) by role, so a content edit can’t inadvertently reach settings that affect the whole site’s indexing.

What isn’t on this roadmap

The public roadmap lists what the project intends to build; it doesn’t promise dates or a release order. Shipped behaviors referenced above (webhook delivery logs, per-entity restrictions, the two-role system) are documented on their own pages; the planned work here builds on those, and links rather than repeats.

‘Roadmap’ in one sentence: the pillars above are the completion work; a forms system ready for list-based marketing, discovery assistance for search engines, and access control that scales from solo operator to many-team organizations. Nothing here ships without its “what today does” clause staying true, so check back as items land.