@slycode/slycode 0.1.1 → 0.1.2

package/templates/tutorial-project/documentation/kanban.json

@@ -0,0 +1,385 @@
+{
+  "project_id": "slycode_tutorial",
+  "stages": {
+    "backlog": [
+      {
+        "areas": [],
+        "tags": [
+          "tutorial",
+          "guide"
+        ],
+        "problems": [],
+        "checklist": [],
+        "created_at": "{{TIMESTAMP}}",
+        "updated_at": "{{TIMESTAMP}}",
+        "id": "card-tutorial-1",
+        "title": "Start Here: What This Board Is",
+        "description": "Welcome to SlyCode Tutorial.\n\nThis board teaches SlyCode by having you use it, not read docs.\n\nWhat to notice first:\n- Cards move left to right through stages\n- Each card has a Terminal tab with action buttons\n- When you click an action, AI does the work for that card\n\nRead the next two short cards, then open the companion card and start the hands-on flow.",
+        "type": "chore",
+        "priority": "low",
+        "order": 10
+      },
+      {
+        "areas": [],
+        "tags": [
+          "tutorial",
+          "guide"
+        ],
+        "problems": [],
+        "checklist": [],
+        "created_at": "{{TIMESTAMP}}",
+        "updated_at": "{{TIMESTAMP}}",
+        "id": "card-tutorial-2",
+        "title": "If You Don't Like Tutorials",
+        "description": "If you want the fast version, here are the core points.\n\n- Move cards through stages by dragging them across lanes.\n- Open a card, go to Terminal, and run the stage action buttons; the AI handles the workflow for you.\n  - Base Kanban and messaging skills are included to teach your agent how to interact with SlyCode.\n  - It can move cards between lanes as part of your workflow.\n  - It can attach planning docs to cards (design docs, feature specs, and chore plans when used).\n  - It can add/edit notes and keep a running context trail.\n  - It can create and update testing checklists directly on the card.\n- Sly Actions are lane-aware meta-prompts built on top of your CLI skills/agents, and they can reuse those same skills/agents. You can customize them from the top-right menu (three-line icon).\n- Cards and workflows can be automated from the top-right clock icon.\n- Archived cards are visible via the top-right archive/box icon.\n- Card terminal (Terminal tab) [runs in project workspace].\n- Project terminal (bottom-right) [runs in project workspace].\n- Global terminal (Dashboard) [runs in SlyCode workspace].\n- Skills are managed from Dashboard/Toolkit: stored centrally, then deployed to projects for Claude or .agents (Codex/Gemini).\n- Voice input works after OpenAI API key setup; default hotkey is Ctrl + .\n- Telegram can be linked for updates.\n  - Create your own Telegram bot with @BotFather, then use that token in config.\n  - Add bot token and chat ID in your environment/config.\n  - Start messaging service and send a test message.\n  - For voice in Telegram, add your OpenAI key (STT) and ElevenLabs key (TTS) in `.env`.\n  - Enable report-via-messaging on automations when you want async summaries.\n  - You can also ask the agent to message you in any workflow at any time.\n\nIf this is enough context, jump straight to the companion card, or add one of your own projects from the dashboard and start working on your real code.",
+        "type": "chore",
+        "priority": "low",
+        "order": 20
+      },
+      {
+        "areas": [],
+        "tags": [
+          "tutorial",
+          "guide"
+        ],
+        "problems": [],
+        "checklist": [],
+        "created_at": "{{TIMESTAMP}}",
+        "updated_at": "{{TIMESTAMP}}",
+        "id": "card-tutorial-3",
+        "title": "Cards, Stages, and Progress Signals",
+        "description": "Quick orientation before you begin:\n\n- Backlog: clarify work\n- Design: define approach\n- Implementation: build\n- Testing: verify\n- Done: graduate / expand\n\nUseful signals on cards:\n- Checklist progress\n- Problem indicators\n- Session status\n\nNow open the companion card below, switch to the Terminal tab, and run Onboard to start the guided path.",
+        "type": "chore",
+        "priority": "low",
+        "order": 30
+      },
+      {
+        "areas": [],
+        "tags": [
+          "tutorial",
+          "companion"
+        ],
+        "problems": [],
+        "checklist": [],
+        "created_at": "{{TIMESTAMP}}",
+        "updated_at": "{{TIMESTAMP}}",
+        "id": "card-tutorial-4",
+        "title": "Companion Card: Ship a Tiny Tutorial Output",
+        "description": "Build one small, useful output for this tutorial.\n\nTarget output for this card:\n- A clear card description that explains the task outcome\n- A practical checklist with 3-5 verification items\n- One short agent note summarizing what was done\n\n---\n\nJourney map for this card:\n- Backlog: run Onboard\n- Design: run Design Doc, then Feature Spec\n- Implementation: run Implement (Quick Fix optional)\n- Testing: run Test Review, then Approve\n\n## Tutorial AI Instructions\nKeep this tutorial task lightweight and educational.\n- Prefer concise outputs over production-depth expansions\n- Keep the user inside SlyCode UX (card, checklist, notes, linked docs)\n- Follow the current stage intent for this card\n- Do not delete this \"Tutorial AI Instructions\" section during Onboard or later stage actions\n- In Design stage, ask exactly one easy question, then proceed: \"Should I format this output as short bullets or a short paragraph?\"\n- If uncertain, ask one focused question, then proceed",
+        "type": "feature",
+        "priority": "medium",
+        "order": 40
+      },
+      {
+        "areas": [],
+        "tags": [
+          "tutorial",
+          "automation"
+        ],
+        "problems": [],
+        "checklist": [],
+        "created_at": "{{TIMESTAMP}}",
+        "updated_at": "{{TIMESTAMP}}",
+        "id": "card-tutorial-17",
+        "title": "Weekly Standup",
+        "description": "You are running a morning standup report. Analyse the current board state and deliver a concise briefing.\n\n**Steps:**\n1. Run `sly-kanban board` to get the full board snapshot.\n2. Summarise the state in this format:\n\n**In Progress** \u2014 What's actively being worked on (implementation/testing stages). Note any cards that have been in the same stage for multiple days.\n\n**Blocked / Stale** \u2014 Cards with unresolved problems, or cards that haven't moved recently.\n\n**Recently Completed** \u2014 Cards moved to done since the last standup.\n\n**Suggested Focus** \u2014 Based on priority, dependencies, and momentum, recommend which 1-2 cards should get attention today.\n\n3. Archive any done cards that are older than 48 hours: `sly-kanban search --stage done`, check timestamps, and `sly-kanban archive <card-id>` for stale ones.\n4. Keep the report under 15 lines. Be direct \u2014 this is a status check, not an essay.",
+        "type": "chore",
+        "priority": "low",
+        "order": 901,
+        "automation": {
+          "enabled": false,
+          "schedule": "0 9 * * 1",
+          "scheduleType": "recurring",
+          "provider": "claude",
+          "freshSession": true,
+          "reportViaMessaging": true
+        },
+        "archived": false
+      },
+      {
+        "areas": [],
+        "tags": [
+          "tutorial",
+          "automation"
+        ],
+        "problems": [],
+        "checklist": [],
+        "created_at": "{{TIMESTAMP}}",
+        "updated_at": "{{TIMESTAMP}}",
+        "id": "card-tutorial-18",
+        "title": "Nightly Context Refresh",
+        "description": "You are running a scheduled context refresh. Check if codebase reference files have drifted from reality and update them.\n\n**Steps:**\n1. Load the context-priming skill: `/context-priming`\n2. Run a drift check across all areas. Compare reference files against the actual codebase.\n3. For each area with detected drift:\n   - Note what changed (new files, moved files, renamed functions, changed patterns)\n   - Update the reference file to match reality\n4. Summarise what was updated and what stayed current.\n\n**Keep it lightweight.** Only update references that have actually drifted. Don't rewrite things that are still accurate.",
+        "type": "chore",
+        "priority": "low",
+        "order": 902,
+        "automation": {
+          "enabled": false,
+          "schedule": "0 2 * * *",
+          "scheduleType": "recurring",
+          "provider": "claude",
+          "freshSession": true,
+          "reportViaMessaging": false
+        },
+        "archived": false
+      }
+    ],
+    "design": [
+      {
+        "areas": [],
+        "tags": [
+          "tutorial",
+          "guide"
+        ],
+        "problems": [],
+        "checklist": [],
+        "created_at": "{{TIMESTAMP}}",
+        "updated_at": "{{TIMESTAMP}}",
+        "id": "card-tutorial-5",
+        "title": "Design Stage: Plan Before Build",
+        "description": "Your companion card should be here after Onboard.\n\nNow do:\n1. Run Design Doc on the companion card\n2. Run Feature Spec on the companion card\n3. Check the Design and Feature tabs to see linked docs\n\nThis is the SlyCode pattern: define the work before implementation starts.",
+        "type": "chore",
+        "priority": "low",
+        "order": 10,
+        "design_ref": "documentation/designs/example_welcome_dashboard.md",
+        "feature_ref": "documentation/features/example_in_card_deliverable_feature.md",
+        "agentNotes": [
+          {
+            "id": 1,
+            "agent": "Tutorial",
+            "text": "Notes persist across sessions. Use this tab to leave short context breadcrumbs for future you or another provider.",
+            "timestamp": "{{TIMESTAMP}}"
+          }
+        ]
+      }
+    ],
+    "implementation": [
+      {
+        "areas": [
+          "terminal-actions"
+        ],
+        "tags": [
+          "tutorial",
+          "guide"
+        ],
+        "problems": [
+          {
+            "id": "prob-tutorial-example-1",
+            "description": "Example issue pattern: section order in deliverable was unclear on first pass.",
+            "severity": "minor",
+            "created_at": "{{TIMESTAMP}}",
+            "resolved_at": "{{TIMESTAMP}}"
+          }
+        ],
+        "checklist": [],
+        "created_at": "{{TIMESTAMP}}",
+        "updated_at": "{{TIMESTAMP}}",
+        "id": "card-tutorial-6",
+        "title": "Implementation Stage: Build With Context",
+        "description": "Now run Implement on the companion card.\n\nWhat to pay attention to:\n- The AI uses your card description and linked specs\n- Implement should create/update checklist items for testing\n- Implement should also add a brief summary note\n- You can switch provider if you want to compare style\n- Quick Fix is useful for focused adjustments\n- Checkpoint is your safety snapshot tool\n\nGoal: produce a clear in-card outcome (description + checklist + note) without overengineering.",
+        "type": "chore",
+        "priority": "low",
+        "order": 10
+      }
+    ],
+    "testing": [
+      {
+        "areas": [],
+        "tags": [
+          "tutorial",
+          "guide"
+        ],
+        "problems": [],
+        "checklist": [
+          {
+            "id": "check-tutorial-1",
+            "text": "Companion card has a clear updated description of the delivered outcome",
+            "done": false
+          },
+          {
+            "id": "check-tutorial-2",
+            "text": "Companion card has a practical checklist (3+ items) and relevant items are toggled",
+            "done": false
+          },
+          {
+            "id": "check-tutorial-3",
+            "text": "Companion card has at least one implementation summary note",
+            "done": false
+          },
+          {
+            "id": "check-tutorial-4",
+            "text": "No unresolved problems block approval",
+            "done": false
+          }
+        ],
+        "created_at": "{{TIMESTAMP}}",
+        "updated_at": "{{TIMESTAMP}}",
+        "id": "card-tutorial-7",
+        "title": "Testing Stage: Review and Approve",
+        "description": "Now verify quality before done.\n\nRun on the companion card:\n- Test Review\n- Analyse (if needed)\n- Approve when satisfied\n\nUse checklist/progress as your quality gate, not just intuition.",
+        "type": "chore",
+        "priority": "low",
+        "order": 10
+      }
+    ],
+    "done": [
+      {
+        "areas": [],
+        "tags": [
+          "tutorial",
+          "guide"
+        ],
+        "problems": [],
+        "checklist": [],
+        "created_at": "{{TIMESTAMP}}",
+        "updated_at": "{{TIMESTAMP}}",
+        "id": "card-tutorial-8",
+        "title": "Core Workflow: Operational Pattern",
+        "description": "Scope:\n- This is the default execution pattern for real cards.\n\nSteps:\n- Backlog: run Onboard to clarify title, scope, areas, priority.\n- Design: create/link design doc when requirements are not obvious.\n- Implementation: execute work and add/update card checklist + notes.\n- Testing: run Test Review, resolve issues, then Approve.\n- Done: archive completed cards to keep active lanes clean.",
+        "type": "chore",
+        "priority": "low",
+        "order": 10
+      },
+      {
+        "areas": [],
+        "tags": [
+          "tutorial",
+          "reference"
+        ],
+        "problems": [],
+        "checklist": [],
+        "created_at": "{{TIMESTAMP}}",
+        "updated_at": "{{TIMESTAMP}}",
+        "id": "card-tutorial-9",
+        "title": "Automations: Scheduled Execution",
+        "description": "Automations let cards run AI work on schedule.\n\nThis project includes two example automations (both disabled by default):\n- **Weekly Standup** \u2014 Board summary + archive stale done cards (Mondays 9am)\n- **Nightly Context Refresh** \u2014 Drift-check reference files (2am daily)\n\nUse `sly-kanban automation list` to see them. Enable with `sly-kanban automation enable <card-id>`.\n\n**Ideas for your own automations:**\n- Daily or weekly standup / progress report\n- Nightly context priming refresh to keep AI references current\n- Weekly backlog triage \u2014 flag stale cards\n- Pre-PR code review on the current implementation card\n- Dependency update check \u2014 scan for outdated packages\n- Documentation sync \u2014 regenerate API docs from source\n- End-of-week summary \u2014 what shipped, what's in flight\n- Security scan \u2014 check for known vulnerabilities\n- Test suite runner \u2014 nightly regression pass with report\n- Changelog generator \u2014 summarise recent git history into release notes\n\n**Configuration options:**\n- `--schedule \"0 9 * * 1-5\"` \u2014 Cron syntax (this = 9am weekdays)\n- `--provider claude|codex|gemini` \u2014 Which AI runs it\n- `--freshSession` \u2014 Start clean each run (recommended for automations)\n- `--reportViaMessaging` \u2014 Send results to Telegram when done",
+        "type": "chore",
+        "priority": "low",
+        "order": 20
+      },
+      {
+        "areas": [],
+        "tags": [
+          "tutorial",
+          "reference"
+        ],
+        "problems": [],
+        "checklist": [],
+        "created_at": "{{TIMESTAMP}}",
+        "updated_at": "{{TIMESTAMP}}",
+        "id": "card-tutorial-10",
+        "title": "Actions + Skills + Providers: Configuration Model",
+        "description": "Scope:\n- Actions are lane-aware meta-prompts.\n- Skills/agents provide reusable execution logic.\n- Providers control model/runtime selection.\n\nSteps:\n- Modify actions when you need workflow-level behavior changes.\n- Modify skills when you need broad reusable execution changes.\n- Keep one baseline action unchanged as fallback.\n- Validate changes on a low-risk card before wider use.\n- Document intentional conventions in card notes.",
+        "type": "chore",
+        "priority": "low",
+        "order": 30
+      },
+      {
+        "areas": [],
+        "tags": [
+          "tutorial",
+          "reference"
+        ],
+        "problems": [],
+        "checklist": [],
+        "created_at": "{{TIMESTAMP}}",
+        "updated_at": "{{TIMESTAMP}}",
+        "id": "card-tutorial-11",
+        "title": "Dashboard + Terminals: Project Control",
+        "description": "Scope:\n- Dashboard is the control surface for multi-project operation.\n\nSteps:\n- Switch projects from dashboard before starting new card work.\n- Use card terminal (Terminal tab) for card-scoped execution.\n- Use project terminal for project-scoped execution.\n- Use global terminal for SlyCode/workspace-scoped tasks.\n- Use filters/archive controls to keep active board signal high.",
+        "type": "chore",
+        "priority": "low",
+        "order": 40
+      },
+      {
+        "areas": [],
+        "tags": [
+          "tutorial",
+          "reference"
+        ],
+        "problems": [],
+        "checklist": [],
+        "created_at": "{{TIMESTAMP}}",
+        "updated_at": "{{TIMESTAMP}}",
+        "id": "card-tutorial-13",
+        "title": "Provider Switching: Practical Policy",
+        "description": "Scope:\n- Provider selection is per task and can change during execution.\n\nSteps:\n- Select provider before running each stage action.\n- Use a fast provider for drafting/refinement loops.\n- Use a stronger reasoning provider for design/review/debug.\n- Re-run with a second provider only when comparison adds value.\n- Capture preferred provider patterns in notes for consistency.",
+        "type": "chore",
+        "priority": "low",
+        "order": 50
+      },
+      {
+        "areas": [],
+        "tags": [
+          "tutorial",
+          "reference"
+        ],
+        "problems": [],
+        "checklist": [],
+        "created_at": "{{TIMESTAMP}}",
+        "updated_at": "{{TIMESTAMP}}",
+        "id": "card-tutorial-15",
+        "title": "Messaging + Telegram + Voice: Setup Checklist",
+        "description": "Scope:\n- Optional remote interaction channel; web UI works without this.\n\nSetup steps:\n- Create a Telegram bot with @BotFather.\n- Store the bot token in .env.\n- Start a chat with your bot and capture your chat ID.\n- Store chat ID in .env.\n- For voice: add OpenAI API key (speech-to-text) in .env.\n- For voice output: add ElevenLabs API key (text-to-speech) in .env.\n- Start messaging service.\n- Send a test message and confirm a response.\n- For automation summaries, enable report-via-messaging on the automation card.",
+        "type": "chore",
+        "priority": "low",
+        "order": 55
+      },
+      {
+        "areas": [],
+        "tags": [
+          "tutorial",
+          "cleanup"
+        ],
+        "problems": [],
+        "checklist": [],
+        "created_at": "{{TIMESTAMP}}",
+        "updated_at": "{{TIMESTAMP}}",
+        "id": "card-tutorial-14",
+        "title": "Tutorial Exit: Cleanup Procedure",
+        "description": "Steps:\n- Archive tutorial cards you no longer need.\n- Keep only reference cards you expect to reuse.\n- Create your first real backlog card.\n- If not needed, remove tutorial project from registry/workspace.\n- Verify active lanes now contain only real project work.",
+        "type": "chore",
+        "priority": "low",
+        "order": 60
+      },
+      {
+        "areas": [],
+        "tags": [
+          "tutorial",
+          "reference"
+        ],
+        "problems": [],
+        "checklist": [],
+        "created_at": "{{TIMESTAMP}}",
+        "updated_at": "{{TIMESTAMP}}",
+        "id": "card-tutorial-16",
+        "title": "Telegram Interface: Complete Reference",
+        "description": "Everything available in the SlyCode Telegram bot.\n\n## Persistent Buttons (bottom of chat)\n\nEight quick-access buttons always visible:\n`/switch` `/search` `/provider` `/status` `/voice` `/tone` `/mode` `/sly`\n\n## Commands\n\n| Command | What it does |\n|---------|-------------|\n| /switch | Navigate between global, project, and card terminals. Shows inline buttons for projects, lanes, and cards. |\n| /search | With a query: search cards by title/description. Without: show active sessions and recent cards. |\n| /provider | Switch AI provider (Claude, Codex, Gemini). |\n| /status | Show current target, provider, mode, tone, voice, and session state. |\n| /sly | Show context-aware action buttons (same as the Terminal tab in the web UI). |\n| /global | Jump directly to the global terminal. |\n| /project | Jump from a card terminal to its project terminal. |\n| /voice | Search and select a TTS voice, or `/voice reset` for default. |\n| /tone | Set voice tone preset (casual, professional, short & ominous, excited, deadpan) or `/tone clear`. |\n| /mode | Set response mode: text only, voice only, or both. |\n\n## Navigation (/switch)\n\nDrill-down structure:\n1. **Projects list** \u2014 tap a project to enter it\n2. **Project view** \u2014 see lane buttons with card counts (backlog (3), design (1), etc.) plus a special automations lane\n3. **Lane drilldown** \u2014 see cards in that lane (8 per page, \"More...\" for pagination)\n4. **Card selected** \u2014 messages now go to that card's terminal\n\nNavigation buttons: Global, Projects, Project (back), and Back appear contextually.\n\nBreadcrumb at top shows where you are: `\ud83d\udccd ProjectName \u00b7 stage \u00b7 Card Title`\n\n## Sending Messages\n\n**Text** \u2014 Type normally. Message is forwarded to the active terminal session with a channel header.\n**Voice** \u2014 Send a voice note. It's transcribed via OpenAI Whisper and forwarded as text with a [Telegram/Voice] header.\n**Photos** \u2014 Send images (single or album). They're uploaded to the bridge and inserted as `[Screenshot: path]` references the AI can see.\n**\"stop\"** \u2014 Type the word \"stop\" (exact) to interrupt a running session.\n\n## Card Switching\n\nWhen the AI sends a reply from a different card/session than your current target:\n- A header shows which card it came from: `\ud83d\udccd Project \u00b7 stage \u00b7 Card Title`\n- A **Switch to Card** button lets you jump there with one tap\n\n## Response Modes (/mode)\n\n| Mode | Behaviour |\n|------|-----------|\n| Text | Text replies only |\n| Voice | Audio replies only (TTS via ElevenLabs) |\n| Both | Text first, then a shorter voice summary |\n\n## Voice Features\n\n- **/voice** searches ElevenLabs voices by name and lets you pick one\n- **/tone** sets the style of voice responses (affects delivery, not just words)\n- Voice notes you send are auto-transcribed and forwarded\n- TTS responses are sent as Telegram voice messages (OGG format)\n\n## Sly Actions (/sly)\n\nShows the same action buttons as the Terminal tab in the web UI, filtered by:\n- Current terminal type (global, project, card stage)\n- Session state (startup actions when stopped, toolbar when running)\n- Card type (feature, bug, chore)\n\nTapping an action sends the full templated prompt to the session.\n\n## Session Indicators\n\n- \ud83d\udfe2 Running \u2014 session is actively processing\n- \ud83d\udd35 Detached \u2014 session exists but paused\n- \u26aa Stopped \u2014 no active session\n- Typing indicator appears when the AI is working\n\n## Tips\n\n- From global search, results show project name prefix for cross-project discovery\n- Automation cards appear with \u2699 prefix and in a separate virtual lane\n- Albums (multiple photos) are batched and sent together\n- All state persists across restarts (target, mode, tone, voice, provider)",
+        "type": "chore",
+        "priority": "low",
+        "order": 56
+      },
+      {
+        "areas": [
+          "scripts-deployment",
+          "terminal-actions"
+        ],
+        "tags": [
+          "tutorial",
+          "setup"
+        ],
+        "problems": [],
+        "checklist": [],
+        "created_at": "{{TIMESTAMP}}",
+        "updated_at": "{{TIMESTAMP}}",
+        "id": "card-tutorial-12",
+        "title": "Set Up HTTPS for Remote Access",
+        "description": "# HTTPS Setup Wizard\n\nYou are an interactive setup wizard. Walk the user through enabling HTTPS for SlyCode so that browser features requiring a secure context (voice input, clipboard API, etc.) work when accessing remotely.\n\n**Your job**: detect the environment, ask questions, explain options clearly, execute commands, and verify the result. Be conversational and helpful \u2014 assume the user is not an expert.\n\n---\n\n## IMPORTANT: BEFORE YOU BEGIN\n\n**Display this caution to the user before making any changes:**\n\n```\nHTTPS Setup \u2014 Please Read Before Continuing\n\nThis wizard will make network-level changes to your system.\nThese changes depend on your specific server, OS, and network\nconfiguration and cannot be validated for every environment.\n\nThis is an AI-assisted process. It provides guided suggestions\nbut you are responsible for reviewing and approving each step.\n\n- Keep bypass permissions DISABLED so you can review each command\n- You are responsible for verifying changes are correct for your setup\n- Stop at any point if something looks wrong\n\nPress Enter to continue, or Ctrl+C to exit.\n```\n\n**Wait for acknowledgment before proceeding to Phase 1.**\n\n---\n\n## PHASE 1: ENVIRONMENT DETECTION\n\nRun these checks silently first, then present a summary.\n\n### 1.1 Read SlyCode ports\n\n```bash\n# Get dev port from web/package.json or default\ngrep -E '\"dev\"' web/package.json  # look for the port in the dev script\n# Get prod port from .env\ngrep -E '^WEB_PORT=' .env 2>/dev/null || echo \"WEB_PORT=7591\"\ngrep -E '^BRIDGE_PORT=' .env 2>/dev/null || echo \"BRIDGE_PORT=7592\"\n```\n\nNote the dev web port (usually 3003) and prod web port (usually 7591). The bridge does NOT need HTTPS \u2014 it's accessed via Next.js API proxy (`/api/bridge/[...path]`), not directly by the browser.\n\n### 1.2 Check if already configured\n\n```bash\ngrep -E '^HTTPS_METHOD=' .env 2>/dev/null\ngrep -E '^HTTPS_DEV_URL=' .env 2>/dev/null\ngrep -E '^HTTPS_PROD_URL=' .env 2>/dev/null\n```\n\nIf HTTPS is already configured, tell the user and ask if they want to reconfigure or just verify the setup works.\n\n### 1.3 Check Tailscale\n\n```bash\ncommand -v tailscale && echo \"TAILSCALE_INSTALLED=yes\" || echo \"TAILSCALE_INSTALLED=no\"\ntailscale status --json 2>/dev/null | head -5  # check if running\ntailscale status --self --json 2>/dev/null  # get machine DNS name\ntailscale serve status 2>/dev/null  # existing serve rules\n```\n\n### 1.4 Check other tools\n\n```bash\ncommand -v mkcert && echo \"MKCERT_INSTALLED=yes\" || echo \"MKCERT_INSTALLED=no\"\ncommand -v caddy && echo \"CADDY_INSTALLED=yes\" || echo \"CADDY_INSTALLED=no\"\ncommand -v nginx && echo \"NGINX_INSTALLED=yes\" || echo \"NGINX_INSTALLED=no\"\ncommand -v openssl && echo \"OPENSSL_INSTALLED=yes\" || echo \"OPENSSL_INSTALLED=no\"\n```\n\n### 1.5 Check what's currently listening\n\n```bash\nss -tlnp 2>/dev/null | grep -E ':(443|8443|3003|7591|3443|7443)\\b'\n```\n\n### 1.6 Present summary\n\nSend the user a summary via messaging like:\n\n```\nHTTPS Setup Wizard \u2014 Environment Check\n\nWeb ports:\n  Dev:  3003\n  Prod: 7591\n\nHTTPS status: not configured\n\nAvailable tools:\n  \u2713 Tailscale (your-machine.example.ts.net)\n    Existing serve rules:\n      :443  \u2192 127.0.0.1:8080\n      :8443 \u2192 100.x.y.z:8080\n  \u2717 mkcert (not installed)\n  \u2717 Caddy (not installed)\n  \u2713 openssl\n```\n\n---\n\n## PHASE 2: ASK THE USER WHAT APPROACH THEY WANT\n\nPresent ALL options, explain each one clearly, and recommend based on what's available. Ask the user to choose.\n\n**Message the user:**\n\n```\nHow would you like to set up HTTPS?\n\nBased on your environment, here are your options:\n\n1. Tailscale Serve \u2b50 RECOMMENDED\n   Tailscale acts as a reverse proxy in front of your HTTP ports.\n   It auto-provisions real Let's Encrypt certificates (not self-signed).\n   Zero changes to SlyCode \u2014 your apps stay on plain HTTP.\n   Only accessible to devices on your Tailscale network.\n   Setup: ~2 minutes, 2 commands, persists across reboots.\n\n2. mkcert (locally-trusted certificates)\n   Generates certificates signed by a local CA that your browser trusts.\n   Good if you don't use Tailscale. Requires installing mkcert.\n   Other devices need your root CA installed to avoid browser warnings.\n   You'll need a small HTTPS proxy script in front of Next.js.\n\n3. Caddy reverse proxy\n   Caddy is a web server with automatic HTTPS built in.\n   Can use self-signed certs, Let's Encrypt, or Tailscale certs.\n   Good if you already use Caddy or want a production-grade reverse proxy.\n   Requires installing Caddy.\n\n4. OpenSSL self-signed certificate\n   Generate a self-signed cert with openssl (available on most systems).\n   Browsers will show a security warning \u2014 you have to click through it.\n   Quick and dirty, no extra software needed, but not great UX.\n\n5. Manual / I'll handle it myself\n   I'll just tell you what SlyCode needs (HTTPS on the web port)\n   and you can set it up however you like.\n\nWhich option? (1-5)\n```\n\nIf Tailscale is not installed, still list it but say \"(not detected \u2014 install at https://tailscale.com/download)\" and don't mark it recommended. In that case, recommend mkcert or Caddy.\n\nIf nothing is installed, recommend option 4 (openssl) as the quickest path, or option 2 with mkcert install instructions.\n\n**Wait for the user's response before proceeding.**\n\n---\n\n## PHASE 3: EXECUTE THE CHOSEN PATH\n\n### PATH 1: Tailscale Serve\n\n#### Step 1: Verify Tailscale is running\n\n```bash\ntailscale status --self --json 2>/dev/null\n```\n\nIf not running:\n```\nTailscale doesn't seem to be running. Try:\n  sudo tailscale up\n\nThen let me know when it's connected.\n```\n\nExtract the machine DNS name (e.g., `your-machine.example.ts.net`). Confirm with the user:\n```\nYour Tailscale machine name: your-machine.example.ts.net\nIs this correct?\n```\n\n#### Step 2: Check existing serve rules and pick ports\n\n```bash\ntailscale serve status 2>/dev/null\n```\n\nShow the user what's already configured. Then suggest HTTPS ports that don't conflict:\n\nPort strategy: Use dedicated HTTPS ports offset +3 from the local HTTP ports to avoid conflicts when restarting local services. Default: dev 3003 -> HTTPS 3006, prod 7591 -> HTTPS 7594\n\nTell the user:\n```\nI'll use dedicated HTTPS ports offset from your local service ports.\nThis avoids conflicts when restarting your local services.\n\n  Dev  (3003) -> HTTPS port 3006\n  Prod (7591) -> HTTPS port 7594\n\nThis means you'd access:\n  Dev:  https://[machine-name]:3006\n  Prod: https://[machine-name]:7594\n\nAre these ports OK, or would you prefer different ones?\n```\n\nWait for confirmation. If the user wants different ports, use those instead.\n\n#### Step 3: Apply the configuration\n\nRun both commands:\n\n```bash\ntailscale serve --bg --https 3006 http://127.0.0.1:3003\ntailscale serve --bg --https 7594 http://127.0.0.1:7591\n```\n\nThe `--bg` flag makes the rules persistent across reboots. If either command fails, show the error and troubleshoot:\n- \"permission denied\" \u2192 may need `sudo tailscale serve ...`\n- \"port already in use\" \u2192 pick a different port\n- \"HTTPS not enabled\" \u2192 need to enable HTTPS certs in Tailscale admin console (https://login.tailscale.com/admin/dns \u2014 enable \"HTTPS Certificates\")\n\n#### Step 4: Verify\n\n```bash\ntailscale serve status\n```\n\nConfirm both rules appear. Then tell the user:\n```\nDone! Your HTTPS URLs are:\n  Dev:  https://your-machine.example.ts.net:3006\n  Prod: https://your-machine.example.ts.net:7594\n\nThese persist across reboots. Both rules are active even when only\none service is running \u2014 the other will just show a connection error.\n\nTry opening the dev URL in your browser now to verify.\n```\n\n#### Step 5: Save config to .env\n\nAppend or update these lines in `.env`:\n\n```env\n# \u2500\u2500 HTTPS (configured by setup wizard) \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\nHTTPS_METHOD=tailscale\nHTTPS_DEV_URL=https://your-machine.example.ts.net:3006\nHTTPS_PROD_URL=https://your-machine.example.ts.net:7594\n```\n\nAlso update `web/next.config.ts` `allowedDevOrigins` to include the Tailscale hostname if not already present.\n\nSkip to PHASE 4.\n\n---\n\n### PATH 2: mkcert\n\n#### Step 1: Install mkcert if needed\n\nIf not installed, guide the user:\n\n```\nmkcert is not installed. Here's how to install it:\n\n  macOS:\n    brew install mkcert\n\n  Ubuntu/Debian:\n    sudo apt install mkcert\n    (or: sudo apt install libnss3-tools && brew install mkcert)\n\n  Amazon Linux / RHEL / Fedora:\n    # mkcert isn't in default repos \u2014 install from GitHub release:\n    curl -L -o mkcert https://github.com/FiloSottile/mkcert/releases/latest/download/mkcert-v*-linux-amd64\n    chmod +x mkcert\n    sudo mv mkcert /usr/local/bin/\n\n  After installing, run:\n    mkcert -install\n\n  This creates a local Certificate Authority and installs it in your\n  browser's trust store. You may be prompted for your password.\n\nLet me know when mkcert is installed, or say \"skip\" to try another approach.\n```\n\n#### Step 2: Determine hostnames\n\nAsk the user:\n```\nWhat hostnames or IPs will you use to access SlyCode?\n\nInclude everything you might type in your browser's address bar.\nExamples: localhost, 192.168.1.50, my-server.local\n\nDefault: localhost 127.0.0.1\nYour answer:\n```\n\n#### Step 3: Generate certificates\n\n```bash\nmkdir -p .slycode/certs\ncd .slycode/certs\nmkcert localhost 127.0.0.1 [any additional hostnames from user]\n```\n\nThis creates `localhost+N.pem` and `localhost+N-key.pem`.\n\nRename for clarity:\n```bash\nmv localhost+*.pem server.pem\nmv localhost+*-key.pem server-key.pem\n```\n\n#### Step 4: Create HTTPS proxy script\n\nCreate a small Node.js script that terminates TLS and proxies to the Next.js HTTP server:\n\n```javascript\n// .slycode/https-proxy.js\nconst https = require('https');\nconst httpProxy = require('http-proxy');\nconst fs = require('fs');\nconst path = require('path');\n\nconst HTTPS_PORT = parseInt(process.env.HTTPS_PORT || '3443');\nconst HTTP_PORT = parseInt(process.env.HTTP_PORT || '3003');\nconst CERT_DIR = path.join(__dirname, 'certs');\n\nconst proxy = httpProxy.createProxyServer({\n  target: `http://127.0.0.1:${HTTP_PORT}`,\n  ws: true,\n});\n\nconst server = https.createServer({\n  key: fs.readFileSync(path.join(CERT_DIR, 'server-key.pem')),\n  cert: fs.readFileSync(path.join(CERT_DIR, 'server.pem')),\n}, (req, res) => proxy.web(req, res));\n\nserver.on('upgrade', (req, socket, head) => proxy.ws(req, socket, head));\n\nserver.listen(HTTPS_PORT, () => {\n  console.log(`HTTPS proxy: https://localhost:${HTTPS_PORT} \u2192 http://localhost:${HTTP_PORT}`);\n});\n```\n\nNOTE: This requires `http-proxy` package: `npm install http-proxy --save-dev` in the project root.\n\nAlternatively, a simpler version without http-proxy (using only Node.js built-ins) \u2014 forward requests manually. But http-proxy handles WebSocket upgrade properly, which is important for SSE streams.\n\nTell the user:\n```\nI've created an HTTPS proxy at .slycode/https-proxy.js\n\nStart it alongside your dev server:\n  node .slycode/https-proxy.js &\n  npm run dev\n\nOr for prod:\n  HTTPS_PORT=7443 HTTP_PORT=7591 node .slycode/https-proxy.js &\n  npm start\n\nYour HTTPS URLs:\n  Dev:  https://localhost:3443\n  Prod: https://localhost:7443\n```\n\n#### Step 5: Save config\n\n```env\nHTTPS_METHOD=mkcert\nHTTPS_DEV_URL=https://localhost:3443\nHTTPS_PROD_URL=https://localhost:7443\nHTTPS_CERT=.slycode/certs/server.pem\nHTTPS_KEY=.slycode/certs/server-key.pem\n```\n\n**Important note about other devices**: If the user accesses from another device on the network, that device's browser won't trust the mkcert CA. Tell them:\n```\nOther devices on your network will see a certificate warning.\nTo fix this, copy mkcert's root CA to those devices:\n  mkcert -CAROOT\n  # Copy the rootCA.pem file to the other device and install it\n```\n\nSkip to PHASE 4.\n\n---\n\n### PATH 3: Caddy Reverse Proxy\n\n#### Step 1: Install Caddy if needed\n\n```\nCaddy is not installed. Here's how to install it:\n\n  macOS:\n    brew install caddy\n\n  Ubuntu/Debian:\n    sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https\n    curl -1sLf 'https://dl.cloudkeeper.com/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg\n    curl -1sLf 'https://dl.cloudkeeper.com/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list\n    sudo apt update && sudo apt install caddy\n\n  Amazon Linux / RHEL / Fedora:\n    sudo dnf install 'dnf-command(copr)'\n    sudo dnf copr enable @caddy/caddy\n    sudo dnf install caddy\n\n  Or download from: https://caddyserver.com/download\n\nLet me know when Caddy is installed.\n```\n\n#### Step 2: Determine if Tailscale is available for certs\n\nIf Tailscale is running, Caddy can automatically get Tailscale certificates (no manual cert management at all):\n\n```\nYou have Tailscale running. Caddy can automatically get trusted\ncertificates from Tailscale \u2014 zero certificate management needed.\n\nShould I configure Caddy to use Tailscale certificates? [Y/n]\n```\n\nIf yes, the Caddyfile uses the Tailscale domain. If no, Caddy uses its own internal CA (similar to mkcert but built-in).\n\n#### Step 3: Create Caddyfile\n\n**With Tailscale:**\n```\n# .slycode/Caddyfile\n{\n  auto_https disable_redirects\n}\n\nhttps://your-machine.example.ts.net:3006 {\n  reverse_proxy localhost:3003\n}\n\nhttps://your-machine.example.ts.net:7594 {\n  reverse_proxy localhost:7591\n}\n```\n\n**Without Tailscale (local CA):**\n```\n# .slycode/Caddyfile\n{\n  auto_https disable_redirects\n}\n\nhttps://localhost:3443 {\n  tls internal\n  reverse_proxy localhost:3003\n}\n\nhttps://localhost:7443 {\n  tls internal\n  reverse_proxy localhost:7591\n}\n```\n\n#### Step 4: Start Caddy\n\n```bash\ncaddy start --config .slycode/Caddyfile\n```\n\nFor persistence, either:\n- Add to start scripts\n- Install as systemd service: `caddy run --config .slycode/Caddyfile --adapter caddyfile`\n\n#### Step 5: Save config (same pattern as other paths)\n\nSkip to PHASE 4.\n\n---\n\n### PATH 4: OpenSSL Self-Signed Certificate\n\n#### Step 1: Generate certificate\n\n```bash\nmkdir -p .slycode/certs\nopenssl req -x509 -newkey rsa:2048 -nodes \\\n  -keyout .slycode/certs/server-key.pem \\\n  -out .slycode/certs/server.pem \\\n  -days 365 \\\n  -subj \"/CN=localhost\" \\\n  -addext \"subjectAltName=DNS:localhost,IP:127.0.0.1\"\n```\n\nIf the user needs additional IPs/hostnames, add them to subjectAltName.\n\n#### Step 2: Warn about browser trust\n\n```\n\u26a0\ufe0f  Self-signed certificates are NOT trusted by browsers.\n\nYou'll see a warning like \"Your connection is not private\" every time.\nTo proceed: click \"Advanced\" \u2192 \"Proceed to localhost (unsafe)\".\n\nThis is fine for personal use but annoying. If you want trusted\ncertificates, consider Tailscale Serve or mkcert instead.\n```\n\n#### Step 3: Create the same HTTPS proxy script as Path 2\n\nSame `https-proxy.js` file \u2014 it works with any certificate, not just mkcert.\n\n#### Step 4: Save config\n\n```env\nHTTPS_METHOD=openssl\nHTTPS_DEV_URL=https://localhost:3443\nHTTPS_PROD_URL=https://localhost:7443\nHTTPS_CERT=.slycode/certs/server.pem\nHTTPS_KEY=.slycode/certs/server-key.pem\n```\n\nSkip to PHASE 4.\n\n---\n\n### PATH 5: Manual / DIY\n\nTell the user what SlyCode needs:\n\n```\nHere's what SlyCode needs for HTTPS:\n\n1. Serve the Next.js web app over HTTPS on some port\n   - Dev runs on HTTP port 3003\n   - Prod runs on HTTP port 7591\n   - You can use any reverse proxy (nginx, Caddy, Traefik, etc.)\n   - Or terminate TLS in Node.js with a custom server\n\n2. The browser needs window.isSecureContext === true\n   - This means valid HTTPS, or localhost, or a .localhost domain\n   - Self-signed certs work but show browser warnings\n\n3. Save your HTTPS URLs in .env so the UI can show them:\n   HTTPS_METHOD=manual\n   HTTPS_DEV_URL=https://your-url:port\n   HTTPS_PROD_URL=https://your-url:port\n\n4. If your HTTPS URL is on a different origin than the HTTP one,\n   update web/next.config.ts allowedDevOrigins.\n\nThat's it. Let me know if you need help with any part.\n```\n\nSkip to PHASE 4.\n\n---\n\n## PHASE 4: VERIFICATION\n\nAfter any path completes:\n\n### 4.1 Test the HTTPS URL\n\n```\nLet's verify the setup works.\n\nIs your dev server running? (npm run dev in the web/ directory)\nIf not, start it and let me know.\n```\n\nOnce confirmed running, ask the user to open the HTTPS URL in their browser.\n\n```\nOpen this URL in your browser:\n  https://your-machine.example.ts.net:3006\n\nTell me what you see:\n  a) SlyCode loads normally\n  b) Browser shows a certificate warning\n  c) Connection refused / can't connect\n  d) Something else\n```\n\n**Troubleshoot based on response:**\n\n**(a) Success** \u2192 proceed to voice test\n\n**(b) Certificate warning:**\n- If self-signed (path 4): expected, click through it\n- If mkcert: `mkcert -install` may not have run, or accessing from a different device\n- If Tailscale: should not happen with real LE certs \u2014 check `tailscale cert` status\n\n**(c) Connection refused:**\n- Is the dev server running? `ss -tlnp | grep 3003`\n- Is the tailscale serve rule active? `tailscale serve status`\n- Firewall blocking? `sudo iptables -L -n | grep [port]`\n- Wrong port? Double-check the URL\n\n**(d) Something else** \u2192 ask for details, troubleshoot accordingly\n\n### 4.2 Test voice input\n\n```\nNow let's test voice input:\n\n1. Open the HTTPS URL in your browser\n2. Click on a terminal or input field\n3. Look at the microphone button \u2014 does it show a warning icon?\n   - If yes: something is still wrong with the secure context\n   - If no warning: good!\n4. Try recording a voice message\n\nDid it work?\n```\n\n### 4.3 Confirm and summarize\n\n```\nHTTPS setup complete! Here's your configuration:\n\n  Method:   Tailscale Serve\n  Dev URL:  https://your-machine.example.ts.net:3006\n  Prod URL: https://your-machine.example.ts.net:7594\n  Persists: yes (across reboots)\n\n  Config saved to .env\n\nUseful commands:\n  tailscale serve status          # Check serve rules\n  slycode https status            # Check HTTPS config (once implemented)\n\nBookmark your HTTPS URLs \u2014 use them instead of the HTTP ones\nwhen accessing remotely.\n```\n\n---\n\n## NOTES FOR THE AGENT\n\n- Always use the messaging skill to communicate with the user (don't just write to stdout)\n- **Never proceed with commands without explicit user confirmation** \u2014 a casual \"yes\" may be acknowledgment, not authorization\n- Wait for user responses at each decision point \u2014 don't assume\n- If anything fails, explain clearly and offer alternatives\n- The .env file may not have the HTTPS section yet \u2014 append it, don't overwrite existing content\n- The bridge port does NOT need HTTPS \u2014 only the web port\n- For Tailscale: Do NOT use the same port for HTTPS as the local HTTP service \u2014 it causes conflicts when restarting the local service. Use offset ports: dev 3003 -> 3006, prod 7591 -> 7594\n- For Tailscale: `tailscale serve` uses any port (not limited to 443/8443/10000 \u2014 that's Funnel only)\n- For Tailscale: `--bg` makes rules persistent across reboots\n- For Tailscale: existing serve rules on other ports are NOT affected\n- The user may already have services on common ports (443, 8443) \u2014 always check first\n- `tailscale serve status` shows current rules \u2014 parse this before suggesting ports\n\n---\n\n## PHASE 5: AUDIT TRAIL (MANDATORY)\n\nAfter completing setup (or if the user abandons partway through), you MUST add agent notes to this card documenting everything. This is non-negotiable \u2014 the notes are the user's permanent record of what was done and how to undo it.\n\n### 5.1 Decision Log Note\n\nAdd a note titled with the date and time summarizing:\n- What environment was detected (OS, Tailscale yes/no, tools available)\n- Which approach the user chose and why\n- What ports were selected\n- What URLs were configured\n- What files were created or modified\n- Whether verification passed or failed\n\nExample:\n```\nHTTPS Setup \u2014 2026-02-24 10:30AM\n\nEnvironment: Amazon Linux, Tailscale detected (your-machine.example.ts.net)\nExisting serve rules: :443 \u2192 18789, :8443 \u2192 8080\nChosen method: Tailscale Serve\nPorts: dev 3003 \u2192 HTTPS 3006, prod 7591 \u2192 HTTPS 7594\nURLs:\n  Dev:  https://your-machine.example.ts.net:3006\n  Prod: https://your-machine.example.ts.net:7594\n\nChanges made:\n  1. Ran: tailscale serve --bg --https 3006 http://127.0.0.1:3003\n  2. Ran: tailscale serve --bg --https 7594 http://127.0.0.1:7591\n  3. Appended HTTPS config to .env (HTTPS_METHOD, HTTPS_DEV_URL, HTTPS_PROD_URL)\n  4. Added Tailscale hostname to web/next.config.ts allowedDevOrigins\n\nVerification: PASSED \u2014 SlyCode loaded over HTTPS, voice input working.\n```\n\n### 5.2 Undo/Reversal Note\n\nAdd a SEPARATE note with complete step-by-step reversal instructions. This must be specific to what was actually done \u2014 not generic. The user should be able to follow these instructions months later to completely remove everything.\n\nExample for Tailscale path:\n```\nHTTPS Undo Instructions \u2014 2026-02-24\n\nTo completely reverse the HTTPS setup:\n\n1. Remove Tailscale serve rules:\n   tailscale serve --https=3006 off\n   tailscale serve --https=7594 off\n   Verify removed: tailscale serve status\n\n2. Remove HTTPS config from .env:\n   Delete these lines from .env:\n     HTTPS_METHOD=tailscale\n     HTTPS_DEV_URL=https://your-machine.example.ts.net:3006\n     HTTPS_PROD_URL=https://your-machine.example.ts.net:7594\n\n3. Remove Tailscale hostname from web/next.config.ts:\n   Remove 'your-machine.example.ts.net' from allowedDevOrigins\n   (only if it wasn't there before setup)\n\nAfter undo, access SlyCode via HTTP as before.\nVoice input will only work on localhost.\n```\n\nExample for mkcert path:\n```\nHTTPS Undo Instructions \u2014 2026-02-24\n\nTo completely reverse the HTTPS setup:\n\n1. Stop the HTTPS proxy if running:\n   pkill -f 'https-proxy.js' or kill the process\n\n2. Remove generated files:\n   rm -rf .slycode/certs/\n   rm .slycode/https-proxy.js\n\n3. Remove http-proxy dependency (if installed):\n   npm uninstall http-proxy\n\n4. Remove HTTPS config from .env:\n   Delete lines: HTTPS_METHOD, HTTPS_DEV_URL, HTTPS_PROD_URL, HTTPS_CERT, HTTPS_KEY\n\n5. Optionally uninstall mkcert CA:\n   mkcert -uninstall\n```\n\nExample for Caddy path:\n```\nHTTPS Undo Instructions \u2014 2026-02-24\n\nTo completely reverse the HTTPS setup:\n\n1. Stop Caddy:\n   caddy stop\n   (or: systemctl --user stop caddy if installed as service)\n\n2. Remove Caddyfile:\n   rm .slycode/Caddyfile\n\n3. Remove HTTPS config from .env:\n   Delete lines: HTTPS_METHOD, HTTPS_DEV_URL, HTTPS_PROD_URL\n\n4. If Caddy was installed just for this, optionally uninstall it.\n```\n\n### 5.3 Tell the User About the Notes\n\nAt the end of the setup, tell the user:\n```\nI've saved two notes on this card:\n  1. A log of everything that was decided and configured\n  2. Step-by-step instructions to completely undo the setup\n\nIf you ever need to reverse this or remember what was done,\njust look at the notes on this card:\n  sly-kanban show [this-card-id]\n\nThe notes have the exact commands to remove everything.\n```\n\nThis ensures full traceability and reversibility for every HTTPS setup performed through this wizard.",
+        "type": "chore",
+        "priority": "medium",
+        "order": 57
+      }
+    ]
+  },
+  "last_updated": "{{TIMESTAMP}}",
+  "lastUpdated": "{{TIMESTAMP}}"
+}