Initial wiki structure

This commit is contained in:
2026-04-19 03:57:03 +00:00
commit 31c3083ff4
11 changed files with 1041 additions and 0 deletions

View File

@@ -0,0 +1,50 @@
# Git Sync Protocol & Repository Structure
The Git repository serves as the **Single Source of Truth (SSOT)** for all wiki content. This document defines how data is structured and synchronized.
## 1. Repository Layout
```text
/
├── content/ # All Markdown wiki pages
│ ├── ships/
│ ├── modules/
│ └── ...
├── assets/ # Images, PDFs, and static files
│ ├── images/
│ └── ...
├── schema/ # Shared validation schemas (JSON Schema)
├── metadata/ # Global metadata (e.g., typeID mapping table)
│ └── mapping.json
└── .wikijsignore # Files to be ignored by Wiki.js sync
```
## 2. Synchronization Flow
### Primary Write Path (Agent -> Git -> Wiki.js)
1. **Agent Modification:** An agent (A, B, or C) generates or updates a Markdown file.
2. **Local Commit:** The agent commits the change to its local clone of the repository.
3. **Push to Origin:** The agent pushes to the `main` branch.
4. **Wiki.js Sync:**
- Wiki.js is configured with the "Git" storage target.
- It pulls changes from the `main` branch at a set interval (default: 5 minutes) or via Webhook.
- Wiki.js renders the new Markdown content in the UI.
### Wiki.js to Git (Optional / Prohibited)
- **Status:** DISABLED
- **Rationale:** Since human editing is disabled, there should be no writes originating from the Wiki.js UI. This prevents merge conflicts and ensures the Agent pipeline remains the sole source of content.
## 3. Commit Standards
To ensure a clean audit trail, all commits must follow the Conventional Commits-style with agent identifiers:
**Format:** `[AGENT_ID] action: description (hash: source_hash)`
**Examples:**
- `[AGENT_A] seed: ships/caldari/condor (hash: sha256_...)`
- `[AGENT_B] update: ships/amarr/abaddon (patch: 2026-04-16)`
- `[AGENT_G] asset: images/ships/condor.png`
## 4. Conflict Resolution
- **Strategy:** Last-Write-Wins (LWW) based on Git commit timestamp.
- **Merge Logic:** Automated merges are preferred. If a conflict occurs (rare in agent-only environments), the pipeline will halt and trigger a "System Alert" for manual intervention.

View File

@@ -0,0 +1,36 @@
# Wiki.js API Authentication & Security Strategy
## 1. Authentication Method
- **Token Type:** Permanent API Keys (Bearer Tokens)
- **Generation:** Generated via the Wiki.js Administration Area -> API Keys
- **Storage:** Stored as environment variables in the agent runtime environment (e.g., `WIKIJS_API_TOKEN`).
## 2. Permission Scopes
To maintain security, the API token used by agents will be restricted to the minimum necessary scopes:
| Scope | Requirement | Justification |
|-------|-------------|---------------|
| `write:pages` | Mandatory | Allows agents to create and update content |
| `read:pages` | Mandatory | Allows agents to check existing content before updates |
| `write:assets` | Mandatory | Allows Agent G to upload images/files |
| `read:assets` | Mandatory | Allows checking for existing assets |
| `read:tags` | Optional | Allows metadata tagging |
| `manage:system` | **Prohibited** | Agents must NOT have administrative system access |
## 3. Token Rotation Policy
- **Frequency:** Tokens should be rotated every 90 days.
- **Process:**
1. Generate new token in Wiki.js.
2. Update environment variable in agent deployment (Komodo/Docker).
3. Verify connectivity.
4. Revoke old token.
## 4. Write Access Control
- **Human Editing:** All human accounts in Wiki.js will be assigned to a "Read-Only" group.
- **Agent Editing:** Only the API account (associated with the token) will have write permissions.
- **Emergency Bypass:** A single "Admin" account will be maintained for emergency manual intervention, protected by 2FA.
## 5. Security Best Practices
- **TLS:** All API calls MUST be made over HTTPS.
- **IP Whitelisting:** If possible, Wiki.js should be configured to only accept API requests from the IP of the agent runner.
- **Audit Logs:** Enable Wiki.js audit logging to track all changes made via the API token.