The Gillish ecosystem: product brief.

Executive summary#

What: a network of five focused, single-purpose WordPress plugins from one small studio. Cairnstone (a Gutenberg-native block builder with universal Conditional Content and a curated 30+ block library), Node (link management, click tracking, affiliate cloaking, auto-linking, and content-structure visualization), Feed (a free content finder), and Mesh (a competitor link-graph analyser), with Core, a unified dashboard, tying them together once a site runs more than one. Core also carries the studio's internal MCP module, the transport surface Gillish uses for its own infrastructure.

For whom: WordPress-native site owners, niche bloggers, affiliate and content sites, small studios, who want precise tools that each do one thing well, not a bloated "AI-powered all-in-one" suite.

Why a family, not five plugins: each tool is independently useful, but they were designed to compound. The same studio, the same design language, the same admin home (Core), the same engineering doctrine, and a handful of deliberate cross-tool bridges mean a site that adopts one tool has a low-friction, high-trust path to the others, and gets more from each because the others are there.

What is new in this revision: Core shipped its first feature of its own. The site-wide short-tag engine, Dynamic Tags (year, copyright lines, brand name, support email, and similar live values), was extracted out of Gillish Node into Core, so the tags now resolve across the whole site rather than only inside Node; Node keeps only the anchor-text processor that expands them inside managed-link text. This ends Core's parked-shell status: it is no longer only a dashboard. In the same arc, bot-detection signal was consolidated onto a single neutral gillish_is_bot hook owned by Core, populated by Node and read by Cairnstone, replacing the previous direct Node-to-Cairnstone pipe. Earlier in the cycle: the standalone MCP plugin was absorbed into Core as an internal-infrastructure module (2026-06-09), so the toolset reads five plugins and customer-facing AI lives in the products themselves; the ecosystem floors moved from WordPress 6.6 / PHP 8.2 to WordPress 6.9 / PHP 8.3 after five same-day floor-lift decisions on 2026-05-21; the remote auto-deploy matrix (three GitHub-Actions-driven test environments) was retired on 2026-05-23 in favour of three local Studio installations on the operator's workstation, with verification handled in-session; and the EU Cyber Resilience Act Annex I gap audit landed across Core, Cairnstone, and Node security pages (2026-05-20), with the first CycloneDX 1.5 SBOMs published in parallel.

The governing principle#

One rule governs every product decision in the ecosystem: each tool must be excellent on its own, and worth more when its siblings are installed. "Better together" is never "depends on". A tool run alone is whole; a missing sibling is simply detected as absent and the feature degrades gracefully. No tool hard-wires itself into another's internals.

The pattern is the same everywhere: each plugin probes for siblings with class_exists( '\Gillish\<Tool>\Plugin', false ), a no-autoload one-shot check, and lights up cross-tool bridges only when the probe returns true. No use Gillish\Node\… imports, no service locator, no shared runtime library: a missing sibling is simply reported inactive. Core never has to be present for siblings to work, and siblings never have to know Core exists.

This is already wired, not aspirational. The Better-together bridges section enumerates the concrete code paths.

The five tools#

Five plugins, one studio. Four tools plus the hub. Each has its own working documents, overview, product brief, foundation plan, and security & compliance page, reachable from the ecosystem nav at the top of this site.

Gillish Cairnstone#

A Gutenberg-native block builder: a curated library of 30+ ready-to-use blocks (charts, accordions, pricing tables, conversion blocks, FAQs, TOC, …), a way to build new reusable blocks from inside Gutenberg, and universal Conditional Content that gates any block on visitor signals (country, device, referral, returning visitor, custom). Cairnstone's distinctive trick is injecting two universal capability panels, Cairnstone Style and Cairnstone Visibility, into every block's existing Inspector, with a Schema panel that lights up for blocks whose manifest opts into Schema.org emission.

