changes

.config/hypr/hyprlock.conf

@@ -1,4 +1,8 @@
 # Hyprlock config with Catppuccin Mocha theme
+general {
+    grace = 0
+    no_input_trim = false
+}
 
 # Background
 background {
@@ -42,6 +46,7 @@ label {
 
 # Password input
 input-field {
+    ignore_empty_input = false
     monitor =
     size = 300, 50
     outline_thickness = 2
@@ -49,21 +54,21 @@ input-field {
     dots_spacing = 0.15
     dots_center = true
     dots_rounding = 2
-    outer_color = rgba(180, 190, 254, 1.0)  # Lavender
-    inner_color = rgba(49, 50, 68, 1.0)     # Surface0
-    font_color = rgba(205, 214, 244, 1.0)   # Text
+    outer_color = rgba(180, 190, 254, 1.0)
+    inner_color = rgba(49, 50, 68, 1.0)
+    font_color = rgba(205, 214, 244, 1.0)
     fade_on_empty = false
-    placeholder_text = <i>Enter password...</i>
+    placeholder_text = <i>Touch YubiKey or enter password...</i>
     hide_input = false
-    check_color = rgba(166, 227, 161, 1.0)  # Green
-    fail_color = rgba(243, 139, 168, 1.0)   # Red
+    check_color = rgba(166, 227, 161, 1.0)
+    fail_color = rgba(243, 139, 168, 1.0)
     fail_text = <i>$FAIL <b>($ATTEMPTS)</b></i>
-    capslock_color = rgba(249, 226, 175, 1.0)  # Yellow
+    fail_timeout = 3000
+    capslock_color = rgba(249, 226, 175, 1.0)
     position = 0, -80
     halign = center
     valign = center
 }
-
 # Lock icon
 label {
     monitor =

.config/nvim/lazy-lock.json

@@ -1,5 +1,6 @@
 {
   "LuaSnip": { "branch": "master", "commit": "dae4f5aaa3574bd0c2b9dd20fb9542a02c10471c" },
+  "blink.cmp": { "branch": "main", "commit": "f22f66eb7c4d037ed523a78b27ee235b7bc9a1f4" },
   "catppuccin": { "branch": "main", "commit": "12c004cde3f36cb1d57242f1e6aac46b09a0e5b4" },
   "cmp-buffer": { "branch": "main", "commit": "b74fab3656eea9de20a9b8116afa3cfc4ec09657" },
   "cmp-nvim-lsp": { "branch": "main", "commit": "cbc7b02bb99fae35cb42f514762b89b5126651ef" },
@@ -19,6 +20,8 @@
   "nvim-treesitter": { "branch": "main", "commit": "5cb05e1b0fa3c469958a2b26f36b3fe930af221c" },
   "opencode.nvim": { "branch": "main", "commit": "1088ee70dd997d785a1757d351c07407f0abfc9f" },
   "plenary.nvim": { "branch": "master", "commit": "b9fd5226c2f76c951fc8ed5923d85e4de065e509" },
+  "render-markdown.nvim": { "branch": "main", "commit": "e3c18ddd27a853f85a6f513a864cf4f2982b9f26" },
+  "snacks.nvim": { "branch": "main", "commit": "9912042fc8bca2209105526ac7534e9a0c2071b2" },
   "telescope-fzf-native.nvim": { "branch": "main", "commit": "6fea601bd2b694c6f2ae08a6c6fab14930c60e2c" },
   "telescope.nvim": { "branch": "master", "commit": "3333a52ff548ba0a68af6d8da1e54f9cd96e9179" }
 }

.config/opencode/AGENTS.md

@@ -16,7 +16,7 @@
 | `planner` | primary | `github-copilot/gpt-5.4` | Produce approved specs and decide whether execution is ready |
 | `builder` | primary | `github-copilot/gpt-5.4` | Execute approved specs and integrate delegated work |
 | `researcher` | subagent | `github-copilot/gpt-5.4` | Deep research, external docs, tradeoff analysis |
-| `explorer` | subagent | `github-copilot/claude-sonner-4.6` | Fast read-only repo inspection and fact gathering |
+| `explorer` | subagent | `github-copilot/claude-sonnet-4.6` | Read-only repo inspection; reports facts only, never plans or recommendations |
 | `reviewer` | subagent | `github-copilot/claude-opus-4.6` | Critique plans, code, tests, and release readiness |
 | `coder` | subagent | `github-copilot/gpt-5.3-codex` | Implement narrowly scoped code changes |
 | `tester` | subagent | `github-copilot/gpt-5.4` | Run verification, triage failures, capture evidence |
@@ -34,6 +34,15 @@
 - `builder` must follow the approved plan exactly.
 - `builder` must stop and escalate back to `planner` when it finds a spec contradiction, a hidden dependency that changes scope, or two failed verification attempts after recording root cause and evidence.
 
+### Builder Commits
+
+- `builder` automatically creates git commits at meaningful task checkpoints and at final completion when uncommitted changes remain.
+- A "meaningful checkpoint" is a completed implementation chunk from the approved plan, not every file save.
+- Skip commit creation when there are no new changes since the prior checkpoint.
+- Commit messages should reflect the intent of the completed task from the plan.
+- Standard git safety rules apply: review staged content, respect hooks, no force-push or destructive operations.
+- Push automation is out of scope; the user decides when to push.
+
 ## Commands
 
 - `/init` initializes or refreshes repo memory and the project `AGENTS.md`.
@@ -99,6 +108,12 @@ Local skills live under `skills/<name>/SKILL.md` and are loaded on demand via th
 | `dispatching-parallel-agents` | Safe parallelization with strict isolation tests and a single integrator |
 | `test-driven-development` | Canonical red-green-refactor workflow for code changes |
 
+### Design & Domain Skills
+
+| Skill | Purpose |
+| --- | --- |
+| `frontend-design` | Distinctive, production-grade frontend UI with high design quality, accessibility, and performance |
+
 ### Ecosystem Skills
 
 | Skill | Purpose |
@@ -111,11 +126,11 @@ Local skills live under `skills/<name>/SKILL.md` and are loaded on demand via th
 
 Agents must proactively load applicable skills when their trigger conditions are met. Do not wait to be told.
 
-- **`planner`**: `brainstorming` (unclear requests, design work), `writing-plans` (authoring `plans/<slug>`), `dispatching-parallel-agents` (parallel lanes), `systematic-debugging` (unresolved bugs), `test-driven-development` (specifying code tasks), `docker-container-management` (repo uses Docker), `python-development` (Python repo/lane), `javascript-typescript-development` (JS/TS repo/lane).
-- **`builder`**: `dispatching-parallel-agents` (before parallel fan-out), `systematic-debugging` (bugs, regressions, flaky tests), `verification-before-completion` (before any completion claim), `test-driven-development` (before delegating or performing code changes), `docker-container-management` (containerized repo), `python-development` (Python lanes), `javascript-typescript-development` (JS/TS lanes).
+- **`planner`**: `brainstorming` (unclear requests, design work), `writing-plans` (authoring `plans/<slug>`), `dispatching-parallel-agents` (parallel lanes), `systematic-debugging` (unresolved bugs), `test-driven-development` (specifying code tasks), `frontend-design` (frontend UI/UX implementation or redesign), `docker-container-management` (repo uses Docker), `python-development` (Python repo/lane), `javascript-typescript-development` (JS/TS repo/lane).
+- **`builder`**: `dispatching-parallel-agents` (before parallel fan-out), `systematic-debugging` (bugs, regressions, flaky tests), `verification-before-completion` (before any completion claim), `test-driven-development` (before delegating or performing code changes), `frontend-design` (frontend UI/UX implementation lanes), `docker-container-management` (containerized repo), `python-development` (Python lanes), `javascript-typescript-development` (JS/TS lanes).
 - **`tester`**: `systematic-debugging` (verification failure diagnosis), `verification-before-completion` (before declaring verification complete), `test-driven-development` (validating red/green cycles), `docker-container-management` (tests run in containers), `python-development` (Python verification), `javascript-typescript-development` (JS/TS verification).
 - **`reviewer`**: `verification-before-completion` (evaluating completion evidence), `test-driven-development` (reviewing red/green discipline).
-- **`coder`**: `test-driven-development` (all code tasks), `docker-container-management` (Dockerfiles, compose files, containerized builds), `python-development` (Python code lanes), `javascript-typescript-development` (JS/TS code lanes); other skills when the assigned lane explicitly calls for them.
+- **`coder`**: `test-driven-development` (all code tasks), `frontend-design` (frontend component, page, or application implementation lanes), `docker-container-management` (Dockerfiles, compose files, containerized builds), `python-development` (Python code lanes), `javascript-typescript-development` (JS/TS code lanes); other skills when the assigned lane explicitly calls for them.
 - **`librarian`**: Load relevant skills opportunistically when the assigned task calls for them; do not override planner/builder workflow ownership.
 
 ### TDD Default Policy

.config/opencode/agents/builder.md

@@ -29,6 +29,7 @@ You are the execution authority.
   - `test-driven-development` before delegating or performing code changes.
   - `docker-container-management` when executing tasks in a containerized repo.
   - `python-development` when executing Python lanes.
+  - `frontend-design` when executing frontend UI/UX implementation lanes.
   - `javascript-typescript-development` when executing JS/TS lanes.
 
 - Read the latest approved plan before making changes.
@@ -37,4 +38,7 @@ You are the execution authority.
 - Use parallel subagents when implementation lanes are isolated and can be verified independently.
 - Maintain an execution log in basic-memory under `executions/<slug>` with `Status: in_progress|blocked|done`.
 - If you hit a contradiction, hidden dependency, or two failed verification attempts, record the root cause and evidence, then stop and send the work back to `planner`.
-- Do not create commits unless the user explicitly asks.
+- Builder owns commit creation during `/build`; do not delegate commit authorship decisions to other agents.
+- Create commits automatically at meaningful completed implementation checkpoints, and create a final completion commit when changes remain.
+- Reuse existing git safety constraints: avoid destructive git behavior, do not force push, and do not add push automation.
+- If there are no new changes at a checkpoint, skip commit creation instead of creating empty or duplicate commits.

.config/opencode/agents/coder.md

@@ -16,6 +16,7 @@ Implement only the assigned lane.
 - Proactively load `test-driven-development` for code development tasks.
 - Load `docker-container-management` when the lane involves Dockerfiles, compose files, or containerized builds.
 - Load `python-development` when the lane involves Python code.
+- Load `frontend-design` when the lane involves frontend component, page, or application implementation.
 - Load `javascript-typescript-development` when the lane involves JS/TS code.
 - Load other local skills only when the assigned lane explicitly calls for them.
 

.config/opencode/agents/explorer.md

@@ -1,5 +1,5 @@
 ---
-description: Fast read-only repo explorer for locating files, symbols, patterns, and local facts
+description: Read-only repo inspector that reports observable facts only — never plans or recommendations
 mode: subagent
 model: github-copilot/claude-sonnet-4.6
 temperature: 0.0
@@ -12,9 +12,17 @@ permission:
 permalink: opencode-config/agents/explorer
 ---
 
-Focus on local discovery.
+You are a fact-gathering tool, not a planner.
 
-- Inspect the repository quickly and report only the relevant facts.
+- Inspect the repository quickly and report only observable facts.
 - Prefer `glob`, `grep`, `read`, structural search, and memory lookups.
-- Return file paths, symbols, and constraints with minimal speculation.
+- Return file paths, symbols, code relationships, and constraints.
 - Do not make changes.
+
+Forbidden output:
+- Plan drafts, task lists, or implementation steps.
+- Solution design or architecture proposals.
+- Speculative recommendations or subjective assessments.
+- Priority rankings or suggested next actions.
+
+If a finding has implications for planning, state the fact and stop. Let the caller draw conclusions.

.config/opencode/agents/planner.md

@@ -29,6 +29,7 @@ You are the planning authority.
   - `test-driven-development` when specifying implementation tasks that mutate code.
   - `docker-container-management` when a repo uses Docker/docker-compose.
   - `python-development` when a repo or lane is primarily Python.
+  - `frontend-design` when the task involves frontend UI/UX implementation or redesign.
   - `javascript-typescript-development` when a repo or lane is primarily JS/TS.
 
 ## Clarification and the `question` tool

.config/opencode/commands/build.md

@@ -9,7 +9,10 @@ Execute the latest approved plan for: $ARGUMENTS
 1. Read the latest matching `plans/<slug>` note with `Status: approved`.
 2. Create or update `executions/<slug>` with `Status: in_progress` before changing code.
 3. Delegate implementation to `coder`, verification to `tester`, review to `reviewer`, and docs or memory updates to `librarian` where appropriate.
-4. Follow the plan exactly. If the plan is contradictory, missing a dependency, or fails verification twice, stop, capture evidence, set the execution note to blocked, and send the work back to `planner`.
-5. Finish by updating the execution note to `Status: done` or `Status: blocked` and summarizing what changed.
+4. Builder owns commit creation during `/build`: create automatic commits at meaningful completed implementation checkpoints.
+5. Reuse existing git safety rules and avoid destructive git behavior; do not add push automation.
+6. If no new changes exist at a checkpoint, skip commit creation rather than creating empty or duplicate commits.
+7. Follow the plan exactly. If the plan is contradictory, missing a dependency, or fails verification twice, stop, capture evidence, set the execution note to blocked, and send the work back to `planner`.
+8. Finish by creating a final completion commit when changes remain, then update the execution note to `Status: done` or `Status: blocked` and summarize what changed.
 
-Do not create a commit unless the user explicitly asks.
+Automatic commits are required during `/build` as defined above.

.config/opencode/skills/frontend-design/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: frontend-design
+description: Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, or applications. Generates creative, polished code that avoids generic AI aesthetics.
+permalink: opencode-config/skills/frontend-design/skill
+---
+
+# Frontend Design
+
+## When to Load
+
+Load this skill when the task involves building, redesigning, or significantly styling a frontend component, page, or application. Triggers include: user requests for UI/UX implementation, wireframe-to-code work, visual redesigns, and new web interfaces.
+
+## Design Thinking Checklist
+
+Before writing code, answer these:
+
+1. **Purpose** — What problem does this interface solve? Who is the audience?
+2. **Brand / product context** — Does the project have existing design tokens, a style guide, or brand constraints? Follow them first; extend only where gaps exist.
+3. **Aesthetic direction** — Commit to a clear direction (e.g., brutally minimal, maximalist, retro-futuristic, editorial, organic, luxury, playful, industrial). Intentionality matters more than intensity.
+4. **Differentiation** — Identify the single most memorable element of the design.
+5. **Constraints** — Note framework requirements, performance budgets, and accessibility targets (WCAG AA minimum).
+
+## Implementation Checklist
+
+- [ ] Produce production-grade, functional code (HTML/CSS/JS, React, Vue, etc.)
+- [ ] Ensure the result is visually cohesive with a clear aesthetic point of view
+- [ ] Respect accessibility: semantic HTML, sufficient contrast, keyboard navigation, focus management
+- [ ] Respect performance: avoid heavy unoptimized assets; prefer CSS-only solutions for animation where practical
+- [ ] Use CSS variables for color/theme consistency
+- [ ] Match implementation complexity to the aesthetic vision — maximalist designs need elaborate effects; minimal designs need precision and restraint
+
+## Aesthetic Guidance
+
+- **Typography** — Choose distinctive, characterful fonts. Pair a display font with a refined body font. Avoid defaulting to the same choices across projects; vary intentionally.
+- **Color & Theme** — Dominant colors with sharp accents outperform timid, evenly-distributed palettes. Vary between light and dark themes across projects.
+- **Motion** — Prioritize high-impact moments: a well-orchestrated page load with staggered reveals creates more delight than scattered micro-interactions. Use CSS animations where possible; use a motion library (e.g., Motion) for complex sequences. Include scroll-triggered and hover effects when they serve the design.
+- **Spatial Composition** — Explore asymmetry, overlap, diagonal flow, grid-breaking elements, generous negative space, or controlled density.
+- **Backgrounds & Atmosphere** — Build depth with gradient meshes, noise textures, geometric patterns, layered transparencies, shadows, grain overlays, or other contextual effects rather than defaulting to flat solid colors.
+
+Avoid converging on the same fonts, color schemes, or layout patterns across generations. Each design should feel context-specific and intentional.
+
+## TDD & Verification
+
+Frontend code changes follow the project's TDD default policy. When the skill is loaded alongside `test-driven-development`:
+
+- Write or update component/visual tests before implementation when a test harness exists.
+- If no frontend test harness is available, state the exception and describe alternative verification (e.g., manual browser check, screenshot comparison).
+- Satisfy `verification-before-completion` requirements before claiming the work is done.

.config/opencode/skills/using-superpowers/SKILL.md

@@ -0,0 +1,115 @@
+---
+name: using-superpowers
+description: Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions
+---
+
+<SUBAGENT-STOP>
+If you were dispatched as a subagent to execute a specific task, skip this skill.
+</SUBAGENT-STOP>
+
+<EXTREMELY-IMPORTANT>
+If you think there is even a 1% chance a skill might apply to what you are doing, you ABSOLUTELY MUST invoke the skill.
+
+IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.
+
+This is not negotiable. This is not optional. You cannot rationalize your way out of this.
+</EXTREMELY-IMPORTANT>
+
+## Instruction Priority
+
+Superpowers skills override default system prompt behavior, but **user instructions always take precedence**:
+
+1. **User's explicit instructions** (CLAUDE.md, GEMINI.md, AGENTS.md, direct requests) — highest priority
+2. **Superpowers skills** — override default system behavior where they conflict
+3. **Default system prompt** — lowest priority
+
+If CLAUDE.md, GEMINI.md, or AGENTS.md says "don't use TDD" and a skill says "always use TDD," follow the user's instructions. The user is in control.
+
+## How to Access Skills
+
+**In Claude Code:** Use the `Skill` tool. When you invoke a skill, its content is loaded and presented to you—follow it directly. Never use the Read tool on skill files.
+
+**In Gemini CLI:** Skills activate via the `activate_skill` tool. Gemini loads skill metadata at session start and activates the full content on demand.
+
+**In other environments:** Check your platform's documentation for how skills are loaded.
+
+## Platform Adaptation
+
+Skills use Claude Code tool names. Non-CC platforms: see `references/codex-tools.md` (Codex) for tool equivalents. Gemini CLI users get the tool mapping loaded automatically via GEMINI.md.
+
+# Using Skills
+
+## The Rule
+
+**Invoke relevant or requested skills BEFORE any response or action.** Even a 1% chance a skill might apply means that you should invoke the skill to check. If an invoked skill turns out to be wrong for the situation, you don't need to use it.
+
+```dot
+digraph skill_flow {
+    "User message received" [shape=doublecircle];
+    "About to EnterPlanMode?" [shape=doublecircle];
+    "Already brainstormed?" [shape=diamond];
+    "Invoke brainstorming skill" [shape=box];
+    "Might any skill apply?" [shape=diamond];
+    "Invoke Skill tool" [shape=box];
+    "Announce: 'Using [skill] to [purpose]'" [shape=box];
+    "Has checklist?" [shape=diamond];
+    "Create TodoWrite todo per item" [shape=box];
+    "Follow skill exactly" [shape=box];
+    "Respond (including clarifications)" [shape=doublecircle];
+
+    "About to EnterPlanMode?" -> "Already brainstormed?";
+    "Already brainstormed?" -> "Invoke brainstorming skill" [label="no"];
+    "Already brainstormed?" -> "Might any skill apply?" [label="yes"];
+    "Invoke brainstorming skill" -> "Might any skill apply?";
+
+    "User message received" -> "Might any skill apply?";
+    "Might any skill apply?" -> "Invoke Skill tool" [label="yes, even 1%"];
+    "Might any skill apply?" -> "Respond (including clarifications)" [label="definitely not"];
+    "Invoke Skill tool" -> "Announce: 'Using [skill] to [purpose]'";
+    "Announce: 'Using [skill] to [purpose]'" -> "Has checklist?";
+    "Has checklist?" -> "Create TodoWrite todo per item" [label="yes"];
+    "Has checklist?" -> "Follow skill exactly" [label="no"];
+    "Create TodoWrite todo per item" -> "Follow skill exactly";
+}
+```
+
+## Red Flags
+
+These thoughts mean STOP—you're rationalizing:
+
+| Thought | Reality |
+|---------|---------|
+| "This is just a simple question" | Questions are tasks. Check for skills. |
+| "I need more context first" | Skill check comes BEFORE clarifying questions. |
+| "Let me explore the codebase first" | Skills tell you HOW to explore. Check first. |
+| "I can check git/files quickly" | Files lack conversation context. Check for skills. |
+| "Let me gather information first" | Skills tell you HOW to gather information. |
+| "This doesn't need a formal skill" | If a skill exists, use it. |
+| "I remember this skill" | Skills evolve. Read current version. |
+| "This doesn't count as a task" | Action = task. Check for skills. |
+| "The skill is overkill" | Simple things become complex. Use it. |
+| "I'll just do this one thing first" | Check BEFORE doing anything. |
+| "This feels productive" | Undisciplined action wastes time. Skills prevent this. |
+| "I know what that means" | Knowing the concept ≠ using the skill. Invoke it. |
+
+## Skill Priority
+
+When multiple skills could apply, use this order:
+
+1. **Process skills first** (brainstorming, debugging) - these determine HOW to approach the task
+2. **Implementation skills second** (frontend-design, mcp-builder) - these guide execution
+
+"Let's build X" → brainstorming first, then implementation skills.
+"Fix this bug" → debugging first, then domain-specific skills.
+
+## Skill Types
+
+**Rigid** (TDD, debugging): Follow exactly. Don't adapt away discipline.
+
+**Flexible** (patterns): Adapt principles to context.
+
+The skill itself tells you which.
+
+## User Instructions
+
+Instructions say WHAT, not HOW. "Add X" or "Fix Y" doesn't mean skip workflows.

.config/opencode/skills/using-superpowers/references/codex-tools.md

@@ -0,0 +1,25 @@
+# Codex Tool Mapping
+
+Skills use Claude Code tool names. When you encounter these in a skill, use your platform equivalent:
+
+| Skill references | Codex equivalent |
+|-----------------|------------------|
+| `Task` tool (dispatch subagent) | `spawn_agent` |
+| Multiple `Task` calls (parallel) | Multiple `spawn_agent` calls |
+| Task returns result | `wait` |
+| Task completes automatically | `close_agent` to free slot |
+| `TodoWrite` (task tracking) | `update_plan` |
+| `Skill` tool (invoke a skill) | Skills load natively — just follow the instructions |
+| `Read`, `Write`, `Edit` (files) | Use your native file tools |
+| `Bash` (run commands) | Use your native shell tools |
+
+## Subagent dispatch requires collab
+
+Add to your Codex config (`~/.codex/config.toml`):
+
+```toml
+[features]
+collab = true
+```
+
+This enables `spawn_agent`, `wait`, and `close_agent` for skills like `dispatching-parallel-agents` and `subagent-driven-development`.

.config/opencode/skills/using-superpowers/references/gemini-tools.md

@@ -0,0 +1,33 @@
+# Gemini CLI Tool Mapping
+
+Skills use Claude Code tool names. When you encounter these in a skill, use your platform equivalent:
+
+| Skill references | Gemini CLI equivalent |
+|-----------------|----------------------|
+| `Read` (file reading) | `read_file` |
+| `Write` (file creation) | `write_file` |
+| `Edit` (file editing) | `replace` |
+| `Bash` (run commands) | `run_shell_command` |
+| `Grep` (search file content) | `grep_search` |
+| `Glob` (search files by name) | `glob` |
+| `TodoWrite` (task tracking) | `write_todos` |
+| `Skill` tool (invoke a skill) | `activate_skill` |
+| `WebSearch` | `google_web_search` |
+| `WebFetch` | `web_fetch` |
+| `Task` tool (dispatch subagent) | No equivalent — Gemini CLI does not support subagents |
+
+## No subagent support
+
+Gemini CLI has no equivalent to Claude Code's `Task` tool. Skills that rely on subagent dispatch (`subagent-driven-development`, `dispatching-parallel-agents`) will fall back to single-session execution via `executing-plans`.
+
+## Additional Gemini CLI tools
+
+These tools are available in Gemini CLI but have no Claude Code equivalent:
+
+| Tool | Purpose |
+|------|---------|
+| `list_directory` | List files and subdirectories |
+| `save_memory` | Persist facts to GEMINI.md across sessions |
+| `ask_user` | Request structured input from the user |
+| `tracker_create_task` | Rich task management (create, update, list, visualize) |
+| `enter_plan_mode` / `exit_plan_mode` | Switch to read-only research mode before making changes |