golboni/news

1. What this repository is

- This is not a traditional application repo with source code, build scripts, and runtime services.

- It is a content-production and publishing repository for the Atlantean Chronicle — Weekly Build workflow.

- The core output is a set of static HTML issue pages plus supporting media assets and operating instructions.

2. Primary control plane: the project instructions

- CHRONICLE_PROJECT_SYSTEM_PROMPT.md is the most important orchestrating artifact.

- It defines the Chronicle’s section order, design system, color variables, editorial standards, weekly workflow, checklist, privacy rules, squad context, and setup instructions.

- In architecture terms, this file acts as the policy and template layer that governs how every weekly issue is created.

3. Operational runbook

- SOP-007-Chronicle-Build.md is referenced in the README as the formal process document for the build.

- It covers the Thursday prep + Friday 20-minute build process, file locations, troubleshooting, and issue numbering reference.

- This is the process boundary separating content planning from actual issue assembly.

4. Main content artifacts: weekly issue pages

- The files atlantean-chronicle-vol1-no1.html through atlantean-chronicle-vol1-no8.html, plus chronicle-vol1-no9.html, are the actual published issue outputs.

- Each HTML file appears to represent a single numbered Chronicle release in volume 1.

- These files are the primary product surface of the system.

5. Public entry points

- index.html is likely the main landing or directory page for the Chronicle.

- mobile-news.html is a separate presentation layer for mobile consumption.

- Together, these represent the navigation/access layer that routes readers to the issue pages.

6. Media subsystem

- The photos/ and pics/ directories store visual assets used by the HTML issues and/or landing pages.

- These are supporting resources rather than standalone content units.

- Their role is the asset dependency layer for layout, illustration, or story imagery.

7. Editorial workflow and data flow

- The README describes a workflow where the system prompt is loaded into Claude Projects, a prior issue is uploaded as a project file, and a memory document is also supplied.

- The build flow is: instructions + prior issue + memory/context → next weekly issue draft → saved as HTML artifact.

- This means the repo supports a human-in-the-loop editorial pipeline, not an automated compile/deploy pipeline.

8. State and continuity model

- Issue numbering is the key continuity mechanism: No. 6, No. 7, No. 8, No. 9, etc.

- The repository preserves prior issues as a historical archive and uses them as context for future builds.

- The architecture is therefore append-only and sequential, with each issue depending on the editorial state established by previous ones.

9. External dependencies and boundaries

- The README explicitly references Claude Projects and Forgejo as outside systems.

- The system prompt is meant to be pasted into Claude project instructions, and the SOP is meant to be pushed to an external docs location.

- So the repo itself is only one part of the ecosystem; the broader architecture includes AI-assisted authoring and external documentation management.

10. No application runtime or backend

- There is no evidence of server code, package manifests, databases, or build tooling.

- The repository is best understood as a static publishing bundle with editorial governance, not a software service.

- Any architecture diagram should show a manual/content workflow rather than a runtime application stack.

11. How to diagram it

- The clearest diagram would have:

- a governance/input layer (CHRONICLE_PROJECT_SYSTEM_PROMPT.md, SOP, memory/context files),

- a content production step in Claude,

- a static issue output layer (*.html issue files),

- a navigation/access layer (index.html, mobile-news.html),

- and a media asset layer (photos/, pics/).

- The arrows should emphasize editorial generation and reuse of prior issues rather than data processing or service calls.

12. Repository summary in one sentence

- This repo is a static, AI-assisted weekly publication system where a locked editorial prompt and operating procedure drive the creation of sequential HTML Chronicle issues supported by shared media assets and entry pages.