Chore/agpl license

.claude/rules/docs-style.md

@@ -0,0 +1,50 @@
+# Docs and copy style
+
+## Tone
+
+Professional open-source developer tool: clean, technical, precise,
+trustworthy. Not generic SaaS marketing, not AI-generated filler, not startup
+hype, not fake enterprise. Write like the maintainer of a tool people trust
+with their repositories and credentials.
+
+## Positioning to emphasize
+
+- Git-owned content and portability (plain `.md`/`.mdx` in the user's repo)
+- Adapter/publisher architecture (one schema, many targets)
+- Local/private control; credentials stay server-side
+- Publishing confidence: validation, exact output preview, content QA,
+  publish checklist, demo mode
+
+## Competitors
+
+Respect Decap CMS, TinaCMS, CloudCannon, GitCMS, WordPress, and Ghost. State
+plainly where they are stronger (maturity, hosting, ecosystems, visual
+editing) and where SourceDraft differs. Never attack, never imply they are
+bad choices, never invent their weaknesses.
+
+## Evidence rules
+
+- Feature claims must match shipped code; check `docs/project-status.md`.
+- Acceptable sources: this repository, official docs of the tools discussed,
+  reputable open-source ecosystem guidance, neutral UX/product principles.
+- Not acceptable as neutral evidence: vendor marketing pages, SEO listicles,
+  fabricated statistics, competitor sales pages. Real user/founder reviews may
+  be cited only as clearly-marked anecdotes.
+- No fake screenshots, metrics, benchmarks, or testimonials.
+
+## UX writing principles
+
+Optimize docs and UI text for: fast first success, low cognitive load, clear
+system status, obvious next action, recognition over recall, error
+prevention, user control and recovery, progressive disclosure, transparent
+limitations, and trust around credentials and publishing. The reader is
+technical but may be new to Git-based CMS workflows.
+
+## Mechanics
+
+- Sentence-case headings, short paragraphs, tables for matrices.
+- Every doc links onward to the next logical doc.
+- Commands shown must actually work from the repo root (or state the cwd).
+- Mark experimental/partial features inline, not only in a footnote.
+- Keep "MVP password auth is intended for local/private use" warnings wherever
+  exposure to the public internet could be implied.

.claude/rules/no-scope-creep.md

@@ -0,0 +1,41 @@
+# No scope creep
+
+SourceDraft launches first as a genuinely useful free and open-source AGPL
+project. The free version must not be artificially crippled, and monetization
+is **not** implemented now.
+
+## Forbidden in the current phase
+
+Do not implement, scaffold, stub, or document as available:
+
+- Paywalls, billing, SaaS plans, license gates, or feature flags that gate
+  open-source functionality
+- Telemetry or analytics collection of any kind
+- OAuth, user accounts, team accounts, or RBAC
+- Hosted / multi-tenant Studio
+- Plugin marketplace
+- AI writing tools
+- Large UI redesigns
+
+Also forbidden: fake screenshots, fake metrics, fake benchmarks, and
+production/enterprise overclaims in any doc or UI string.
+
+## Allowed to mention (roadmap only)
+
+Future commercial possibilities (hosted SourceDraft Cloud, managed onboarding,
+OAuth/team accounts, RBAC, managed media, premium support, agency workspaces,
+migration services, dual licensing) may appear in `docs/roadmap.md` as
+clearly-labeled future options — never as current features, never as code.
+
+## Decision filter
+
+Classify every proposed change as one of:
+
+1. **True launch blocker** — broken, misleading, insecure, or missing piece
+   that would embarrass the project on day one. Do it.
+2. **High-value polish** — improves first success, clarity, or trust with low
+   risk. Do it if cheap and in scope.
+3. **Later roadmap** — useful but not now. Write it down in `docs/roadmap.md`
+   or an issue; do not implement.
+4. **Explicitly not now** — anything on the forbidden list. Refuse, even if
+   requested casually, and point to this file.

.claude/rules/release-gates.md

@@ -0,0 +1,45 @@
+# Release gates
+
+Before tagging a release, merging release-related PRs, or recommending any
+public promotion, all gates below must pass. See `RELEASE_CHECKLIST.md` and
+`docs/public-launch-checklist.md` for the full operator checklists.
+
+## Automated gates
+
+```bash
+pnpm install --frozen-lockfile
+pnpm build
+pnpm test
+pnpm test:e2e   # required for releases and any UI/auth/publish change
+```
+
+- CI (`.github/workflows/ci.yml`) green: build, unit tests, studio e2e
+- CodeQL: no open high-severity alerts on the release PR
+
+## Repository hygiene gates
+
+- `LICENSE` is AGPL-3.0-or-later; no stray MIT references anywhere
+- `.env` / `.env.local` gitignored and not committed
+- No-secrets scan clean on tracked files (tokens, passwords, private keys):
+  `git grep -nIiE 'ghp_[A-Za-z0-9]|gho_[A-Za-z0-9]|BEGIN [A-Z]+ PRIVATE KEY' -- ':!*.example*'`
+- No QuBrite hardcoding in `*.ts` / `*.tsx` app logic
+
+## Honesty gates
+
+- README, `docs/project-status.md`, and `CHANGELOG.md` agree on shipped vs
+  experimental vs not-shipped
+- Stated limitations still accurate: MVP password auth, in-memory sessions,
+  Contents API scale limits, `s3-compatible` upload not implemented, no post
+  list for Bitbucket/WordPress/Ghost
+- No screenshots showing tokens, real repo secrets, or personal data
+- No production/SaaS/enterprise claims anywhere
+
+## Manual gates (release only)
+
+- Demo mode walkthrough passes (`docs/manual-acceptance-test.md`)
+- Real publish against a **test** GitHub repository: direct commit and
+  pull-request mode both verified
+- Screenshots regenerated (`pnpm screenshots:generate`) if UI changed
+
+If any gate fails, the release stops. Document the failure; do not waive
+gates silently.

.claude/rules/source-draft-project-rules.md

@@ -0,0 +1,38 @@
+# SourceDraft project rules
+
+SourceDraft is an open-source publishing Studio for Markdown, MDX, and
+Git-backed content workflows, with an adapter/publisher architecture for
+multiple static-site frameworks and CMS targets. License: AGPL-3.0-or-later.
+
+## Product identity
+
+- Target users: solo developers, technical bloggers, documentation-site
+  maintainers, Astro/Next.js/Hugo/Docusaurus/MkDocs/Nuxt Content users, and
+  small teams that want Git-owned content.
+- Core promise: Git-owned, portable content; secrets server-side; publishing
+  confidence (validation, preview of exact output path/file, content QA).
+- SourceDraft is **not** WordPress, not a site builder, not a hosted CMS.
+- QuBrite.com is the origin story only. Never hardcode QuBrite (or any single
+  site) into core logic, defaults, or fixtures.
+
+## Engineering rules
+
+- Universal article schema lives in `@sourcedraft/core`; adapters and
+  publishers consume it through `adapterRegistry` / `publisherRegistry`.
+- Secrets are read from `.env` in `apps/studio/server` only. Browser code must
+  never import publisher/media packages or see credential values.
+- Keep modules typed, small, and testable. Prefer boring reliable code.
+- No unnecessary comments, no unrelated refactors, no dependency additions
+  without explicit justification.
+- Errors returned to Studio must be clear and actionable, without leaking
+  secret values.
+
+## Honesty rules
+
+- Docs and UI describe only what is implemented. Shipped vs experimental vs
+  not-shipped follows `docs/project-status.md` — update it when status
+  changes, and keep README/CHANGELOG consistent with it.
+- No fake analytics, fake charts, fake metrics, fake screenshots, placeholder
+  features, or production/enterprise overclaims.
+- Known limitations (MVP auth, in-memory sessions, Contents API scale limits,
+  S3 upload not implemented) stay visibly documented until fixed.

.github/ISSUE_TEMPLATE/adapter_request.md

@@ -0,0 +1,36 @@
+---
+name: Adapter request
+about: Request or propose a new file adapter (framework/static-site generator)
+title: "adapter: "
+labels: enhancement, adapter
+assignees: ""
+---
+
+## Framework / generator
+
+<!-- e.g. Gatsby, Zola, VitePress — link the official docs -->
+
+## Frontmatter format
+
+<!-- YAML / TOML / JSON? Required fields? Link to the framework's content docs -->
+
+## Field mapping
+
+<!-- How universal fields map: pubDate → ?, updatedDate → ?, category → ?,
+     heroImage → ?, draft → ?, tags → ? -->
+
+## File path conventions
+
+<!-- Default contentDir, extension (.md/.mdx), filename conventions
+     (slug / date-slug / index), anything unusual -->
+
+## Example post file
+
+```markdown
+<!-- Paste a real (sanitized) post file from a site using this framework -->
+```
+
+## Are you willing to implement it?
+
+<!-- Adapters are a great first contribution — see docs/contributing-roadmap.md.
+     Copy the structure of packages/adapter-hugo-markdown. -->

.github/ISSUE_TEMPLATE/publisher_request.md

@@ -0,0 +1,37 @@
+---
+name: Publisher request
+about: Request or propose a new publish target (Git host or CMS API)
+title: "publisher: "
+labels: enhancement, publisher
+assignees: ""
+---
+
+## Target
+
+<!-- e.g. Gitea, Forgejo, Strapi — link the official API docs -->
+
+## Kind
+
+<!-- Git file commit, or remote CMS API? -->
+
+## Auth model
+
+<!-- Token type/scopes, app passwords, API keys. Secrets must stay
+     server-side in .env — note any auth flow that can't work that way (e.g.
+     OAuth-only APIs are currently out of scope). -->
+
+## Capabilities expected
+
+- Publish new post: yes / no
+- Update existing post: yes / no (how is the post identified?)
+- Upload media: yes / no
+- List/read posts: yes / no
+
+## Why not a plugin?
+
+<!-- Custom publishers can load via server-side plugins (docs/plugins.md).
+     Why should this one be built in? -->
+
+## Are you willing to implement it?
+
+<!-- See the publisher interface in docs/compatibility-roadmap.md -->