Current state: in active development, pre-launch, the most actively built tool in the family. The major version v3.0.0 is reserved for the wp.org launch; pre-launch development carries on in the v2.3.x line. Phases 1 through 15 are shipped and live: the inspector and Conditional Content foundation, the interaction system, the Schema panel with JSON-LD, Block Bindings with inline data tokens, block import/export, and the AI-integration arc (the cairnstone/* Abilities API plus discovery, mutation, audit, and preview behind an opt-in). The current work is Phase 16, the library upgrade pass (aligning the transplanted blocks and building the Accordion, Tabs, Modal, Carousel, Counter, and Reveal interaction blocks); third-party block verification (17) and licence plumbing (18) remain. Working documents: cairnstone docs.

Gillish Node#

Link management, click tracking, affiliate cloaking, auto-linking, and content-structure visualization. The most mature tool in the ecosystem, currently on the v2.91.x line. Node shed its Dynamic Tags engine to Core (where a site-wide content tool belongs), keeping only the anchor-text processor that expands tags inside managed-link text. Node supplies the visitor-country signal (GeoIP) to Cairnstone through a public hook surface, and populates Core's neutral gillish_is_bot signal that Cairnstone reads for bot-detection, so Cairnstone does not ship a second copy of that machinery. Pre-launch; in active development. Working documents: node docs.

Gillish Feed#

The free content finder: ingests multi-source industry signal, surfaces what is worth writing, and hands those opportunities to the rest of the ecosystem. A finder, not a creator, it never hosts AI inside the plugin. Free forever, with no Pro tier and no licensing, by deliberate exception: the free baseline is AI-free and therefore costs nothing to operate.

Current state: parked skeleton on the v0.1.x line. Sequenced behind Cairnstone and Node; the skeleton holds Feed's place in the ecosystem without committing development effort yet. Working documents: feed docs.

Gillish Mesh#

A standalone competitor link-graph analyser for niche bloggers priced out of the heavyweight SEO suites. Mesh is Node's sibling, it shares Node's design language, and with Node installed it can read Node's graph cache instead of re-crawling, so the comparison is apples-to-apples.

Current state: parked Phase 0 skeleton on the v0.1.x line. Sequenced behind Cairnstone and Node; the planned-capability map, product brief, and six-phase foundation plan are published in full on this site so the eventual build does not start from a blank page.

Gillish Core#

The unified dashboard: one common admin surface that detects every installed Gillish tool and links into each tool's own dashboard and documentation, and the home this docs network is organised around. Core owns the shared gillish top-level admin menu so siblings can hang submenus off one branded entry on a multi-tool site, not N top-level items.

Core's value appears only once a site runs two or more Gillish tools, it is the connective tissue for a multi-plugin site, not a standalone product. Siblings never depend on Core; Core never hard-couples to them; but a zero/one-plugin site has nothing for Core to surface.

Current state: on the v0.1.x line, a shipped hub that now carries its first feature of its own. The ecosystem grid works; the shared Gillish menu groups, bands, and sorts the family; the menu-naming setting works; light/dark theming works; the security & compliance page is the canonical visible surface for the ecosystem-wide CRA program; since v0.1.24 Core carries its first feature of its own, Dynamic Tags, extracted from Gillish Node (Node v2.91.30) so the tags now work across the whole site, not just inside Node, with Node keeping only the anchor-text shim that expands them inside managed-link text (short text tags that expand to live values such as the year, copyright lines, or the site's brand name and support email, off by default and configured on a new tabbed settings page); since v0.1.26 Core consolidates the neutral gillish_is_bot hook as the one ecosystem-wide surface for bot-detection signal, replacing the previous direct Node-to-Cairnstone pipe; and since v0.1.11 Core carries the studio's internal MCP module (the transport surface Gillish uses for its own infrastructure, not a customer integration). Working documents: about Core, security & compliance.

Better-together bridges (in code)#

"Better together" is already wired. The concrete bridges, all built on the class-existence probe:

• Cairnstone ← Node (visitor-country resolver). Cairnstone's Conditional Content reads visitor country through Node's resolver when Node is present, instead of shipping a second copy of the GeoIP machinery. Pivoted from Cairnstone-side GeoIP to Node delegation in Cairnstone 2.2.71.
• Core ↔ every sibling (internal ability transport). Any Gillish sibling that registers abilities through the WordPress Abilities API (Cairnstone Phase 13's cairnstone/* set today) surfaces automatically on Core's internal MCP module, one tool per ability, with no per-sibling code. The module is the studio's own infrastructure surface, not a customer product.
• Core + Node → Cairnstone (bot detection). Core owns the neutral gillish_is_bot hook (since Core v0.1.26); Node populates it; Cairnstone reads it to skip Conditional Content evaluation on bot traffic. The signal is a Core-owned ecosystem surface rather than a direct Node-to-Cairnstone pipe.
• Mesh ← Node (graph cache). When Node is installed alongside Mesh, Mesh reads Node's already-crawled link graph instead of re-crawling, so the competitor analysis works on the same data Node already has.
• Feed → ecosystem (content hand-off). Feed is scoped as the finder that hands opportunities to the rest of the ecosystem, rather than duplicating a writing tool.
• Core ↔ every sibling (the umbrella). Core's Shared\Ecosystem catalogue is the only place that knows which Gillish tools exist; siblings (or site code) can adjust their own card via the gillish_core_ecosystem_plugins filter. Each plugin keeps its own top-level WordPress admin menu by design; the only menu surface they would ever share is the gillish umbrella Core itself owns.

Who it is for#

The common customer lives in wp-admin, is price-sensitive, and wants tools that are honest about their scope. Niche bloggers, affiliate and review-site operators, content-led small businesses, and small portfolio owners who find the heavyweight SEO and page-builder suites overpriced, overbuilt, or both. The promise across the family is the same: WordPress-native, single-purpose, honest about what it does and does not do.

It is deliberately not for:

• Agencies running large multi-tenant fleets where centralised licence management is the primary buying criterion.
• Enterprise teams that already own and have standardised on the heavyweight suites.
• Anyone wanting an all-in-one that does everything adequately and nothing precisely.
• Sites that cannot meet the platform floors (PHP 8.3, WordPress 6.9) and cannot move.

Platform floors & testing matrix#

Two declared minimums, both moved aggressively forward in five same-day decisions on 2026-05-21:

The full policy, when a floor moves, what it means if you run a Gillish plugin, and why the studio holds an aggressive posture, lives on the ecosystem-wide version-support page.

Three local Studio installations cover the (PHP × WordPress) matrix; production sites are manual zip upload only and are never in any auto-deploy:

The plugin source on the operator's workstation is junction-mounted into all three local Studio sites' wp-content/plugins/ simultaneously (see distribution infrastructure), so editing the canonical source exercises every slot at once. The declared floor is therefore continuously available, not just declared.

A second, theme-context matrix sits alongside the version matrix, testing rendering rather than PHP/WordPress compatibility, and it tests in isolation: where the three sites above run every plugin active together, each theme site activates only the one plugin under test, so no cross-plugin interaction can corrupt a rendering result. The four differ by active theme:

The two matrices answer different questions: the version matrix (three sites, all plugins active) asks whether a change runs across the PHP and WordPress floor-to-bleeding range and whether the plugins coexist; the theme matrix (four sites, one plugin active) asks whether that one plugin renders correctly across theme contexts, uncontaminated by the others. Any change with a visible result, in the editor or on a rendered page, is confirmed on the dark site at minimum. Only Cairnstone is set up on the theme matrix today.

Engineering doctrine#

The studio runs a written engineering doctrine, mirrored across every plugin's CLAUDE.md and held in practice. The load-bearing rules:

• The smallest diff that meets the spec ships. No speculative features, no premature abstractions, no "while I'm here" refactors. Documented as the Karpathy four-principle inheritance (think before coding, simplicity first, surgical changes, goal-driven execution) at the user-global scope; every plugin's CLAUDE.md inherits it.
• One hook registry per plugin. Every add_action / add_filter for a plugin lives in its register_hooks() method, nowhere else. The file to read first when tracing how something is wired.
• Hand-rolled PSR-4 autoloader. No Composer at runtime. Composer is dev-only (PHPUnit, PHPStan, phpcs); the runtime payload that reaches the local Studio sites is the canonical source minus a strip list (composer.* / phpstan.* / phpcs.* / tests/ / plans/ / CLAUDE.md), never a Composer install.
• PHPStan level 9, 0 errors. The hard gate. New errors are regressions, not new debt. Compliance is verified surgically, per unit, never a tree-wide automated rewrite.
• WordPress-Extra phpcs ruleset as the bar; intentional ecosystem deviations (the PSR-4 filename convention, signature-match unused parameters, the inline-SVG icon's base64_encode) are documented in each plugin's CLAUDE.md rather than left as floating warnings.
• English-only production surface. Every visible UI string, every __() default, every aria-label and code comment is English. The studio is Norway-based but conversation-only Norwegian; mixed-language UI signals amateur.
• Light + dark mode is non-negotiable. Every admin surface ships both, paired in the same edit.
• Security boundary always on. Every entry point is current_user_can() + nonce gated; every output goes through the appropriate esc_* helper; secrets are never hard-coded, they live in wp-config.php / options.
• Documentation cites its source. Any GDPR / CRA / WCAG / "compliant" claim names the file or rule it rests on, or is marked "not assessed". A fabricated compliance claim is a legal liability; the studio writes none.

The studio's broader process, how a Gillish plugin actually gets shaped, crafted, verified, and shipped, is documented in The Method.

Distribution infrastructure#

The studio retired its remote auto-deploy matrix on 2026-05-23. The current pattern is local-first; each piece carries its weight:

• Three local Studio installations on the operator's workstation cover the floor / stable / bleeding matrix (WordPress 6.9.4 / PHP 8.3, WordPress latest stable / PHP 8.4, WordPress 7.1 / PHP 8.5). Studio is Automattic's local-WordPress app; each site runs WordPress in WebAssembly.
• Plugin source = single canonical tree on a dedicated drive on the workstation. The plugin's wp-content/plugins/ entry in every local Studio site is an NTFS junction to that one tree, so editing the canonical source is reflected in all three Studio sites instantly.
• Production-clean view via a mirror script. A robocopy mirror produces a wp.org-clean view of each plugin (strips dev-only files: CLAUDE.md, composer.json, phpcs.*, phpstan.*, phpunit.xml.dist, tests/, plans/, .claude/) at a second tree the Studio junctions actually point at. The dev tree on the workstation keeps every file; only the mirror Studio sees is stripped. Same list will drive the eventual wp.org submission ZIP.
• Verification runs in-session. Chrome MCP drives admin-surface checks against the local Studio sites; Plugin Check runs against the same mirror Studio sees, so a clean PCP pass on the floor site is the closest cheap proxy for "would survive wp.org submission review". composer audit + the wp-playground accessibility scan run as pre-push gates on the operator's machine.
• Production is manual zip upload, always. Production sites are never in any auto-deploy. A human flips production, every time, with the artefact they intend. wp.org submission is the same shape: a manual zip uploaded to the Plugin Directory.

The docs site itself, html.gillish.com, what you are reading, is updated by a local rsync over SSH to the production server, additive-only, run by the operator. The retired GitHub-Actions workflow that previously deployed this site on push was removed on 2026-05-24. The repo on GitHub now serves only as a backup; nothing on it deploys anywhere.

Version regulation: the version bump is the moment a meaningful change ships, never a release-time ceremony. A feature, a behavioural fix, a security fix, a schema change, or a floor lift each get a bump in the same commit as the change (header Version: + readme.txt Stable tag + a == Changelog == entry). Pure docs / comment / test-only edits do not. Major-version bumps are reserved: Cairnstone's v3.0.0 is held for the wp.org launch; the studio does not roll major versions speculatively.

Commercial & distribution model#

The distribution target is the wp.org plugin directory: free tiers ship there for distribution, reviews, and discovery; paid upgrades happen through each plugin's own UI to a separate channel, never as a paywall on a wp.org-listed feature. Everything is GPLv2-or-later, with no obfuscated code, no telemetry without explicit opt-in, and all bundled third-party assets GPL-compatible.

The commercial model is per tool, not ecosystem-wide:

The free-forever exception is deliberate, not an accident:

• Feed's free baseline costs nothing to operate. No AI inside the plugin means no per-user inference cost. A no-Pro plugin on wp.org draws site owners wary of "AI plugin" upsell tactics; trust is the currency for content tooling, and permanent-free is the strongest signal available.

Compliance & honesty#

Compliance is a standing posture, tracked honestly and per tool, not a badge. Each Gillish tool carries its own security & compliance page that maps GDPR, CCPA/CPRA, the EU Cyber Resilience Act, OWASP, and WCAG 2.2 AA to a real status with sources, met, partial, not applicable, or not assessed. A fabricated "fully compliant" claim is a legal liability, so none is made anywhere on this site.

The EU Cyber Resilience Act program is Core-owned for the whole ecosystem and runs in two operational phases:

• Phase 1, operational baseline. Public coordinated-vulnerability-disclosure (CVD) policy, security.txt at the well-known location, the public posture pages on this site, the SBOM publication routine, and the internal incident-response runbook. Live across the ecosystem from 2026-05-19.
• Phase 2, Annex I gap audit. Fourteen Part-I cited rows + eight Part-II cited rows, mirrored across Core, Cairnstone, and Node security pages (2026-05-20). The first CycloneDX 1.5 SBOM ships in parallel; the public mirror at core/security/#annex-i is the canonical visible surface.

The honesty rule governs this brief too: where something is undecided it is marked open, not papered over.

Where it honestly stands#

• Nothing is launched. No Gillish tool is on the wp.org plugin directory yet. All five are pre-launch.
• Two are in active development: Cairnstone (phases 1 through 15 shipped and live, the library upgrade pass Phase 16 the current work, on the v2.3.x line) and Node (the most mature tool, on the v2.91.x line, in steady-state pre-launch work, having shed its Dynamic Tags engine to Core).
• Two are parked: Feed and Mesh, deliberately sequenced behind Cairnstone and Node, scaffolded but not built, and honest about it.
• Core is on the v0.1.x line and now carries its first feature of its own: the ecosystem grid renders, the shared Gillish menu groups and sorts the family, the menu-naming setting works, light/dark theming works, and the CRA program docs live here. Dynamic Tags (extracted from Node, now site-wide) shipped in v0.1.24, ending Core's parked-shell status; the neutral gillish_is_bot bot-detection hook consolidated in v0.1.26; and the studio's internal MCP module (the transport surface Gillish uses for its own infrastructure) shipped in v0.1.11. Deeper ecosystem features are reserved, not built.
• The platform floors are aggressive. WordPress 6.9 / PHP 8.3 minimum, tested up through WordPress 7.0 / PHP 8.5. The aggressive posture is documented and defended; floors only move forward.
• The studio is local-first: three local Studio installations cover the floor / stable / bleeding matrix (retired the remote auto-deploy matrix 2026-05-23); production is manual zip upload, always.
• The CRA program is operational: Phase 1 baseline (security.txt + CVD policy) live since 2026-05-19; Phase 2 Annex I gap audit + first SBOM landed 2026-05-20.

Strategic non-goals#

Load-bearing at the ecosystem level, not just per tool:

• Not a SaaS. Everything runs inside the user's own WordPress install, lower cost to operate, no infrastructure to scale, and the studio is not a data controller for anyone's visitors.
• Not an all-in-one. Single-purpose discipline per tool is the moat. The day a tool grows a second unrelated job, a bigger plugin can match it on breadth.
• Not a marketplace product. wp.org plus the studio's own site; the customer relationship is direct.
• Not dependency-coupled. "Better together" must never quietly become "buy the other one too or this breaks." The probe-and-degrade pattern is enforced at the architectural level.
• Not a telemetry pipeline. No data leaves the site by default. Any future telemetry is explicit opt-in or it does not ship.
• Not a held-keys product. The BYOK posture is non-negotiable across the ecosystem: the studio never holds AI-service keys; they live in the user's own WordPress install.
• Not a holding pattern on dead floors. Aggressive WordPress / PHP minimums are the bias; "we still support PHP 7.4 for the long tail" is the opposite of this studio.

Open ecosystem questions#

• A unified suite / bundle: open; working position is wait for standalone demand, revisit later.
• Cross-sell mechanics: the product-level bridges are wired and shipping; any marketing-level cross-promotion is evolving and pull-driven, not decided.
• Launch sequencing: working plan: Cairnstone and Node first (the two in active development), then Feed and Mesh when their phases unblock. Subject to how the first launches go.
• Internationalisation timing: English-first; translations are demand-driven, not pre-committed.
• Mesh commercial model: working hypothesis is freemium; not committed until Mesh exits Phase 0.
• Whether Core grows beyond the dashboard. The shell is the product until the ecosystem demands more. Ecosystem-level settings, cross-plugin status aggregation, and shared GDPR-affecting telemetry are all deliberately deferred and would be raised as their own brief.

This brief is an ecosystem-level snapshot. The per-tool product briefs, foundation plans, and security pages carry the detail; the code and each tool's in-repo planning documents stay the ultimate source of truth. See About Core for the dashboard that coordinates the family, and The Method for how a Gillish tool gets built.