theIdea.club — Platform Architecture Handoff

For staging-claude and production-claude. Architecture decisions only — ask clarifying questions as you implement.

1. Rename: Project → Idea

The platform is theIDEA.club, not the PROJECT.club. The term "Project" should be replaced with "Idea" everywhere:

URLs (e.g. /projects/fishing-foiler → /ideas/fishing-foiler)
Navigation and UI copy
Database fields and model names
Code variables, functions, and comments

This is a mechanical find-and-replace across the codebase plus a data migration. Take care with any external links or bookmarks that may use the old URLs.

2. Git Repository Per Idea

Every Idea gets its own Gitea repository on git.theidea.club, auto-created when the Idea is created.

Naming convention: {member-handle}/{idea-slug} — e.g. paul/fishing-foiler
The repo is the source of truth — a verbatim log of all user↔AI transactions. Context files and summaries are derived from it, not the other way around.
Repo visibility must mirror the Idea's visibility setting (see Section 4).

3. Storage Per Idea

Every Idea gets 10GB of storage on files.theidea.club, which runs as a Nextcloud AIO instance.

Storage is provisioned automatically when an Idea is created.
Nextcloud folder-level sharing should mirror the Idea's visibility and contributor access settings (see Sections 4 and 5).

4. Idea Visibility Model

Every Idea has one of three visibility levels, set by the owner and changeable at any time:

Private — only the owning member can access. Invisible in search and all feeds.
Shared — only explicitly named contributors can access. Visible in their dashboards but not in public search or browse feeds.
Public — anyone can access, including non-members. Appears in the public browse/explore feed.

Visibility can also be set at the page or folder level within an Idea — e.g. a mostly-public Idea can contain private working notes. Authors can change visibility for any page or folder at any time, self-serve.

Visibility must be mirrored across services:

git.theidea.club — repo is private, collaborator-access, or public to match
files.theidea.club — Nextcloud folder sharing scoped to match
LDAP (if/when implemented) — group membership drives access consistently across www, git, and files

5. Dashboard Order

A member's dashboard lists Ideas in this order:

Their own Ideas (any visibility level)
Shared Ideas they own and have opened to contributors
Shared Ideas they are contributing to (other members' Ideas where they hold a Contributor role)

6. Contributor Role

A Contributor is a distinct role — not ownership, not plain read access. Contributors are named explicitly on a Shared Idea.

Adding Contributors

Only the owner can add a contributor directly.
An existing contributor can nominate another contributor, but it is gated by owner approval — same gate, different initiator.

Contributor Role Scoping

Contributor roles are scoped. Levels can be mixed per contributor:

Read — can view content only
Comment/Suggest — can post content, but it is gated (owner must approve before publishing)
Write — can post content directly, auto-published
Nominate — can propose new contributors (still requires owner approval)

Contribution Policy

The owner sets a per-Idea contribution policy:

Moderated — all contributions require owner approval before publishing
Open — contributions from Write-level contributors are auto-published

Implications for Services

git.theidea.club — Contributors get Gitea collaborator access (push rights if Open, PR-only if Moderated)
files.theidea.club — Nextcloud folder access scoped to the contributor
LDAP — a contributor group per Idea would make cross-service access consistent

7. Web Server as Git Proxy

The theIdea.club web server acts as an authenticated proxy between AI agents and git.theidea.club. AI agents (API Claude and others) never hold Gitea credentials directly.

A dedicated Gitea service account (e.g. theidea-app) holds auth credentials on the server. This account does not yet exist — needs to be created.
The server exposes git operations as tools that API Claude can call (same pattern as fetch_url): e.g. git_read_file, git_write_file, git_list_repo, git_create_repo
Tool definitions are injected into the API Claude system prompt at session start
The server executes the actual Gitea REST API calls and returns results to API Claude

API Claude read access is confirmed. Write access (whether API Claude can commit directly vs. only proposing content for the server to commit) is held open — to be decided as implementation progresses.

8. API Claude as Curator

API Claude's role is not just a chat agent — it is the curator of the discussion record across all Ideas. Because the git repo is the source of truth and context files are derived summaries, API Claude needs read access to verify those summaries match the full history at any time.

9. Infrastructure Overview

www.theidea.club     — the platform (web server, git proxy)
mail.theidea.club    — member communications
files.theidea.club   — Nextcloud AIO (10GB storage per Idea)
git.theidea.club     — Gitea (one repo per Idea, source of truth)
         ↕
   [LDAP in DMZ]     — unified auth across all four services (planned)

Each of the four services already supports LDAP. staging-claude has more context on the current state of LDAP planning.

10. Open Questions for staging-claude

What is the current state of LDAP planning? Is a host provisioned or just under consideration?
What is the current Gitea setup — are any service accounts or org structures already in place?
How is Nextcloud AIO currently configured — is per-folder provisioning via API already available?
What is the current URL structure for Ideas, and what is the safest migration path for the Project→Idea rename?
What git tool calls does API Claude most urgently need first — read-only access to context files, or full CRUD?

Reading rider intent.