diff --git a/GIT_CLONE_TUTORIAL.md b/GIT_CLONE_TUTORIAL.md deleted file mode 100644 index 7f99f36..0000000 --- a/GIT_CLONE_TUTORIAL.md +++ /dev/null @@ -1,46 +0,0 @@ -# Clone Tekton from Gitea - -## Prerequisites - -- You have a Gitea account at `https://git.klud.top`. -- For SSH clone: your public SSH key is added at `https://git.klud.top/user/settings/keys`. - -## SSH clone (preferred) - -Test SSH: - -```bash -ssh -T git@ssh.git.klud.top -``` - -Expected output: - -```text -Hi there, ! You've successfully authenticated with the key named , but Gitea does not provide shell access. -``` - -Clone: - -```bash -git clone git@ssh.git.klud.top:danchie/tekton.git -``` - -## HTTPS clone - -```bash -git clone https://git.klud.top/danchie/tekton.git -``` - -Use HTTPS when SSH keys are not available, e.g. CI scripts or temporary machines. - -## Tea CLI - -```bash -tea repos clone --git-protocol ssh danchie/tekton -``` - -## Troubleshooting - -- **`Permission denied (publickey)`** — Your key was not added in Gitea, or your SSH agent has not loaded it. Run `ssh-add ~/.ssh/id_ed25519`. -- **`Host key verification failed`** — Run `ssh -T git@ssh.git.klud.top` interactively once and accept the fingerprint. -- **`Could not resolve hostname ssh.git.klud.top`** — DNS cache stale. Wait a few minutes or flush DNS. diff --git a/TASKS.md b/TASKS.md deleted file mode 100644 index 1601012..0000000 --- a/TASKS.md +++ /dev/null @@ -1,174 +0,0 @@ -# AI Agent Workflow Guide for Tekton Dash - -This document tells AI agents how to work on Tekton Dash tasks end-to-end. - ---- - -## 1. Task Source: Notion MCP - -All tasks live on the **"TektonDash - Armageddon PR Tasks"** Notion board. - -https://www.notion.so/danchiego-game/36433be43b29800c8422ed5bdd65671b?v=36433be43b2980de8635000c0a910a0d - -### Finding Tasks - -**CRITICAL:** Always start by finding tasks from Notion. Priority order: P0 > P1 > P2 > P3. Status order: In Progress > To Do. - -Example search for "Gauntlet" tasks: -``` -Use: mcp_notion_API_post_search - query: "[Gauntlet]" or task name - filter: {"property": "object", "value": "page"} -``` - -### Reading a Task - -**CRITICAL:** The **Description** field contains the actual implementation requirements. TASKS.md defines workflow procedure only — each task's unique problem and solution are in Notion's Description field. - -Always read full task details: -``` -Use: mcp_notion_API_retrieve_a_page - page_id: "" -``` - -Each task page has these properties: - -| Property | Type | Purpose | -|---|---|---| -| **Name** | title | Task title, e.g. `[Gauntlet] #1 Game Mode Registration` | -| **Status** | select | `To Do` → `In Progress` → `Done` | -| **Priority** | select | `P0` (critical) / `P1` / `P2` / `P3` | -| **Effort** | select | `S - Small` / `M - Medium` / `L - Large` / `XL - Epic` | -| **Sprint** | select | `Alpha` / `Beta` / `Release` | -| **ProjectType** | select | `CORE` / `CLIENT` / `SERVER` / `INFRA` | -| **Description** | rich_text | Full task description — **read this to understand what to do** | -| **Acceptance** | checkbox | Check when task is verified complete | -| **DueDate** | date | Optional deadline | -| **UnitTest** | date | Optional test completion date | - -### Task Lifecycle - -``` -To Do → In Progress → Done -``` - -**CRITICAL WORKFLOW:** - -1. **Read task from Notion**: Use `mcp_notion_API_retrieve_a_page(page_id="...")` to get full task details -2. **Read Description field carefully**: This contains the actual implementation requirements — file names, function signatures, integration points, RPC patterns, etc. -3. **Implement exactly what Description specifies**: Don't invent your own approach — follow the Description's technical requirements -4. **Write unit tests**: Follow pattern in `tests/` directory (see GUT_SETUP_SKILLS.md) -5. **Update changelog**: Add entry to `CHANGELOG_DRAFT.md` (consumer-facing language, not technical jargon) -6. **Version management**: Check git diff for existing version changes (see Version Bumping section below) -7. **Mark complete in Notion**: Set `Status` → `Done`, check `Acceptance` ✅ - -``` -Use: mcp_notion_API_patch_page - page_id: "" - properties: {"Status": {"select": {"name": "Done"}}, "Acceptance": {"checkbox": true}} -``` - ---- - -## 2. Code Structure - -| Path | Purpose | -|---|---| -| `scripts/game_mode.gd` | GameMode enum + helpers (add new modes here) | -| `scripts/managers/` | All game mode managers (lobby, stop_n_go, portal, gauntlet) | -| `scenes/main.gd` | Central orchestrator — init, setup, game start routing | -| `tests/` | GUT unit tests — one file per task/feature | - -### Adding a New Game Mode - -1. Add enum to `scripts/game_mode.gd` → update `from_string()`, `mode_to_string()`, `get_all_modes()`, `is_restricted()` -2. Add mode name to `LobbyManager.available_game_modes` in `lobby_manager.gd` -3. Add arena name to `_update_available_areas()` in `lobby_manager.gd` -4. Add manager var + init branch in `main.gd` `_init_managers()` -5. Add setup branch in `_setup_host_game()` and `_setup_client_game()` -6. Add start branch in `_start_game()` -7. Add background in `_apply_arena_background()` - ---- - -## 3. Unit Testing - -### Pattern - -All tests extend `GutTest` and live in `tests/`. Naming: `test_.gd` - -```gdscript -extends GutTest - -func before_all(): - gut.p("=== Feature Tests [Task ID] ===") - -func test_something(): - assert_eq(actual, expected, "Description") - -func after_all(): - gut.p("=== Feature Tests Complete ===") -``` - -### Running Tests - -```cmd -run_tests.cmd # all tests -run_tests.cmd test_gauntlet_registration # specific test -``` - -Reports saved to `test_reports/` with timestamps. - ---- - -## 4. Version Bumping - -**Before bumping, check git for existing uncommitted version changes:** - -```cmd -git diff --cached -- project.godot CHANGELOG_DRAFT.md -git diff -- project.godot CHANGELOG_DRAFT.md -``` - -### If version changes already exist (staged or unstaged): -→ **APPEND** your changelog bullet to the existing version block in `CHANGELOG_DRAFT.md` -→ **DO NOT** bump `project.godot` or `export_presets.cfg` — you're joining an in-progress batch - -### If NO version changes exist (clean state): -→ **BUMP** version (increment patch: `2.3.5` → `2.3.6`) -→ **UPDATE** all locations below - -Version appears in **4 locations** — all must match: - -| File | Field | -|---|---| -| `CHANGELOG_DRAFT.md` | `## [X.Y.Z] — YYYY-MM-DD` header | -| `project.godot` | `config/version="X.Y.Z"` | -| `export_presets.cfg` | `application/file_version` and `application/product_version` (per preset) | -| `export_presets.cfg` | `export_path` filenames containing version | -| `export_presets.cfg` | `version/name` (Android preset) | - -### Changelog Style - -Entries are **consumer-facing** (readable by players). No internal jargon. - -```markdown -## [2.3.6] — 2026-05-22 -- Added new game mode: Candy Cannon Survival -``` - -**Bad:** "Added GAUNTLET = 3 to GameMode.Mode enum" -**Good:** "Added new game mode: Candy Cannon Survival" - ---- - -## 5. Key Conventions - -- **Caveman Mode**: Be terse. No filler. Execute first, talk second. -- **Read task from Notion FIRST**: Always use `mcp_notion_API_retrieve_a_page` to get the Description field before implementing -- **Description field is the spec**: TASKS.md is workflow procedure only. Each task's unique requirements (file names, function signatures, RPC patterns, integration points) are in Notion's Description field -- **Read before edit**: Always check whole files before modifying `.gd`, `.tscn`, `.tres`, `.res` files -- **Notion status flow**: `To Do` → `In Progress` → `Done` (never skip steps) -- **Test everything**: Every completed task gets a `test_.gd` in `tests/` -- **GUT framework**: Tests use the Godot Unit Test (GUT) addon at `addons/gut/` -- **Version discipline**: Check `git diff -- project.godot CHANGELOG_DRAFT.md` before bumping version (see Version Bumping section)