chore: initialize gregWiki standalone repository

2026-04-11 03:29:19 +02:00 · 2026-04-08 00:10:25 +02:00
commit d377ff70a8
186 changed files with 4885 additions and 0 deletions
--- a/contributors/docusaurus-workflow.md
+++ b/contributors/docusaurus-workflow.md
@@ -0,0 +1,40 @@
+---
+id: docusaurus-workflow
+title: Docusaurus Contributor Workflow
+slug: /contributors/docusaurus-workflow
+---
+
+## Local workflow
+
+Markdown and MDX live in the repo-root `docs/` folder. The Docusaurus app is in `wiki/`.
+
+```bash
+cd wiki
+npm install
+npm run start
+```
+
+## Build workflow
+
+```bash
+cd wiki
+npm run build
+npm run serve
+```
+
+## Can we hide Docusaurus build stuff from non-contributors?
+
+Short answer for a **public repo**: **not fully**.
+
+What you can do:
+
+- Keep generated output (`build/`, `.docusaurus/`, `node_modules/`) out of Git using `.gitignore`.
+- Put docs tooling under `wiki/` so core runtime contributors can ignore it; content stays in `docs/`.
+- Use path-based CODEOWNERS to limit review noise.
+- Trigger docs CI on `docs/**` and `wiki/**` changes.
+
+What you cannot do in a public repo:
+
+- Fully hide tracked source files from non-contributors.
+
+If you need true visibility restriction, use a private repo/submodule for docs infra.
--- a/contributors/luminescent-design-system.md
+++ b/contributors/luminescent-design-system.md
@@ -0,0 +1,97 @@
+---
+sidebar_label: Luminescent design system
+description: Visual and interaction guidelines for the docs site (Luminescent Architect).
+---
+
+The **Frika Mod Framework** (FMF) is the product name for all Docusaurus branding (site title, navbar, page titles). **Luminescent Architect** names this visual design system only.
+
+# Design System Specification: The Luminescent Architect
+
+## 1. Overview & Creative North Star
+
+**The Creative North Star: "The Luminescent Architect"**  
+This design system moves away from the "flat-and-boxy" utility of standard modding sites. It treats code and community interaction as an architectural feat. We achieve a high-end editorial feel through **Tonal Depth** and **Intentional Asymmetry**. Instead of rigid grids that feel like a spreadsheet, we use overlapping layers and "light-bleed" to guide the user’s eye. The goal is a digital environment that feels like a high-end laboratory: sterile, precise, yet pulsing with the energy of the teal primary accent.
+
+## 2. Color & Atmospheric Theory
+
+We do not use color simply to decorate; we use it to define space.
+
+### The "No-Line" Rule
+
+**Explicit Instruction:** Prohibit 1px solid borders for sectioning.  
+Boundaries are defined solely through background color shifts. For example, a `surface-container-low` section sitting on a `surface` background creates a natural edge. This "Editorial Bleed" makes the interface feel expansive and premium rather than boxed-in.
+
+### Surface Hierarchy & Nesting
+
+Treat the UI as physical layers of "Synthetic Glass."
+
+- **Layer 0 (Base):** `surface` (#001110) - The deep abyss.
+- **Layer 1 (Sub-sections):** `surface-container-low` (#001715).
+- **Layer 2 (Cards/Containers):** `surface-container` (#001E1C).
+- **Layer 3 (Modals/Popovers):** `surface-container-high` (#002422).
+
+### The Glass & Gradient Rule
+
+Floating elements (Navigation, Tooltips) must use **Glassmorphism**.
+
+- **Formula:** `surface-container` at 80% opacity + `backdrop-filter: blur(12px)`.
+- **Signature Texture:** Primary CTAs must utilize a subtle linear gradient from `primary` (#61F4D8) to `primary-container` (#08C1A6) at a 135-degree angle. This prevents "flatness" and gives the button a machined, metallic quality.
+
+Implementation reference: `wiki/src/css/custom.css` (`@theme` tokens, `.btn-primary`, `.glass-card`, `.navbar`).
+
+## 3. Typography: The Editorial Edge
+
+The contrast between the technical precision of **Inter** and the geometric authority of **Space Grotesk** defines the brand.
+
+- **Display & Headlines (Space Grotesk):** Use these for hero sections and documentation titles. High-contrast and slightly wider tracking (+2%) creates an authoritative, "tech-brochure" aesthetic. Tailwind / utility: `font-headline`.
+- **Body & Labels (Inter):** Reserved for technical data and long-form wiki content. Inter’s tall x-height ensures readability against the dark `background`. Default body uses `font-sans`.
+- **Code Blocks:** Must use a monospaced font (JetBrains Mono) nested in `surface-container-highest` to differentiate logic from documentation. Utility: `font-mono` / Infima monospace variables.
+
+## 4. Elevation & Depth
+
+We abandon the traditional drop-shadow. Depth is achieved via **Tonal Layering**.
+
+- **The Layering Principle:** To lift a card, place a `surface-container-lowest` card inside a `surface-container-low` section. The "inverse lift" creates a sophisticated, recessed look.
+- **Ambient Glows:** For "floating" primary elements, use a shadow with the color `primary` at 10% opacity, a blur of `32px`, and a spread of `-4px`. This mimics the glow of a physical LED.
+- **The Ghost Border Fallback:** If a border is required for accessibility, use the `outline-variant` token at **15% opacity**. This creates a "suggestion" of a line that disappears into the background.
+
+## 5. Component Architecture
+
+### Buttons: The Kinetic Core
+
+- **Primary:** Gradient fill (`primary` to `primary-container`), `on-primary` text. Add a 2px outer glow of `primary` on hover.
+- **Secondary (Outlined):** No fill. A "Ghost Border" of `outline-variant` at 40%. On hover, the border opacity jumps to 100%.
+- **Tertiary:** Pure text in `secondary`. Used for low-priority actions in the Sidebar.
+
+### Navigation: Structural Fixed Points
+
+- **Top Bar (Global):** Height: 72px. Background: `surface` (80% opacity) with `backdrop-blur`. No bottom border; use a subtle transition to `surface-container-low` for the content area.
+- **Wiki Sidebar (Contextual):** Sticky position. Uses `surface-container-low`. Active links use a left-aligned 4px vertical pill in `primary` and high-contrast `on-surface` text.
+
+### Cards & Information Architecture
+
+- **Rule:** Forbid divider lines within cards.
+- **Implementation:** Use 24px vertical padding (from the spacing scale) to separate the header from the body. Use `surface-variant` for metadata badges (e.g., "v1.2.0") to provide a "recessed" look.
+
+### Code Blocks & Documentation
+
+- **Container:** `surface-container-highest` with a `md` (0.75rem) corner radius.
+- **Syntax Highlighting:** Use `tertiary` (#64D0FF) for functions, `secondary` (#1CEDE1) for strings, and `error_dim` (#D7383B) for keywords.
+
+## 6. Do’s and Don’ts
+
+### Do:
+
+- **Do** use `primary_fixed_dim` for icons to ensure they don't overpower the text.
+- **Do** allow for generous "negative space." High-end editorial design requires breathing room to feel premium.
+- **Do** use `surface_bright` as a very subtle "top-light" gradient on large containers to simulate overhead lighting.
+
+### Don’t:
+
+- **Don’t** use pure white (#FFFFFF) for text. Always use `on_surface` (#C0FCF6) to reduce eye strain in dark mode.
+- **Don’t** use 1px solid borders to separate sidebar items; use vertical spacing or a subtle background hover state.
+- **Don’t** use standard "drop shadows" (Black/Grey). Always tint your shadows with the background or accent color to maintain tonal harmony.
+
+## 7. Token map (implementation)
+
+Semantic colors are defined as Tailwind v4 `@theme` variables in `wiki/src/css/custom.css` (e.g. `--color-primary`, `--color-on-surface`, `--color-surface-container-low`). Prefer those utilities in React pages (`bg-background`, `text-on-surface`, `border-outline-variant/15`) so the site stays aligned with this spec.
--- a/contributors/monorepo-target-layout.md
+++ b/contributors/monorepo-target-layout.md
@@ -0,0 +1,55 @@
+---
+id: monorepo-target-layout
+title: Monorepo target layout and migration phases
+sidebar_label: Monorepo target layout
+description: Planned top-level structure and phased migration without a single big-bang refactor.
+---
+
+# Monorepo target layout and migration phases
+
+The repository **stays one Git repo**. The goal is **clear boundaries** between framework, mods, plugins, templates, docs, and tooling so users, modders, and contributors can navigate predictably.
+
+## Target topology (directional)
+
+| Top-level | Purpose |
+|-----------|---------|
+| `framework/` | Core MelonLoader framework (`framework/FrikaMF.csproj`, `framework/FrikaMF/`, entry `Main.cs`) |
+| `mods/` | Gameplay mods (`FMF.Mod.*`, `FMF.*.dll` style) |
+| `plugins/` | FFM plugins (`FFM.Plugin.*`) |
+| `Templates/` | Scaffolds for new mods/plugins |
+| `wiki/` | Docusaurus site (product docs; route base `/wiki`) |
+| `tools/` | Repo maintenance: hook catalog generator, codegen stubs |
+| `scripts/` | Release automation (existing) |
+
+**Binaries**: prefer **GitHub Releases** (and pre-releases for beta) over committing DLLs. See [Release channels](../reference/release-channels.md).
+
+## Phased migration (no big-bang)
+
+```mermaid
+flowchart LR
+  p1[Phase1_DocsAndTools]
+  p2[Phase2_MoveModsPlugins]
+  p3[Phase3_FrameworkExtract]
+  p4[Phase4_CIRedirects]
+  p1 --> p2 --> p3 --> p4
+```
+
+| Phase | Scope | Exit criteria |
+|-------|--------|---------------|
+| **1** | Docs, `tools/`, naming wiki, hook catalog script | Docusaurus build green; script generates catalog |
+| **2** | `git mv` former `ModsAndPlugins/` → `mods/` / `plugins/` | Done — `.csproj` relative paths unchanged (depth preserved); CI/docs updated |
+| **3** | Framework sources under `framework/` | Done — `FrikaMF.sln` points at `framework\framework/FrikaMF.csproj`; plugins reference `..\..\framework\framework/FrikaMF.csproj` |
+| **4** | CI matrix: docs + dotnet; `plugin-client-redirects` for old URLs | PR checks match local workflow |
+
+## Path updates checklist (Phase 2 applied)
+
+- [x] `FrikaMF.sln` project paths (`plugins\FFM.Plugin.*`)
+- [x] `.github/workflows` (CodeQL, release assets, Discord feed)
+- [x] Contributor docs and mod/plugin wiki pages (`Project Path` lines)
+- [ ] [`wiki/docusaurus.config.js`](https://github.com/mleem97/gregFramework/blob/master/wiki/docusaurus.config.js) redirects (only if public URLs must map old paths)
+- [ ] Historical wiki-import pages may still mention `StandaloneMods/` — update when editing those files
+
+## Related
+
+- [Repo inventory](./repo-inventory.md)
+- [FMF hook naming](../reference/fmf-hook-naming.md)
--- a/contributors/plugin-submission-audit.md
+++ b/contributors/plugin-submission-audit.md
@@ -0,0 +1,31 @@
+---
+id: plugin-submission-audit
+title: Plugin Submission & Security Audit Workflow
+slug: /contributors/plugin-submission-audit
+---
+
+## Goal
+
+Provide a repeatable workflow where community authors submit plugins through a Git repository URL, then pass an automated security/quality audit before publication in the wiki and release channels.
+
+## Submission Model
+
+1. Author opens a **Plugin Submission** issue.
+2. Author provides a public Git repository URL (`https://...git`).
+3. Maintainer triggers the security-audit workflow.
+
+## Automated Audit Steps
+
+- Clone submitted repository in CI.
+- Run static scan for suspicious calls and execution vectors.
+- Run secret and credential pattern checks.
+- Produce an auditable report artifact.
+
+## Release Gate Policy
+
+- If audit result is **fail**, publication is blocked.
+- If audit result is **pass**, maintainers can mark module as `releaseReady` and publish wiki/release visibility.
+
+## Multiplayer Clarification
+
+Steamworks multiplayer remains a planned direction but is currently blocked by missing Steamworks implementation on the game developer side.
--- a/contributors/repo-inventory.md
+++ b/contributors/repo-inventory.md
@@ -0,0 +1,76 @@
+---
+id: repo-inventory
+title: Repository inventory
+sidebar_label: Repo inventory
+description: Current monorepo layout, projects, and known solution drift (contributors).
+---
+
+# Repository inventory
+
+This page is the **source of truth snapshot** for how the DataCenterExporter / gregFramework monorepo is organized today. Use it before large refactors or when onboarding.
+
+## Top-level areas
+
+| Area | Path | Role |
+|------|------|------|
+| Framework core | [`framework/FrikaMF.csproj`](https://github.com/mleem97/gregFramework/blob/master/framework/FrikaMF.csproj) | MelonLoader mod hosting runtime hooks, Harmony, bridge, events |
+| Target layout / registry | [`FrikaModFramework/`](https://github.com/mleem97/gregFramework/tree/master/FrikaModFramework) | `fmf_hooks.json`, bindings stubs, migration docs |
+| Workshop tooling | [`workshopuploader/`](https://github.com/mleem97/gregFramework/tree/master/workshopuploader) (rename from `WorkshopUploader/`; see `WorkshopUploader/MIGRATION_PUBLIC_REPO.md`) | Steam Workshop / workspace uploader — **.NET MAUI** (Windows) |
+| MCP (LLM / IDE) | [`mcp-server/`](https://github.com/mleem97/gregFramework/tree/master/mcp-server) | Model Context Protocol over docs + `fmf_hooks.json`; Docker: `docker compose up docs-mcp` |
+| Mods (sources) | [`mods/`](https://github.com/mleem97/gregFramework/tree/master/mods) | Gameplay mods (`FMF.*`, `FMF.Mod.*` folders) |
+| Plugins (sources) | [`plugins/`](https://github.com/mleem97/gregFramework/tree/master/plugins) | Framework plugins (`FFM.Plugin.*`) |
+| Templates | [`Templates/`](https://github.com/mleem97/gregFramework/tree/master/Templates) | Scaffolds for new mods/plugins |
+| Documentation content | [`docs/`](https://github.com/mleem97/gregFramework/tree/master/docs) | Markdown/MDX sources for the wiki |
+| Documentation site (Docusaurus) | [`wiki/`](https://github.com/mleem97/gregFramework/tree/master/wiki) | App shell, theme, `npm run build` |
+| Scripts | [`scripts/`](https://github.com/mleem97/gregFramework/tree/master/scripts) | Release metadata, changelog (e.g. `Update-ReleaseMetadata.ps1`) |
+| Wiki import (legacy) | [`docs/wiki-import/`](./../wiki-import/Home.md) | Imported `.wiki` content; still linked from many pages |
+
+## .NET projects on disk (`*.csproj`)
+
+| Project | Location | In `FrikaMF.sln`? |
+|---------|----------|-------------------|
+| FrikaMF | `framework/FrikaMF.csproj` | Yes |
+| WorkshopUploader | `workshopuploader/WorkshopUploader.csproj` (after folder rename) | No — use `WorkshopUploader.sln` in that folder |
+| FFM.Plugin.* (x5) | `plugins/FFM.Plugin.*/` | Yes — paths in [`FrikaMF.sln`](https://github.com/mleem97/gregFramework/blob/master/FrikaMF.sln) use `plugins\...` |
+| FMF.HexLabelMod | `mods/FMF.Mod.HexLabelMod/` | No (build standalone or add to solution) |
+| FMF.ConsoleInputGuard | `mods/FMF.ConsoleInputGuard/` | No |
+| FMF.GregifyEmployees | `mods/FMF.Mod.GregifyEmployees/` | No |
+| FMF.JoniMLCompatMod | `mods/FMF.Plugin.LangCompatBridge/` | No |
+| Templates | `Templates/FMF.*`, `Templates/StandaloneModTemplate/` | No |
+
+## Build status (framework project)
+
+- `framework/FrikaMF.csproj` explicitly **excludes** `workshopuploader/**` from compile (that app builds only via `workshopuploader/WorkshopUploader.csproj` / `WorkshopUploader.sln` in that folder).
+- `dotnet build FrikaMF.sln` builds framework and plugin projects under `plugins\` — **not** the MAUI Workshop app (MelonLoader/game refs still required locally unless `CI=true`).
+
+## `FrikaMF.sln` drift (action items)
+
+1. **Mods not in solution**: Standalone mod projects under `mods/` are intentionally omitted from the solution to keep the graph small; add them if you want `dotnet build` for every module in one shot.
+
+2. **Templates in `framework/FrikaMF.csproj`**: Template sources under `Templates/` may fail `dotnet build framework/FrikaMF.csproj` with `CS0122` if `Core` visibility does not match template expectations — treat templates as **samples** until the project graph is cleaned up.
+
+## Documentation (Docusaurus)
+
+- **Entry**: `/wiki` → [`intro`](../intro.md)
+- **Sidebar**: [`sidebars.js`](https://github.com/mleem97/gregFramework/blob/master/wiki/sidebars.js)
+- **Module catalog** (downloads table): [`wiki/src/data/moduleCatalog.ts`](https://github.com/mleem97/gregFramework/blob/master/wiki/src/data/moduleCatalog.ts)
+- **Landing**: `/` → [`src/pages/index.tsx`](https://github.com/mleem97/gregFramework/blob/master/wiki/src/pages/index.tsx)
+- **Static catalog page**: `/mods`
+
+## Hook / event sources of truth (code)
+
+- String constants: [`framework/FrikaMF/HookNames.cs`](https://github.com/mleem97/gregFramework/blob/master/framework/FrikaMF/HookNames.cs) (`FFM.*` hook IDs today).
+- Numeric IDs: [`framework/FrikaMF/EventIds.cs`](https://github.com/mleem97/gregFramework/blob/master/framework/FrikaMF/EventIds.cs).
+- Generated wiki mirror: run [`tools/Generate-FmfHookCatalog.ps1`](https://github.com/mleem97/gregFramework/blob/master/tools/Generate-FmfHookCatalog.ps1) → [`fmf-hooks-catalog`](../reference/fmf-hooks-catalog.md).
+
+## Debugging (MelonLoader, IL2CPP, Unity)
+
+- **Build first:** `dotnet build FrikaMF.sln -c Debug` (requires MelonLoader + IL2CPP interop under `MelonLoader/` for your game install, or `lib/references/MelonLoader` — see `tools/refresh_refs.py`).
+- **Attach:** Run **Data Center** with MelonLoader, then attach your IDE’s **.NET / CoreCLR** debugger to the game process (process name usually matches the game executable). Breakpoints hit in **Debug** builds of mods/plugins copied into `Mods/`.
+- **`FFM.Plugin.AssetExporter`:** The project links `framework/Main.cs` (and related files) **and** references `FrikaMF.csproj`, which would normally produce **CS0436** duplicate-type warnings. Those are **suppressed** in the plugin `.csproj` (`NoWarn`); do not remove the project reference without linking the rest of the `FrikaMF` sources.
+
+## Related
+
+- [Monorepo target layout](./monorepo-target-layout.md) — phased folder goals
+- [FMF hook naming](../reference/fmf-hook-naming.md) — naming convention
+- [Release channels](../reference/release-channels.md) — Steam vs GitHub beta
--- a/contributors/sponsorship-automation.md
+++ b/contributors/sponsorship-automation.md
@@ -0,0 +1,65 @@
+# Sponsorship Automation
+
+This document describes the standard automation flow for GregFramework sponsorship tiers.
+
+## Goal
+
+Keep sponsor tier data synchronized and use it as a source of truth for:
+
+- Discord role sync
+- private/VIP channel access
+- website and wiki placements
+- Mod Store footer sponsor block
+- in-repo sponsor pages and credits
+
+## Repository Workflow
+
+Each repository contains `.github/workflows/sponsor-tier-sync.yml`.
+
+The workflow:
+
+1. runs hourly (and on manual trigger),
+2. queries active GitHub Sponsors,
+3. exports normalized data to `sponsors/sponsors.json`,
+4. commits changes automatically when sponsor data changes.
+
+## Required Secret
+
+Add this repository secret:
+
+- `SPONSORS_READ_TOKEN`: GitHub PAT with access to read sponsor relationships.
+
+Without this secret, the workflow still completes but exports an empty snapshot.
+
+## Tier Mapping
+
+Use this mapping in downstream systems:
+
+- `$1` -> `coffee_supporter`
+- `$5` -> `bronze_backer`
+- `$15` -> `silver_tester`
+- `$25` -> `gold_developer`
+- `$50+` -> `ecosystem_architect`
+
+## VIP Operational Rules
+
+For `$50+` sponsors:
+
+- assign top sponsor placement (Wiki front page + Mod Store footer)
+- create/maintain private 1-on-1 Discord lounge
+- offer featured mod spotlight
+
+## Example Consumer Script (Discord/Wiki Sync)
+
+Use `sponsors/sponsors.json` as input and run a separate scheduled job (bot or CI worker) that:
+
+1. maps each sponsor to a tier role,
+2. grants/revokes Discord roles,
+3. maintains VIP private channels,
+4. updates website/wiki data endpoints.
+
+## First Verified VIP
+
+Current VIP sponsor:
+
+- [@tobiasreichel](https://github.com/tobiasreichel) – `ecosystem_architect` (`$50/month`)