From 49a4fa6aa8700261f753842e5949dd4619727ae4 Mon Sep 17 00:00:00 2001 From: Claude Date: Mon, 19 Oct 2026 09:15:19 +0000 Subject: [PATCH 1/4] Adopt the shared engineering standard and fill gaps in repository files - .claude/engineering-standards.md: the engineering standard shared by every repository, copied from Democracy-by-Design, where tools/sync-standards.sh keeps the copies identical. - CLAUDE.md: imports the standard on its third line; nothing else changed. - .github/dependabot.yml: monthly, minor and patch updates grouped into one pull request per ecosystem, at most two open. Each merged pull request is a production deploy, so fewer, larger updates cost fewer Netlify credits. - Workflows with no permissions block now declare contents: read. None of them writes to the repository. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_014MHzNDc4396EfY5Y96DGT8 --- .claude/engineering-standards.md | 464 +++++++++++++++++++++++++++++++ .github/dependabot.yml | 30 +- .github/workflows/tests.yml | 4 + CLAUDE.md | 2 + 4 files changed, 489 insertions(+), 11 deletions(-) create mode 100644 .claude/engineering-standards.md diff --git a/.claude/engineering-standards.md b/.claude/engineering-standards.md new file mode 100644 index 0000000..6f0c978 --- /dev/null +++ b/.claude/engineering-standards.md @@ -0,0 +1,464 @@ +# Engineering standard for every repository + +This file is the standing engineering standard for all of Varna's repositories. +The same file sits at `.claude/engineering-standards.md` in each one and is +imported by that repository's `CLAUDE.md`. The canonical copy is in +`Varnasr/Democracy-by-Design`; `tools/sync-standards.sh` there copies it to the +others. Change it there, then sync, so the copies never differ. + +The repository's own `CLAUDE.md` describes what that project is, how it is +built and the traps already met in it. Where the two disagree on a fact or a +convention of that project, the project file wins. This file sets the floor +everywhere else. + +## 0. How the standard works with what these repositories already do + +These rules come from decisions the owner has already made, and they shape how +the rest of this file is applied. + +**Ask first when the request is unclear or consequential.** The owner's +standing instruction is to ask clear clarifying questions before running code +when a request is ambiguous, when it names no target, or when the work would be +hard to undo. When the request is clear and the step is reversible and low +risk, do the work instead of stopping at a plan (section 17). + +**Deploys cost money, so changes are batched.** On 13 October 2026 the Netlify +team ran out of credits and all 35 of its sites went offline. Netlify charges +15 credits for every production deploy it publishes. A deploy preview, and a +build that is never published, cost nothing. So: + +- Work on the session's development branch and push there. Open a pull + request only when the owner asks for one, and never merge without being + asked. +- Gather a day's work and merge it once, twice at most. +- Every site on the Netlify team has auto-publishing locked except + democracybydesign.in, which must be able to take a photograph down at once. + A merge builds but goes live only at 07:47 or 19:47 IST, when the "Publish + locked sites" workflow in Democracy-by-Design (`tools/publish-locked.py`) + publishes the newest finished build of each locked site. The script reads + the locked set from Netlify, not from a list. Running that workflow by hand, + with a site name, publishes at once. A green build is therefore not a live + change; say which one you have verified. +- A workflow that commits to the production branch on a schedule makes a + build each time. On a locked site that build is free until the next publish + window; on democracybydesign.in, or on a site someone unlocks, every such + commit is a paid deploy. +- Dependabot runs monthly, groups its updates into one pull request per + ecosystem and opens at most two at a time. A weekly stream of pull requests + invites a weekly stream of merges. + +**Hosting.** Porkbun is the registrar and nothing else; Netlify does hosting +and DNS (owner's rule, 12 October 2026). A few repositories also publish to +GitHub Pages, and their `CLAUDE.md` says so. Do not move a site between hosts +unless asked. + +**Writing.** Everything a reader sees, including README files, documentation, +commit messages, issue text and the reports to the owner, follows the owner's +writing rules: plain full sentences with facts and sources; no em dashes; no +"X, not Y" or "not only... but also" constructions; no stock vocabulary +(robust, leverage, seamless, crucial, delve and the rest of the owner's list); +sentence-case headings; no emoji; no bold leads. Several repositories enforce +part of this in CI (`check-copy-tells.py`, `check_writing.py`, `BANNED` lists). +A check passing does not mean the prose is right. + +**Websites talk about their subject, never about themselves.** No page tells a +reader how it was built or researched ("read twice", "the build fails unless", +"generated by"). That belongs in `CLAUDE.md` and the research files (owner's +rule for every website, 14 October 2026). + +**Numbers.** Never restate a count copied from another repository, a partial +read, or prose that nothing checks. Take it from the source at build time, pin +it with a check, or stop stating it. Every repository that drifted did so this +way. + +**Checks must be able to fail.** No `|| true`, `|| echo`, `2>/dev/null` hiding +the reason, or `fail: false` on a gate. A long job that talks to third-party +hosts (a link crawl) goes in its own workflow on a schedule and off pull +requests, because a job cancelled by its timeout cancels the whole run. Every +new check is fault-injected against a real failure before it is trusted, and +the commit says it was. + +**What a green CI cannot see.** Colour written as a literal, colour reduced by +opacity, a control no keyboard reaches, a row wider than a phone, and an +`element.hidden` overridden by a `display` rule. After any change to colour, +layout or the header, measure in a browser: axe at 390x844 and 1280x900 in both +colour schemes, and `scrollWidth` against `clientWidth`. Chromium is installed +in the cloud sandbox; it reaches localhost and not the internet, so stub CDN +scripts by route. + +**Privacy and law.** These are public repositories. Never commit a secret, a +personal email address that is not already the published contact, or +row-level personal data (names, EPIC numbers, phone numbers). No survivor or +private person is named on a page. A licence, a privacy claim or a compliance +claim that needs a decision goes to the owner; record it as outstanding rather +than inventing it. + +**Model identifiers** never appear in commits, pull requests, code or +documentation. + +## 1. Inspect and understand the existing project + +Before changing any code: + +1. Inspect the repository: branches, directory structure, configuration, + dependencies, workflows, documentation, tests and deployment settings. +2. Identify the application's purpose, users, core functions, technologies and + external integrations. +3. Read the README, `CLAUDE.md`, open issues and pull requests, release history + and recorded decisions. +4. Identify the deployment platform, production branch, domains, environment + variables, build process and available environments. +5. Trace the real user journeys through the frontend, functions, authentication, + data, storage and external services. +6. Establish the current build and test results, from the latest CI run on the + production branch and from local runs. Record existing failures. +7. Identify incomplete features, dead links, placeholders, missing assets, + unused code, duplicated functions, broken imports and inconsistent + configuration. +8. Decide which functionality must be preserved before proposing changes. + +Inspect the files themselves; do not assume. For a live application, compare +the repository against the deployed site where access permits. + +### Preserve + +The project's identity and working functions: branding, design system, colours, +typography, illustrations, navigation, layouts, content, URLs, SEO configuration, +accessibility features and user-facing workflows. Customer information, user +accounts, payment and order records, administrative functions and database +records. + +Before a potentially destructive operation, establish a backup or a verified +rollback. Never replace an established application with a prototype, a starter +template or a generic redesign. Interface changes respect existing design +decisions unless the task is a redesign. + +## 2. GitHub repository standards + +Audit these and create, correct or update them where they apply. Apply them in +proportion: most of these repositories have one owner and no outside +contributors, so a file that exists only to satisfy a list is worse than none. + +### Core files + +- `README.md`: purpose, current functionality, setup, configuration, local + development, testing, deployment, structure, known limitations. Edit the + existing README; do not replace it. +- `LICENSE`: chosen by the owner. Never pick one on the owner's behalf; list the + repository as needing a decision. +- `.gitignore`: generated files, local configuration, secrets, build output, + caches, platform files. +- `.gitattributes`: line endings and binary handling, especially where the + repository holds audio, images or PDFs. +- `.editorconfig`: the formatting the repository already uses. +- `.env.example`: names and safe example values of every environment variable + the code reads, where it reads any. +- `CONTRIBUTING.md`: the commands a contributor actually runs, and the + conventions the project actually follows. +- `CODE_OF_CONDUCT.md`: where the project accepts outside contributions; it + needs a real reporting contact. +- `SECURITY.md`: how to report a vulnerability, to a contact the project + already publishes. +- `CHANGELOG.md`: dated release history, where the project has releases or a + changelog convention. Do not reconstruct one from commit titles. +- `CODEOWNERS`: `* @Varnasr` unless the project names other owners. +- `CITATION.cff`: for research, data and teaching repositories meant to be + cited, with only metadata that can be verified. +- `.github/FUNDING.yml`: only with real funding details. +- `.github/dependabot.yml`: monthly, grouped, at most two open pull requests + (section 0). +- `ROADMAP.md`: only for planned work the owner has stated. + +Do not invent maintainers, affiliations, email addresses, funding accounts, +DOIs, dates or licence permissions. + +### GitHub settings + +Where access permits, review: description, homepage and topics; default branch +and branch protection; pull request rules; issue labels and templates; pull +request template; Discussions, Projects and the Wiki where the project has a +use for them; releases and tags; security alerts and secret scanning; status +badges that mean something. + +The session's tools cannot change most repository settings. When a setting is +outstanding, name it exactly and say where the owner changes it. + +### Documentation + +For larger projects, technical documentation lives under `docs/`: structure, +setup, configuration, data and schemas, APIs and integrations, workflows, +administration, deployment and release, backup and restoration, security, +testing, troubleshooting, maintenance and major decisions. It describes the +software as it is. Remove claims that are no longer true. No decorative badges, +empty documents or placeholder sections. + +## 3. Code quality and architecture + +1. Clear module boundaries and responsibilities. +2. Readable, testable code, typed where the language supports it. +3. The project's own naming and formatting conventions. +4. Remove duplication and abandoned code once it is confirmed unused. +5. Validate inputs and handle errors explicitly. +6. Loading, empty, success and failure states. +7. Configuration separate from logic. +8. Dependencies current, compatible and justified. +9. No framework, service or infrastructure without a need for it. +10. Consequential decisions written down, usually in `CLAUDE.md`. +11. Backward compatibility where users or integrations depend on it. +12. Accessible, responsive interfaces. +13. Every visible control does something. +14. Development and production configuration kept consistent. + +Choose the simplest architecture that meets the requirements. + +## 4. Security, privacy and data protection + +Security review is part of every task. Inspect authentication, authorisation, +sessions, server-side validation, storage, database access, APIs, uploads, +payments and administrative functions, and apply what applies: role-based +access and least privilege; secure session and token handling; credential +rotation and revocation; server-side permission checks; input validation and +output encoding; prevention of SQL injection, XSS, CSRF and SSRF; security +headers and cookie settings; rate limits and abuse screens; secrets kept out of +code, history and browser bundles; dependency and supply-chain checks; data +minimisation and retention; logging of sensitive administrative operations; +payment verification; safe upload and download; honest privacy notices. + +Check environment variable exposure carefully on static hosting: anything a +page's JavaScript reads is public. Server-side secrets belong in Netlify +environment variables and functions. + +Payments in these repositories are UPI deep links and QR codes with no gateway. +A wrong payee fails silently, so a payee is compared against a recorded source +(`docs/upi-merchant.json` in storywell), and the amount is reconciled +downstream rather than trusted from the browser. + +Where an application serves children, holds educational records or processes +customer data, assess the risk and note which legal requirements need review. +Do not write compliance claims. + +## 5. The 111-point engineering review + +Use this as a reference list. For each concern decide whether it is applicable +and addressed, applicable and needs work, applicable and deferred with a +reason, or inapplicable to this architecture. Most of these repositories are +static sites with a few serverless functions; most of sections A, B and C do +not apply to them, and saying so is the correct answer. Do not add a technology +to satisfy the list. + +A. Systems architecture and communication: 1 rate limiting, 2 caching, 3 load +balancing, 4 reverse proxies, 5 API gateways, 6 CI/CD, 7 containers, 8 +orchestration, 9 service discovery, 10 circuit breakers, 11 timeouts, 12 +retries, 13 exponential backoff, 14 idempotency, 15 message queues, 16 +publish-subscribe, 17 event-driven architecture, 18 distributed transactions, +19 sagas, 20 dead-letter queues, 21 scheduled jobs, 22 WebSockets, 23 long +polling, 24 server-sent events. + +B. Databases, concurrency and memory: 25 indexing, 26 query optimisation, 27 +N+1 queries, 28 connection pooling, 29 read replicas, 30 sharding, 31 +partitioning, 32 replication, 33 leader election, 34 CAP trade-offs, 35 +eventual consistency, 36 optimistic locking, 37 pessimistic locking, 38 +distributed locks, 39 race conditions, 40 deadlocks, 41 memory leaks, 42 +garbage collection, 43 thread safety, 44 backpressure. + +C. Scaling, deployment and visibility: 45 autoscaling, 46 horizontal scaling, +47 vertical scaling, 48 CDNs, 49 edge caching, 50 cache invalidation, 51 +feature flags, 52 blue-green deploys, 53 canary releases, 54 rolling deploys, +55 rollback, 56 health checks, 57 liveness and readiness probes, 58 +monitoring, 59 logging, 60 tracing, 61 metrics, 62 alerting, 63 SLOs, 64 SLIs, +65 error budgets, 66 observability. + +D. Security and schema change: 67 secrets management, 68 identity and access, +69 OAuth, 70 token lifecycle, 71 TLS, 72 encryption at rest, 73 encryption in +transit, 74 WAF, 75 DDoS protection, 76 CORS, 77 CSRF, 78 SQL injection, 79 +XSS, 80 SSRF, 81 migrations, 82 schema versioning. + +E. Resilience and networking: 83 disaster recovery, 84 backups, 85 failover, +86 multi-region, 87 chaos engineering, 88 cost optimisation, 89 cold starts, +90 serverless limits, 91 latency, 92 throughput, 93 P99 latency, 94 tail +latency, 95 network partitions, 96 clock skew, 97 DNS, 98 TCP and UDP, 99 +HTTP/2 and HTTP/3. + +F. Interfaces and assurance: 100 REST design, 101 GraphQL controls, 102 gRPC, +103 API versioning, 104 pagination, 105 webhook verification, 106 +accessibility, 107 mobile and cross-browser, 108 supply-chain security, 109 +licence compliance of dependencies, 110 incident response, 111 technical debt. + +For these sites the items that usually matter are 2, 6, 11 to 14, 21, 48 to +50, 55, 56, 58, 62, 67, 71, 76, 77, 79, 80, 84, 88 to 90, 97, 105 to 109 and +111, with 88 (cost) weighted by section 0. + +## 6. Testing and quality assurance + +Cover the functionality a change touches, and the wider system where it +integrates: unit tests for logic that matters, integration and end-to-end tests +for important journeys, authentication and authorisation, validation and +errors, regressions, accessibility, responsive layout, performance where it +matters, dependency and security scanning, build verification and post-deploy +smoke tests. + +For a website, exercise the pages and controls a change touches: navigation, +links, forms, downloads, search, filters, accounts, payment flows, confirmation +messages, administration and the phone layout. An HTTP 200 is not evidence that +a feature works. For a defect that mattered, add a check that would catch it +again. + +Never say a feature was tested when it was read or inferred. + +## 7. CI/CD and dependencies + +Use GitHub Actions. The pipeline covers what applies: installs from a +lockfile, formatting and linting, type checks, tests, security scanning, +production build and deployment checks. + +Workflows declare least-privilege `permissions` (`contents: read` unless a job +needs more), pin actions to a major version or a commit, and never expose +deployment secrets to code from forks. Dependabot follows section 0, and an +automated update merges only when its tests pass. No uncontrolled major-version +upgrades. + +Releases, where a project has them, carry a version, a changelog entry and a +rollback route. A triggered workflow is not a successful deployment. + +## 8. Hosting and production deployment + +Keep the hosting the project has. For a Netlify site, verify as needed: the +linked repository, production branch, build command and publish directory, +runtime versions, `netlify.toml` and redirects, environment variables, +functions, domains and HTTPS, forms, authentication and admin routes, deploy +status and logs, scheduled functions and rollback. + +Several sites publish an allowlist rather than the whole checkout +(`stage_site.py`, `check_publish.py`), and storywell answers a forced 404 on +its private paths. A new top-level file or folder must be named as published or +private there, or CI fails by design. + +A generator that renders every Markdown file it finds publishes notes as +pages. Eleventy rendered `CLAUDE.md` as `/CLAUDE/` in the-measurement-trap, and +would have rendered this file too; both are in `.eleventyignore`. When adding a +file for tooling, check the built output for it, not only the repository. + +Never change domains, DNS, authentication providers, production data or deploy +ownership without understanding the effect and having the owner's +authorisation. Where you can verify the deployed site after release, do; where +you cannot, say exactly what was built and tested and what is unverified, and +whether the site is publish-locked. + +## 9. Database and data integrity + +Before changing a schema or how data is stored: read the schema, migrations +and dependents; identify affected records; preserve data and relationships; +write versioned migrations; plan for failure; test on non-production data; +check permission boundaries (Supabase row-level security); consider duplicate +submissions and partial failure; document the change. No destructive migration +without a backup and explicit authorisation. Service keys stay server-side. + +CMS-edited JSON (Decap, Netlify CMS) is data too: change `admin/config.yml` and +the data together, or the next save coerces the record silently. + +## 10. User experience and design integrity + +Review readable type, contrast in both themes, phone and desktop layout, +navigation, form labels, feedback, keyboard access, loading and error states, +image weight, downloads, consistent components, use of the screen, and +assistive technology. Use the project's own visual language; where a project +has none, the OpenStacks house style (`assets/css/stack.css`) and +kombai.com/gallery/web are the owner's references. Fix specific defects, and +avoid generic restyling. + +## 11. Performance and cost + +Measure before changing: bundle size, unused dependencies, image weight, +request count, blocking scripts, slow queries, duplicate calls, rendering cost, +caching, and hosting and storage cost. Readers here are often on phones and +slow connections. Compare against a recorded baseline. Infrastructure that +costs more than it earns does not go in. + +## 12. Planning and execution + +For a substantial task: inspect the current state; turn the request into +acceptance criteria; identify dependencies and regressions; plan in priority +order; implement in coherent increments with tests after each; update the +documentation with the code; verify the build; deploy only where authorised; +verify the deployed result; record what remains. Use GitHub issues where the +project already does (ImpactMojo files a `bug` issue before each fix) or where +the owner asks. + +Priority: P0 security exposure, data loss, a production outage, broken +authentication or payment. P1 broken core journeys, failing deploys, serious +accessibility defects. P2 unfinished features, maintainability, test gaps, +documentation errors. P3 cosmetic and optional work. Finish working units +rather than leaving many half-done changes. + +## 13. Git and change management + +Check status before editing and keep the owner's uncommitted changes. Work on +the session's development branch. Keep commits coherent, with messages that say +what changed and why. Read the diff before committing. Do not commit generated +files unless the project does so on purpose. Never commit credentials or +private data. No force pushes or history rewrites on shared branches. Tag +verified releases where the project uses tags. When a script changes many +files, check that every change was intended. Do not delete code only because +its purpose is unclear. + +## 14. Reporting + +After a substantial task, report with evidence, in the owner's writing style: + +A. What was reviewed: repository, branch, stack, deploy target. +B. Problems found, by severity, separating confirmed defects from suspected + risks and improvements. +C. Work done: files, commits, pull requests. +D. Repository standards: documentation, settings, tracking, dependency + automation, CI, security, releases. +E. Verification: tests and builds run and their results, deploy state, journeys + checked, failures, links to runs. +F. Remaining work: unfinished tasks, blockers, actions only the owner can take. +G. Status, one of: complete and verified; implemented, awaiting production + verification; partially complete; blocked; deferred with reason. + +Use "complete and verified" only with evidence. Never claim a commit, deploy, +test or fix that did not happen. + +## 15. Prohibited + +1. Fabricating test results, deploy results or repository actions. +2. Claiming work will continue after the session unless an automated process + has been set up and confirmed. +3. Replacing the project with an unrelated prototype. +4. Removing working functionality, or skipping, disabling or loosening a test, + to make CI pass. +5. Putting credentials in source files. +6. Disabling a security control to get around a configuration problem. +7. Inventing project metadata or ownership. +8. Adding a dependency without a clear purpose. +9. Creating infrastructure the project does not need. +10. Leaving placeholder buttons or fake functionality. +11. Changing production data silently. +12. Ignoring a broken build or a failing test. +13. Treating documentation as proof that something works. +14. Creating empty governance files to satisfy a list. +15. Hiding unfinished work or unresolved risk. + +## 16. Definition of done + +The agreed change is implemented; what worked still works; the relevant tests +and the production build pass; risks the change introduced are handled; +documentation matches the code; the work is committed and pushed; the deploy is +verified where access and authorisation allow; and remaining limits are stated +accurately. A repository-wide maintenance task also leaves governance, +workflows, tracking and documentation in a maintained state. + +## 17. Standing instructions + +Apply this standard to every task without being asked. At the start, read the +project's `CLAUDE.md` and select the checks that apply. When the request is +clear, do the work rather than stopping at a plan, and make reversible, +low-risk decisions that fit the project. Ask first, as section 0 says, before +anything destructive, a licence decision, spending money (including a +production deploy outside the batching rule), exposing a private resource or a +consequential production change. When blocked by access, finish everything that +can safely proceed and name the blocker exactly. Keep to earlier decisions +recorded in `CLAUDE.md`, and update that file when a new one is made. Treat a +failing test, a configuration error, missing functionality or a broken journey +as work to be done. diff --git a/.github/dependabot.yml b/.github/dependabot.yml index 8543312..698c075 100644 --- a/.github/dependabot.yml +++ b/.github/dependabot.yml @@ -1,13 +1,21 @@ +# Monthly, with minor and patch updates grouped into one pull request per +# ecosystem and at most two open at a time. Every merged pull request is a +# production deploy, so a steady stream of small ones costs Netlify credits +# (.claude/engineering-standards.md, section 0). Major versions still arrive +# on their own, so each one is a considered upgrade. version: 2 updates: - # GitHub Actions - - package-ecosystem: "github-actions" - directory: "/" - schedule: - interval: "monthly" - day: "monday" - open-pull-requests-limit: 2 - labels: - - "ci" - commit-message: - prefix: "CI:" +- package-ecosystem: github-actions + directory: / + schedule: + interval: monthly + open-pull-requests-limit: 2 + labels: + - ci + commit-message: + prefix: 'CI:' + groups: + github-actions-minor-and-patch: + update-types: + - minor + - patch diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml index 7e0595c..be2a049 100644 --- a/.github/workflows/tests.yml +++ b/.github/workflows/tests.yml @@ -15,6 +15,10 @@ on: push: branches: [ main ] +# Read-only: this workflow checks the repository and writes nothing back to it. +permissions: + contents: read + jobs: r: name: R diff --git a/CLAUDE.md b/CLAUDE.md index 1dc6a40..a4b7081 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -1,5 +1,7 @@ # FieldStack +Shared engineering standard: @.claude/engineering-standards.md. It applies to all work in this repository. This file adds what is specific to the project, and wins where the two disagree. + Reusable R notebooks, scripts and tools for applied data work and evaluation, built for use in the field across health, gender, climate and education programmes in South Asia. Part of the [OpenStacks](https://openstacks.dev) From 13b21b61d9b0d3aa6bb5e1e1d88050a7e03b334d Mon Sep 17 00:00:00 2001 From: Claude Date: Mon, 19 Oct 2026 09:21:15 +0000 Subject: [PATCH 2/4] Engineering standard: note that the session's clones are shallow Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_014MHzNDc4396EfY5Y96DGT8 --- .claude/engineering-standards.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/.claude/engineering-standards.md b/.claude/engineering-standards.md index 6f0c978..abbb101 100644 --- a/.claude/engineering-standards.md +++ b/.claude/engineering-standards.md @@ -305,6 +305,12 @@ again. Never say a feature was tested when it was read or inferred. +The cloud session clones each repository shallow. A script that reads git +history (a change log, a feed, a "last updated" date) either refuses to run or +writes a different answer from CI, and a refusal can look like a clean diff. +Run `git fetch --unshallow` before trusting it. WhoGaveTheOrder's `build.js` +refused, and the empty diff was briefly read as a pass (2026-10-19). + ## 7. CI/CD and dependencies Use GitHub Actions. The pipeline covers what applies: installs from a From 86d594c669a0c3f79094f04194735056ebddc011 Mon Sep 17 00:00:00 2001 From: Claude Date: Mon, 19 Oct 2026 09:32:30 +0000 Subject: [PATCH 3/4] Engineering standard: fourteen of the repositories are private Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_014MHzNDc4396EfY5Y96DGT8 --- .claude/engineering-standards.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/.claude/engineering-standards.md b/.claude/engineering-standards.md index abbb101..e8983ce 100644 --- a/.claude/engineering-standards.md +++ b/.claude/engineering-standards.md @@ -86,7 +86,13 @@ colour schemes, and `scrollWidth` against `clientWidth`. Chromium is installed in the cloud sandbox; it reaches localhost and not the internet, so stub CDN scripts by route. -**Privacy and law.** These are public repositories. Never commit a secret, a +**Privacy and law.** Most of these repositories are public. Fourteen were +private on 2026-10-19: Chromalie, Democracy-by-Design, INDIA-DATA, +IdealogWorks, WhoGaveTheOrder, WomenOnRecord, allthegoodstuff, +impactmojo-field-notes-pro, impactmojo-workshop-pro, makeitpop, +phototales-studio, pika-woodcraft, pinpointventures and storywell. A private +repository can be made public with one click, and everything in its history +goes with it, so treat every one as public: never commit a secret, a personal email address that is not already the published contact, or row-level personal data (names, EPIC numbers, phone numbers). No survivor or private person is named on a page. A licence, a privacy claim or a compliance From 905eec7964feff26a17f487d9257ac8057474d00 Mon Sep 17 00:00:00 2001 From: Claude Date: Mon, 19 Oct 2026 10:02:11 +0000 Subject: [PATCH 4/4] Docs: publish once a day at 20:00 IST [skip netlify] Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_014MHzNDc4396EfY5Y96DGT8 --- .claude/engineering-standards.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/.claude/engineering-standards.md b/.claude/engineering-standards.md index e8983ce..8fb8fe5 100644 --- a/.claude/engineering-standards.md +++ b/.claude/engineering-standards.md @@ -30,10 +30,12 @@ build that is never published, cost nothing. So: - Work on the session's development branch and push there. Open a pull request only when the owner asks for one, and never merge without being asked. -- Gather a day's work and merge it once, twice at most. +- Build all day and publish once. Do not merge on your own judgement: the + owner merges, and nothing goes live before 20:00 IST. Do not use Firecrawl + where curl or a web search will do; its credits are paid for. - Every site on the Netlify team has auto-publishing locked except democracybydesign.in, which must be able to take a photograph down at once. - A merge builds but goes live only at 07:47 or 19:47 IST, when the "Publish + A merge builds but goes live only at 20:00 IST, once a day, when the "Publish locked sites" workflow in Democracy-by-Design (`tools/publish-locked.py`) publishes the newest finished build of each locked site. The script reads the locked set from Netlify, not from a list. Running that workflow by hand,