# AutoSites: Folder-Native Publishing and Distribution AutoSites is a folder-native publishing and application system built around a deliberately compact idea: **a domain is an account, the account is a folder, and the folder contains what the site needs to run**. It combines Markdown content, account settings, themes, modules, inserts, quote and passage extraction, administrative tools, media, and programmable RSS distribution. Its importance is not any single feature. It is the way the features compose into a writer's production system: write once in context, then derive pages, feeds, posters, search surfaces, and automation inputs without maintaining unrelated copies. AutoSites is the deployed application expression of the philosophy described in [[projects/X and XApps - Drop the Folder and It Runs|X and XApps: Drop the Folder and It Runs]]. --- ## What this architecture would be called now The historical names remain important, but a contemporary engineer may recognize the system faster through the following translations. These are architectural correspondences—not claims that the recovered application used today's products or terminology. - **A domain selects a matching account folder.** Modern translation: [[wiki/Multi-Tenant Architecture|multi-tenant architecture]] with [[wiki/Folder-Native Architecture|folder-native tenancy]]. - **Directories and Markdown files become routes.** Modern translation: [[wiki/Convention over Configuration|convention over configuration]] and [[wiki/Convention-Based Routing|file-based routing]]. - **Human-readable files remain authoritative while indexes can be rebuilt.** Modern translation: [[wiki/Filesystem as Source of Truth|filesystem as source of truth]], [[wiki/Read-Write Separation|read/write separation]], and [[wiki/Rebuildable Projection|rebuildable projections]]. - **Markdown content is independent of the rendering host.** Modern translation: [[wiki/Flat-File CMS|flat-file CMS]], [[wiki/Headless CMS|headless content architecture]], and [[wiki/Local-First Software|local-first portability]]. - **`{{quote}}` and `+passage` marks carry publishing intent.** Modern translation: [[wiki/Semantic Annotation|semantic annotation]] and a small authoring [[wiki/Domain-Specific Language|DSL]]. - **One essay produces quote pages, passage pages, posters, indexes, and feeds.** Modern translation: [[wiki/Content Atomization|content atomization]], [[wiki/Derivative Asset Pipeline|derivative asset pipeline]], and [[wiki/Create Once Publish Everywhere|create once, publish everywhere]]. - **Generated surfaces remain connected to the source document.** Modern translation: a [[wiki/Provenance|provenance-aware content graph]] and [[wiki/Document Graph|document graph]]. - **A collection URI selects a book, semantic projection, and transport.** Modern translation: [[wiki/Resource Addressing|resource-oriented addressing]] and [[wiki/Parameterized Syndication|parameterized content views]]. - **RSS query parameters reshape selection, identity, media, and timing.** Modern translation: [[wiki/Content Syndication|programmable syndication]], [[wiki/Content Negotiation|representation selection]], and a declarative feed API. - **An external heartbeat polls randomized, probability-gated feeds.** Modern translation: [[wiki/Event-Driven Architecture|event-driven distribution]] and scheduled automation. - **Google Docs exports are normalized into the same text pipeline.** Modern translation: a remote [[wiki/Host Adapter|authoring adapter]], content federation, and headless authoring. - **Modules, inserts, themes, and account content compose at runtime.** Modern translation: [[wiki/Plugin Architecture|plugin architecture]] and componentized presentation. - **A writer's Markdown corpus becomes searchable, attributable knowledge.** Modern translation: an AI-ready [[wiki/Document-Centric Computing|document corpus]] suitable for [[wiki/Semantic Retrieval|semantic retrieval]] and [[wiki/Retrieval-Augmented Generation|RAG]]. - **Folder paths, frontmatter, links, and source relations supply meaning.** Modern translation: [[wiki/Metadata Grounding|metadata grounding]] and a [[wiki/Layered Context Architecture|layered context architecture]]. The compact translation is: **AutoSites was a folder-native, multi-tenant, Markdown-centered publishing platform with a provenance-aware derivative-content pipeline and a programmable syndication API.** Its present AI relevance is that the same corpus can serve people, search, automation, and models without ceasing to be inspectable documents. The cross-project vocabulary is collected in [[wiki/Modern Technical Translation Map|Modern Technical Translation Map]]. ## The application model The recovered application separates common system resources from domain-specific accounts: ```text AutoSites/ ├── application modules ├── inserts ├── reusable themes ├── shared resources ├── X library └── accounts/ ├── example-one.com/ ├── example-two.com/ └── local-development-domain/ ``` At request time, the host resolves the domain, selects the matching account directory, reads its settings and content, determines the route, composes the relevant modules and inserts, and renders the response. This model made adding another site inexpensive. A new participant did not require a newly engineered application. A domain, an account folder, a reusable theme, and identity-specific content could create another independent publication surface over the shared machinery. The result is closer to a multi-tenant application platform than a conventional collection of hand-built websites, but its tenancy model remains visible in the filesystem. ## Filesystem truth and derived speed AutoSites belongs to a larger design family in which files and directories retain authority: - directory structure expresses namespaces and URL hierarchy; - Markdown files preserve human-readable source content; - settings files provide portable account configuration; - frontmatter carries document metadata; - themes and inserts remain reusable components; - caches, route indexes, and databases can be rebuilt. The intended content router was convention-based: nested directories and Markdown files would resolve naturally, and an editor would operate directly on those same structures. Roughly thirty hardcoded pages in the current recovered build were rapid-launch scaffolding, not the final content architecture. This distinction matters. The system's lasting idea is not “thirty PHP pages.” It is that a person should be able to place an organized Markdown tree into the application and have it become a navigable site. ## Markdown in, publishing system out The writer-facing architecture begins with ordinary writing. In the present Markdown workflow, braces identify a sentence worth extracting as a quote and a leading plus identifies a paragraph worth extracting as a passage. ```text An essay contains {{a sentence marked as a quote}}. +A marked paragraph can contain several marked quotes and can also become a passage. ``` The marks are small because the writer should remain in the act of writing. They are not instructions to stop, open a marketing application, design a graphic, create a landing page, copy text into a scheduler, or maintain a spreadsheet of social posts. They are semantic annotations inside the source. The generator can interpret those annotations as a publication graph: ```text Markdown manuscript | +--> marked quote 01 --> landing page + URI + poster + feed record +--> marked quote 02 --> landing page + URI + poster + feed record +--> marked quote 03 --> landing page + URI + poster + feed record | ... +--> marked quote 35 --> landing page + URI + poster + feed record | +--> marked passage --> passage page + poster + feed record | +--> source relationships, search records, and book provenance ``` An essay with thirty-five marked quotes can therefore become at least thirty-five individually addressable landing pages and thirty-five poster assets, before counting its passage pages, alternate poster treatments, search surfaces, or feed transformations. Each derivative remains connected to the essay or book in which the language belongs. The multiplication is not duplication in the ordinary sense. The source remains authoritative; the pages, posters, feed items, and indexes are projections. If the extraction rules and identifiers are deterministic, they can be regenerated while separately preserving human curation written beneath a generated item. This is why AutoSites is inseparable from my writing process. A successful sentence was not only promotional material. It became an observable conceptual unit. I could study how people responded, revise the language, build a passage around it, and eventually compose larger works from ideas that had been tested for clarity, resonance, literary quality, and philosophical coherence. ## WordChirp in the contemporary public record The surviving public record now establishes that this was not merely a later reconstruction of what I intended to build. On **January 23, 2014**, matching announcements from my Bryant McGill and McGill Media Facebook pages said that BryantMcGill.com was already running on the new system, publicly named the system **WordChirp**, and introduced it to writers who needed help finishing books and mastering social media. The post emphasized that the public documentation and interface were still preliminary; it did not describe the underlying system as hypothetical. > [!example] WordChirp publicly named and running — January 23, 2014 > ![[resources/images/mcgill-software-wordchirp-announcement-bryant-mcgill-2014-01-23.png|700]] > > The companion McGill Media capture preserves the same announcement from the company page. > > ![[resources/images/mcgill-software-wordchirp-announcement-mcgill-media-2014-01-23.png|700]] On **March 8, 2014**, I publicly described WordChirp as a system I had developed, called it “a new blogging paradigm for book writing,” identified it as powered by Google Docs, and announced that SimpleReminders.com was approaching launch on it. The accompanying artwork shows the *Voice of Reason* publishing interface on a tablet. Together, the dated post and its original visual establish a working publishing system, a named technical lineage, and a writer-centered deployment months before the later AutoSites reconstruction. ![[resources/images/mcgill-software-wordchirp-voice-of-reason-tablet-graphic-2014.png]] > [!example] WordChirp and Simple Reminders launch record — March 8, 2014 > ![[resources/images/mcgill-software-wordchirp-simple-reminders-launch-2014-03-08.png|700]] The recovered application code remains necessary for understanding how the system worked. These contemporary posts supply something different: dated public evidence that it had a name, a purpose, a live deployment, and a planned expansion to another publication. ### What “powered by Google Docs” meant “Powered by Google Docs” did not mean that Google Docs replaced WordChirp's content model or that rich-text formatting became the canonical source. It meant that Google Docs could serve as a familiar remote writing surface for people who resisted learning a specialized editor—or resisted Markdown itself. The surviving WordChirp implementation exposes the complete adapter: 1. **Cloud Settings** stores a `Google Doc ID` for a collection and presents a **Sync** button. 2. A sync requests the document's plain-text export from `docs.google.com/document/d/{id}/export?format=txt`. 3. WordChirp normalizes line endings and smart quotes, wraps the downloaded material in the same `***` document-unit separators used by local collections, and saves it as a `.googledoc` sidecar. 4. When WordChirp loads the corresponding local collection, it appends the `.googledoc` content to the collection text. 5. The combined material enters the same collection splitting, metadata extraction, quote and passage interpretation, and Markdown-to-HTML publishing path as locally written material. The person therefore remained in Google Docs and typed ordinary prose plus the lightweight Markdown and writer annotations WordChirp understood. WordChirp pulled the plain text into its native pipeline. Google Docs was the adoption bridge; **Markdown remained the interoperable language underneath it**. This also clarifies the historical strategy. I was meeting resistance from writers who did not want to change tools or learn Markdown directly. Instead of abandoning the durable text model, I adapted the system to the tool they already used. The interface became more familiar without changing the portable representation or the downstream publishing machinery. The pattern is not isolated to one recovered branch. Every CMS lineage examined so far is explicitly Markdown-centered: - **WordChirp** loads its own `markdown.php`, processes collection records through its Markdown pipeline, and imports Google Docs as plain-text sidecars; - **Markbox** preserves the same Google Doc sync, `.googledoc` sidecar, collection append, and `markdown.php` architecture; - the recovered **BryantMcGill vdev** branch likewise includes `markdown.php` and appends `.googledoc` material to collections; - the current **AutoSites** branch defaults pages to Markdown, offers Markdown/GFM editing, and limits quote/passage extraction to records whose parser is identified as Markdown. In other words, Markdown is not a modern interpretation imposed on unrelated CMS artifacts. Across the recovered systems inspected to date, it is a continuous architectural invariant. ### Why I kept saying “[[wiki/Markdown|Markdown]]” My recollection is that throughout roughly 2013, 2015, and 2017 I repeatedly urged students, writers, and audiences to learn Markdown. At the time, that could sound like a technologist's eccentric preference for a lightweight syntax. The system makes the actual reason visible. [[wiki/Markdown|Markdown]] was the smallest durable interface between the writer and the machinery. It was readable without the application, transferable between systems, friendly to versioning and search, and structured enough for software to identify headings, quotations, paragraphs, links, metadata, and intentional annotations. A writer could learn a few marks without learning the publishing stack those marks activated. The 2018 public rollout adds a second documentary layer. A **November 23, 2018** Royal Society post announced that the platform and CMS were entering beta with selected thought leaders and were expected to become fully operational by Christmas. > [!example] Platform and CMS beta announcement — November 23, 2018 > ![[resources/images/mcgill-software-cms-royal-society-platform-beta-2018-11-23.png|700]] Two days later, my [November 25, 2018 post announced the imminent launch of a **free** platform and CMS for aspiring writers and thought leaders](https://x.com/BryantMcGill/status/1066826863689924608). The campaign artwork called it the **Creativity Management System**, displayed the **McGill CMS** name, and connected it to McGill Media and the Simple Reminders Network. The word *free* is part of the contemporary announcement, not a later characterization. ![[resources/images/mcgill-cms-creativity-management-system-2018.png]] > [!example] Free platform and CMS announcement — November 25, 2018 > ![[resources/images/mcgill-cms-x-post-2018-11-25.png|700]] On **November 26**, a public preview showed **Jots** as one of many writing tools for thought leaders and described a sophisticated backend management system for organizing ideas as they emerged. On **November 30**, another Royal Society post publicly celebrated the beginning of a site for Royal thought leader Janice Wayne on an `srn.net` address, with a move to her own domain planned. These posts document both the authoring side and an actual participant deployment. > [!example] Jots and backend writing tools — November 26, 2018 > ![[resources/images/mcgill-software-cms-jots-writing-tools-preview-2018-11-26.png|700]] > [!example] Thought-leader site deployment — November 30, 2018 > ![[resources/images/mcgill-software-cms-royal-thought-leader-site-janice-wayne-2018-11-30.png|700]] This cluster directly establishes the platform, CMS, beta activity, intended users, free offering, writing tools, backend idea management, and at least one named thought-leader site. The narrower statement that I repeatedly and publicly taught **Markdown** during approximately 2013–2017 still requires its own posts, broadcasts, course materials, or recordings because these particular screenshots do not use that word. The distinction now concerns the explicit Markdown-teaching chronology—not whether the writer platform and its deployments existed. ## RSS as a programmable syndication engine Calling the system “RSS” makes it sound simpler than it is. RSS is the interoperable envelope. The underlying feature is a parameter-driven syndication engine that can select material, reshape it for a channel, alter how aggregators perceive it, attach media, and control how often an automation receives anything. ### Canonical content and late-bound distribution The decisive separation is between **canonical content** and **distribution behavior**. A quotation, passage, article, or collection can remain stable in storage while the syndication layer computes different representations of it for different destinations. One channel may receive plain text, another an image enclosure, another attributed text in the RSS title, and another nothing at all because the item fails a length or media requirement. The semantic artifact is stored once; its channel-specific form is produced when requested. This is a form of **late-bound distribution**. Decisions about eligibility, selection, timing, item identity, formatting, media, attribution, and destination behavior are deferred until the feed request is evaluated. RSS is the stable interoperability boundary through which that dynamically constructed view of the corpus is transported; it is not where the system's intelligence resides. The feed URL acts as a declarative recipe—a compact **syndication DSL** in which the path selects a source and projection while the query parameters express a publishing policy: ```text corpus + editorial selection + random selection + probability gate + item identity and time + title/description formatting + attribution + length policy + image policy + hashtag policy = channel-specific syndication feed ``` The surviving implementation actively supports the following controls: | Concern | Parameters and behavior | |---|---| | Corpus | Separate quote, passage, and quotation feed routes | | Editorial tier | `mode=all`, `mode=popular`, or `mode=mostpopular` | | Window | `limit` and `offset` | | Selection | `random=true` shuffles the eligible corpus before limiting it | | Delivery cadence | `possibility=N` gives the entire response an N-percent chance of containing items | | Item identity | `guid=random` appends a fresh random value so an aggregator can treat the selection as new | | Item time | `timestamp=now` replaces the source time with the current poll time | | Attribution | default author name, `author=none`, `author=twitter`, or `author=twittername` | | RSS author field | `itemauthor=true` emits the author's name as item metadata | | Text form | `inquotes=true` adds quotation marks; `html=strip` removes HTML | | Title routing | `totitle=true` moves the text and attribution into the RSS title and clears the description text | | Channel length | `maxlength=N` rejects items whose final title or description exceeds the limit | | Image eligibility | `hasimg=true` restricts output to records with an associated image | | Image placement | default/prepended image HTML, `img=append`, `img=env` for an RSS enclosure, or `img=none` | | Hashtags | `append`, `appendcsv`, `appenda`, and `appendcsva` variants derive tags from the generated slug, optionally with the author | | Editorial exclusions | `subtracted=true` includes material normally omitted from the public selection | The source also preserves experiments for time-range delivery, source-page versus excerpt-page links, and author-versus-post image preference. Those branches are commented or partially disconnected in the recovered version and should be treated as design evidence, not advertised as currently operational parameters. ### Identity, time, and a renewable archive Parameters such as `guid=random` and `timestamp=now` separate the stable identity of the source artifact from the identity and time of a particular syndication event. A quotation may have been written years earlier while its redistribution event occurs now. The architecture therefore has two useful temporal coordinates: **source publication time** and **syndication emission time**. That distinction turns an archive into a renewable distribution reservoir. Previously published material does not become inert merely because it is old. It remains an addressable semantic inventory that can be selected, reformatted, and reintroduced according to the policy encoded in a feed request—without modifying or duplicating the canonical source. ## The URI selects the source corpus The current reconstructed BryantMcGill.org exposes global [quote](https://bryantmcgill.org/quotes/rss/) and [passage](https://bryantmcgill.org/passages/rss/) menus. The older WordChirp and Markbox permutations went further: the URI itself selected not only the output type, but the source document or collection. The router checked whether the first URI segment corresponded to a collection file. If `voice-of-reason.txt` existed, `voice-of-reason` automatically became a collection route. Modules in the following URI segments operated on that already-selected collection. ```text /voice-of-reason/rss complete document/post feed for the Voice of Reason collection /voice-of-reason/quotes/rss Bryant McGill quotes extracted only from Voice of Reason /voice-of-reason/passages/rss marked passages extracted only from Voice of Reason /voice-of-reason/excerpts/rss attributed excerpts or quotations from other people appearing in Voice of Reason ``` The same route family applied automatically to `simple-reminders.txt`, `various-writings.txt`, `word-power-success.txt`, and any other recognized collection. An `/all` collection supplied combined-corpus counterparts. This means any document could become a syndication source merely by existing in the collection architecture. The programmer did not create a new endpoint for every book. The route was a composition: ```text domain / source collection / semantic projection / transport / parameters ``` For example: ```text /voice-of-reason/quotes/rss ?mode=popular &limit=1 &random=true &guid=random &possibility=50 &totitle=true &img=env ``` That URL describes a channel sourced specifically from one book: select a popular quote from *Voice of Reason*, choose one at random, probabilistically emit it as a newly identifiable feed item, place its text in the title, and attach its image for downstream automation. ### The menus were executable documentation The feed pages hid this complexity behind small RSS buttons arranged under **Complete**, **Popular**, and **Favorites**. The first rows answered ordinary questions—last ten, all, one random item, ten random items. Each subsequent row added one visible behavior: fresh GUID, delivery probability, social attribution, quotation marks, title routing, maximum length, and image enclosure. A second table exposed individual parameters and stated that they could be combined. The interface therefore taught composition progressively while every example remained a usable feed. A non-programmer could click a recipe, copy its URL into an automation service, and obtain a sophisticated channel without learning query-string syntax first. That is an important part of the architecture. The engine was powerful, but the public surface was intentionally simple enough for writers and publishers to operate. ## Heartbeat automation Randomization, fresh identity, and probability become especially powerful when an external service polls the feed on a heartbeat. A channel recipe can ask for one randomly selected item, make it look new to the aggregator, and return it only some percentage of the times the feed is checked. A recovered recipe has this form: ```text /quotes/rss/?mode=popular &limit=1 &random=true &guid=random &possibility=50 &author=twitter &totitle=true &maxlength=140 &img=env ``` Read as a sentence, it means: > Choose one random popular quote; give it a new item identity; emit it only half the times the feed is checked; use the author's social identity when available; place channel-safe text in the title; reject anything too long; and attach the image as an enclosure. An IFTTT-style service can check that URL repeatedly and relay each returned item to a social property. Different properties can subscribe to different recipes: short text for one channel, an image enclosure for another, authorless copy for a design surface, popular material for a high-value feed, or a broader random corpus for an archival stream. The cadence does not require a scheduling database inside AutoSites. The external heartbeat supplies time; `random=true` supplies variation; `possibility` controls density; `guid=random` supplies fresh identity; `timestamp=now` can supply a fresh date; and the remaining parameters adapt the item to its destination. ### A feed function, not merely a feed There is no single meaningful feed for the corpus. The endpoint behaves as a **feed function**: each path and parameter vector instantiates a different projection over the same canonical material. A text-only quote stream, an image-qualified social channel, a collection-specific passage feed, and a low-frequency archival resurfacing stream can coexist without maintaining separate copies of the writing. The size of this policy space is multiplicative rather than additive. This is not a claim that millions of feeds were stored or historically deployed. It describes the engine's **nominal combinatorial capacity**. Using only documented controls, a simplified model with three editorial modes, random selection on or off, 101 probability states including no probability gate, two GUID modes, two timestamp modes, four attribution modes, and binary or small-choice settings for author metadata, quotation wrapping, HTML handling, title routing, image eligibility, image representation, and editorial exclusions already exceeds **2.4 million possible parameter recipes**. That estimate still excludes values for collections, limits, offsets, maximum lengths, hashtag text, and the underlying content population. Some combinations would be redundant or unsuitable for a particular destination, so the number is an architectural upper surface—not a usage statistic. Runtime evaluation creates a second dimension: **emission trajectories through time**. The same URL can return nothing on one heartbeat, one passage on the next, and a different passage later. A previously selected item may reappear with a fresh GUID and publication time. The configuration remains stable while probability, random selection, and current-time identity produce a changing sequence of events: ```text heartbeat 1 -> no emission heartbeat 2 -> passage 412 heartbeat 3 -> passage 27 heartbeat 4 -> no emission heartbeat 5 -> passage 1931 heartbeat 6 -> passage 27 with a new GUID and pubDate ``` The system therefore has both a **configuration space**—the policies expressible by URLs—and a **temporal state space**—the possible sequences those policies can emit when repeatedly evaluated. This is the precise, bounded sense in which the endpoint behaves like a small generative publishing system: the corpus supplies durable memory, the parameter recipe supplies policy, and the heartbeat repeatedly asks the engine whether and how that memory should be expressed. ```text write and mark Markdown | v automatic quote/passage pages and posters | v parameterized RSS recipes | v heartbeat polling by an automation service | v continuous distribution across social properties ``` After the automation is connected, the writer's recurring task is still writing. New marked sentences and passages enter the same extraction and syndication system automatically. The corpus grows as the manuscript grows; the feeds continuously gain new possibilities without a separate marketing workflow. ## Premarketing as a byproduct of authorship This is the larger strategic point. A book can be marketed while it is being written because its best semantic units already have addresses, visual assets, distribution recipes, and audience feedback loops. By the time the manuscript is complete, readers may already recognize many of its sentences and ideas. The author may already know which concepts resonate, which formulations are misunderstood, and which passages deserve expansion. The book does not first meet the public on publication day; its components have been circulating, teaching, and gathering signal throughout composition. This does not mechanically guarantee a bestseller. It explains the system I used to work toward one: make the primary activity better writing, make promotion a projection of that writing, and let durable automation carry the repetitive distribution burden. ## Modules, inserts, and presentation AutoSites separates several kinds of reuse: - **modules** handle application areas such as quotes, passages, pages, themes, settings, images, menus, login, and administration; - **inserts** provide composable content or interface fragments; - **themes** provide shared presentation systems; - **account resources** supply site-specific content and identity; - **X functions** supply lower-level reusable behavior. The boundaries are not consistently clean in the historical code. The main application bootstrap carries too many responsibilities, and some modules combine routing, data access, rendering, and response behavior. Those are modernization targets. They do not erase the underlying compositional model. The appropriate refactor is incremental: preserve working URLs and content behavior while extracting request context, account resolution, routing, settings, content access, caching, module dispatch, insertion, rendering, and response into explicit boundaries. ## What the system enabled The economic and social consequence of this architecture was low marginal cost. Once the shared publishing machinery existed, another writer or thought leader could receive a domain, identity, theme, and publishing space without funding another custom platform. The same infrastructure could support teaching, community formation, publishing, and distribution while allowing each account to appear independent. The contemporary public record now documents this wider effort rather than leaving it solely as my later account. The November 2018 posts explicitly announced a **free platform and CMS** for writers and thought leaders, described beta recruitment, demonstrated Jots and backend idea-management tools, and celebrated a named participant's site. The recovered software independently shows how that promise could be delivered at low marginal cost through domain-named accounts, common application code, reusable themes, inserts, administration, and distribution tooling. Further recovery can expand the participant-level history—additional sites, people, correspondence, classes, and community records—but the existence and free writer/thought-leader purpose of the platform are now directly documented. ## The modern continuation AutoSites should remain a runnable donor and integration environment, but not the sole owner of its best ideas. The portable parts belong in shared contracts: - Markdown structure and protected regions; - quote and passage extraction; - clean display text; - deterministic slugs and identity; - provenance and source relationships; - route and account resolution; - collision and orphan reporting; - feed selection and channel transformations. AutoSites can consume PHP implementations. An Obsidian plugin can consume JavaScript implementations. Python and Perl tools can use the same fixtures during recovery and migration. The application then proves the contracts in production instead of trapping them inside one historical codebase. That is also how the intended “drop in a Markdown tree and it runs” model can be completed safely. The source remains portable; the host becomes one of several possible views. --- ## Evidence status | Claim | Basis | Status | |---|---|---| | Domains map to account folders containing site-specific settings and resources | Surviving account resolver, `_acs` structure, and currently running local instance | Artifact-visible | | AutoSites composes modules, inserts, themes, Markdown, X functions, and account data | Recovered application tree and bootstrap | Artifact-visible | | The quote/passage feed supports composable selection and transformation parameters | Surviving `quote-passage-data.php` implementation and its feed-recipe UI | Artifact-visible | | A collection filename automatically created document, quote, passage, and excerpt feed families through URI composition | Recovered WordChirp/Markbox router and RSS, quotes, passages, and excerpts modules | Artifact-visible | | “Excerpts” represented attributed quotations from other people within a source collection | Bryant McGill's clarification, consistent with the excerpt module's per-item author/source handling | Owner account with artifact support | | The compact feed menus were designed to make complex syndication accessible to writers | Surviving live menus and historical per-collection menu generators | Artifact-visible inference | | Bryant repeatedly advocated learning Markdown during approximately 2013–2017 | Bryant McGill's recollection; contemporaneous media recovery remains pending | Owner account | | The current hardcoded pages were launch scaffolding rather than the intended router | Bryant McGill's clarification, consistent with multiple recovered filesystem-routing experiments | Owner account with artifact support | | Another domain/account could reuse the common platform at low marginal engineering cost | Architecture of the recovered multi-account system | Artifact-visible inference | | WordChirp was publicly named and BryantMcGill.com was reported as running on the new system by January 23, 2014 | Dated Bryant McGill and McGill Media Facebook captures | Contemporary public record | | WordChirp was presented as Bryant McGill's book-writing system, powered by Google Docs, with SimpleReminders.com approaching launch | Dated March 8, 2014 Facebook capture and original campaign visual | Contemporary public record | | “Powered by Google Docs” meant a collection could store a Google Doc ID, export its plain text through a Sync control, preserve it as a `.googledoc` sidecar, append it to the local collection, and process it through the same publishing pipeline | Surviving WordChirp Cloud Settings sync implementation, collection loader, and Markdown processor | Artifact-visible | | Markdown is a continuous architectural element across the recovered CMS lineages inspected so far | Explicit Markdown loaders and processing in WordChirp, Markbox, and BryantMcGill vdev; Markdown-default page routing, GFM editor configuration, and Markdown-only extraction in current AutoSites | Artifact-visible | | The later platform included Jots and backend idea-management tools and entered beta with selected thought leaders | Dated November 23 and November 26, 2018 Royal Society captures | Contemporary public record | | The platform supported a wider effort to equip writers and thought leaders with free sites and publishing tools | November 25 announcement explicitly describing the platform and CMS as free, November 30 named participant-site announcement, and recovered multi-account architecture | Contemporary public record with artifact support | ## Related projects - [[projects/X and XApps - Drop the Folder and It Runs|X and XApps: Drop the Folder and It Runs]] - [[projects/Shazam - A Portable Perl Capability Library|Shazam: A Portable Perl Capability Library]] - [[projects/XDO - Executable Markdown and Portable Workflows|XDO: Executable Markdown and Portable Workflows]] - [[projects/Ten Years Building a Symbolic Language Engine|Ten Years Building a Symbolic Language Engine]]