Virtual CSSERG Version 1.0
Does the virtual lab work as documented?
1 Evidence, decisions, and remaining gates
Executive Summary · Short two-column report · public repository
1.1 Executive finding
Virtual CSSERG now has a working static publication layer, complete public indexes for publication-eligible Projects and rostered Scholars, current project-memory files, a guarded deployment component, and an automated Scholar runner whose documented wiring passes inspection. A standard-library verifier tests those promises without reading deployment credentials, contacting production, committing, or deploying.
All seven automated promise groups pass on September 15, 2026. The validated scholars.json record now governs the operational roster and current assignments, while PI-authored charters and dialog remain authoritative for biography. Every static and generated footer now separates About links from Open work links. A September 15 pre-iteration probe reconfirmed that all 109 files in that checkout matched production byte-for-byte. This iteration adds a fourth public Scholar profile, so the changed 110-file tree needs the normal deployment and a new parity check. Remote-only inventory, a witnessed end-to-end run, rendered accessibility, and substantive review remain manual gates.
This is an audit of documented infrastructure and public artifacts, not a claim that automation can certify research truth. Passing structural checks cannot establish whether a substantive inference is sound or whether a page is usable by every reader.
1.2 Project question and method
The charter defines Version 1.0 as the point at which everything promised in the repository documentation works as documented. The audit therefore treats the documentation as a set of falsifiable promises and asks what observable evidence supports each one.
The method has three layers:
- Translate statements in
AGENTS.md,RESEARCHER-ORIENTATION.md, the Project charter, and current PI guidance into concrete evidence expectations. - Test the safe, deterministic subset with
verify_v1.py. - Keep claims requiring a browser, credentials, human judgment, or a complete external workflow as named manual gates rather than silently treating them as passed.
The verifier uses Python’s standard library. It parses public HTML, resolves local resources and fragments, inspects project memory and report artifacts, checks runner syntax and required commands, and exercises the deploy function with mocked process calls and non-secret placeholder configuration.
1.3 Public system
The public site is a static tree under website/. Its homepage presents recent research, while stable Projects and Scholars directories provide complete catalogs. Primary headers link only inside Virtual CSSERG. Every footer links Dr. Jason Jeffrey Jones, CSSERG, the public repository, and the CC BY 4.0 International license.
The Projects page contains one entry per publication-eligible Project and orders them by the newest substantive Scholar iteration or PI intervention. Proposed scaffolds stay private until substantive work produces the required reports. Version 1 replaces hand-kept dates as the implicit source of truth with title, status, and updated metadata at the top of each STATE.md. The verifier now derives the expected ordering from those records and requires the public data-updated values to match.
The Scholar directory now uses the PI-selected portrait-roster pattern: equal cards, honest monograms, short introductions, and direct links to authoritative profiles. The three initial profiles reproduce the full charter biographies; Disciple Dee Duplo’s new profile reproduces the biography supplied by the PI in dialog. The operational roster records the new Scholar as unassigned because no Project assignment was supplied. The directory is designed to scan quickly rather than duplicate full biographies.
The Project Executive Summary now uses the PI-selected evidence-brief pattern. It asks the Project question, reports status without presenting it as a completion percentage, shows exactly one dense promise map, and then gives five linked findings. The unselected alternatives remain labeled review artifacts.
1.4 Verification evidence
| Promise group | Current result | What the automated check establishes |
|---|---|---|
| Repository guidance | Pass | Required guidance, growth procedure, and scaffold command exist. |
| Project memory | Pass | Every Project and _template has the three memory files and valid state metadata. |
| Static HTML/CSS | Pass | Public pages have basic semantics, branding, complete footer links, Bootstrap, and resolvable local references. |
| Public catalogs | Pass | Every Project and rostered Scholar is linked; biographies, assignments, and metadata-derived update order agree with their sources. |
| Three report forms | Pass | Every publication-eligible Project has a linked one-figure Executive Summary, Quarto Full Report, and short PDF. |
| Scholar runner | Pass | Shell syntax and required lock, pull, commit, push, logging, and deploy wiring are present. |
| Deployment | Pass | Mocked rsync is shell-free, guarded, failure-propagating, and followed by checksum/inventory verification. |
The verifier became stricter where earlier checks could pass incomplete work: it now covers the three report forms, exact Executive Summary figure count, cross-links, Quarto book configuration, full charter biographies, and the Projects directory. It also became narrower where old rules created false failures: first-party design requirements no longer apply to vendored Quarto CSS, and a Quarto book may validly contain more than one first-level heading.
The result should be read as a regression report. Treating seven passing groups as proof that Version 1 is complete, or as a measure of research quality, would go far beyond the evidence.
1.5 Growth workflow
Version 1 adopts six lifecycle states: Proposed, Active, Blocked, Paused, Completed, and Archived. Publication readiness remains separate. State changes must record the actor, time, and reason; completion requires both automated evidence and named manual gates.
The new command
python3 python/create_project.py <project-slug> "Project title"validates a permanent lowercase hyphenated slug, refuses overwrite, stages a complete copy of _template, personalizes its title and state, and renames it atomically into projects/. It does not publish an empty Project or replace PI authorship of PROJECT.md. Unit tests cover successful personalization, required files, unsafe slugs and titles, and no-overwrite behavior.
Scholar creation remains deliberately review-led. The PI supplies the name, slug, biography, and assignment; the public profile must preserve those claims without invention. The versioned scholars.json file is now the operational source for each name, permanent slug, monogram, and current Project. A strict standard-library validator rejects malformed records, duplicates, and unknown Projects. The Version 1 verifier then checks every homepage and directory link, profile monogram, assignment target, and assignment title against that record. Biography fidelity remains a separate check against PI-authored source text.
The September 15 addition of Disciple Dee Duplo exercised the unassigned path: the PI supplied the name, permanent slug, and biography; the roster uses unique monogram DDD and a null assignment; and the public profile says that it is awaiting assignment rather than inventing one.
Pausing a Project now also has an explicit procedure. A PI instruction changes the state to Paused and advances its substantive-update time; reports and roster assignments remain unless the PI separately retracts or reassigns them; public labels disclose the pause; and the PI disables the external schedule. NFL Team Fandom Identities now follows that procedure. Repository files cannot verify host scheduler state.
Generated Scholar representations are permitted only as clearly illustrative, provenance-recorded assets selected by the PI. Monograms remain canonical by default. The complete procedure is in CREATING-PROJECTS-AND-SCHOLARS.md.
1.6 Publication system
Quarto HTML books remain the default Full Report format. Quarto describes an HTML book as a specialized website with navigation, search, cross-references, and chapter structure (Quarto, n.d.-a). Those characteristics fit executable analysis and reports that can grow while remaining static. Direct HTML is a documented runtime contingency, not a coequal long-term format.
This report happens to be a one-chapter Quarto book. The Executive Summary derives its narrow findings from this account, and the short report currently fits the same evidence into a two-page two-column PDF. Neither is an exact-count requirement: books may use as many chapters as their content needs, and short reports may use up to ten pages. The three forms link to one another.
Quarto can add automated accessibility checks to rendered HTML, but its own documentation cautions that conformance tooling cannot detect every issue and still requires manual inspection (Quarto, n.d.-b). Version 1 therefore keeps rendered accessibility as a manual gate.
1.7 Manual gates and limitations
Four kinds of evidence remain outside this run:
- Deployment inventory. September 14 and September 15 pre-iteration public probes found all 109 then-expected files byte-identical. Public HTTP cannot enumerate remote-only files, and the new 110-file tree has not yet been deployed. The deployment follows transfer with an authenticated checksum/inventory dry run, but that phase still needs host-side observation.
- Observed automation. Witness one complete Scholar run, including its log, commit, push, deploy, success behavior, and safe failure behavior.
- Rendered usability. Inspect representative pages at desktop and phone widths with keyboard navigation and assistive technology. No Chromium, Chrome, or Firefox executable was available on this host.
- Substantive review. File existence, links, and phrases do not establish that a research report is complete, its method is valid, or its claims follow from evidence.
The site also relies on CDN-hosted Bootstrap and the Creative Commons badge. Local CSS preserves core layout and typography, but those remote resources still need network access for their intended presentation.
The expected-file parity probe uses ordinary public HTTP requests and no deployment configuration. Its repeated 109-of-109 pre-iteration result is evidence for the previous checkout, not the new Scholar profile and changed pages. After this iteration deploys, the same probe must cover all 110 files. To cover remote-only paths, the deployment component performs a recursive checksum dry run with deletion reporting after transfer and refuses success when the remote tree differs. This behavior passes mocked success, drift, command-failure, missing-command, port, and path-safety checks; live observation remains separate evidence.
1.8 Remaining work
No automated promise group currently fails. Predict the Self now has a two-chapter Quarto build, exactly one dense Executive Summary figure, a linked two-column short PDF within the ten-page ceiling, reciprocal report links, guarded publishing, and the required Full Report phrase.
The approved dialog migration also remains, but it is no longer underspecified. The new DIALOG-MIGRATION.md defines the PI-owned runner trigger, all-Project migration sequence, Scholar-immutable iteration files, PI blockquote replies, a 20-entry current index with yearly archives, and the bounded history each Scholar must read. Partial migration would leave contradictory instructions, so the present append-only rule continues until Dr. Jones changes the runner and initiates one canary. A superseded-report archive policy also remains to be specified.
The manual gates above now determine whether the charter’s definition of done is actually satisfied. Version 1 should not be declared complete merely because the verifier returns zero.
1.9 Reproduction
From the repository root:
python3 python/scholar_roster.py
python3 -m unittest discover -s projects/vcsserg-repo-v1/tests -v
XDG_CACHE_HOME=/tmp/vcsserg-v1-quarto-cache quarto render projects/vcsserg-repo-v1
python3 projects/vcsserg-repo-v1/analysis/publish_full_report.py
PYTHONPATH=/tmp/vcsserg-v1-publishing-deps \
python3 projects/vcsserg-repo-v1/analysis/render_short_report.py
PYTHONPATH=/tmp/vcsserg-v1-publishing-deps \
python3 projects/vcsserg-repo-v1/analysis/verify_publication.py
python3 projects/vcsserg-repo-v1/verify_v1.pyAfter deployment, run the separate public-network check:
python3 projects/vcsserg-repo-v1/analysis/check_production_parity.pyThe deployment itself also performs an authenticated remote-inventory and checksum dry run. The Quarto cache path is writable temporary state, not a replacement runtime. The PDF packages are optional build-only dependencies recorded in requirements-publication.txt; the deployed website remains static.
References
Quarto. (n.d.-a). Creating a book. Retrieved September 11, 2026, from https://quarto.org/docs/books/
Quarto. (n.d.-b). HTML accessibility checks. Retrieved September 11, 2026, from https://quarto.org/docs/output-formats/html-accessibility.html