.github/ISSUE_TEMPLATE/security_hardening.md

@@ -0,0 +1,30 @@
+---
+name: Security hardening
+about: Propose a hardening improvement (NOT for reporting vulnerabilities)
+title: "hardening: "
+labels: security
+assignees: ""
+---
+
+<!-- ⚠️ Do NOT report exploitable vulnerabilities here.
+     Use private reporting instead — see SECURITY.md. -->
+
+## Area
+
+<!-- e.g. sessions, CSRF, upload validation, rate limiting, headers,
+     reverse-proxy deployment guidance -->
+
+## Current behavior
+
+<!-- What the code does today. Known MVP limitations are documented in
+     docs/security.md — check it first. -->
+
+## Proposed hardening
+
+<!-- What should change, and for which deployment scenario
+     (local-only / private network / reverse proxy)? -->
+
+## Trade-offs
+
+<!-- Complexity, new dependencies (avoid if possible), impact on local-dev
+     ergonomics and the demo-mode e2e tests -->

.github/pull_request_template.md

@@ -0,0 +1,30 @@
+## What and why
+
+<!-- What does this PR change, and what problem does it solve?
+     Link the related issue if one exists. -->
+
+## Type of change
+
+<!-- Check what applies -->
+
+- [ ] Bug fix
+- [ ] Feature (adapter / publisher / Studio / server)
+- [ ] Documentation
+- [ ] Tests / CI
+- [ ] Refactor (no behavior change)
+
+## Checklist
+
+- [ ] `pnpm build` passes
+- [ ] `pnpm test` passes
+- [ ] `pnpm test:e2e` passes (required if Studio UI, auth, demo mode, or publish flows changed)
+- [ ] Tests added/updated for logic changes
+- [ ] Docs updated if behavior or configuration changed (including compatibility matrices)
+- [ ] No secrets in code, fixtures, tests, or screenshots; nothing credential-related in browser code
+- [ ] No new dependencies (or justified below)
+- [ ] In scope — no monetization, telemetry, OAuth/RBAC, or hosted features (see docs/roadmap.md "Explicitly not now")
+
+## Test notes
+
+<!-- How you verified the change. For publisher changes: which target you
+     tested against (use a test repo/site, never production credentials). -->