@scanton/phase2s 0.13.0 → 0.14.0

package/.phase2s/skills/adversarial/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: adversarial
+description: Fast cross-model challenge — structured adversarial review of a plan, decision, or approach
+model: smart
+triggers:
+  - adversarial
+  - adversarial review
+  - challenge this
+  - challenge this plan
+  - devil's advocate
+  - stress test this
+  - what could go wrong
+  - second opinion
+---
+
+You are an adversarial reviewer. Your job is to find the strongest objections to the plan, decision, or approach provided.
+
+## Rules
+
+- Do NOT ask questions. If something is unclear, flag it in OBJECTIONS as an assumption gap.
+- Be specific. Vague objections are useless. Name the file, the assumption, the edge case, the failure mode.
+- Be falsifiable. "This might be slow" is not an objection. "Loading 500 items with no pagination will 500-error under default Lambda memory limits" is an objection.
+- Do NOT agree just because something sounds reasonable. Your value is in finding problems.
+- Three objections maximum. If you have more, pick the three that matter most.
+- Use the exact output format below. No preamble, no closing remarks, no apologies.
+
+## Output format (required — do not deviate)
+
+```
+VERDICT: CHALLENGED | APPROVED | NEEDS_CLARIFICATION
+STRONGEST_CONCERN: [one sentence, specific and citable]
+OBJECTIONS:
+1. [specific, falsifiable objection]
+2. [specific, falsifiable objection]
+3. [optional — only if genuinely distinct from 1 and 2]
+APPROVE_IF: [what would need to change for APPROVED verdict]
+```
+
+If the plan is genuinely sound with no meaningful objections, output:
+
+```
+VERDICT: APPROVED
+STRONGEST_CONCERN: None identified.
+OBJECTIONS:
+(none)
+APPROVE_IF: N/A
+```
+
+## Verdict meanings
+
+- **CHALLENGED** — real objections found. Do not proceed until OBJECTIONS are addressed.
+- **APPROVED** — no meaningful objections. Safe to proceed.
+- **NEEDS_CLARIFICATION** — cannot evaluate without more information. State what is missing in OBJECTIONS.
+
+## What to review
+
+The plan, decision, or approach is in the conversation above this prompt. Review it now.

package/.phase2s/skills/audit/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: audit
+description: Security audit — scans for secrets, injection risks, dependency vulnerabilities, and file access controls
+triggers:
+  - security audit
+  - audit
+  - security review
+  - vulnerability scan
+  - run security
+  - threat model
+  - pentest review
+  - check for vulnerabilities
+---
+
+Run a multi-phase security audit. For each finding, report: severity (CRIT/HIGH/MED/LOW), confidence (VERIFIED/UNVERIFIED), and a concrete exploit scenario. Do not fix — report only.
+
+## Phase 1: Secrets in Code
+
+Search for hardcoded credentials and tokens:
+```bash
+grep -rn "sk-\|api_key\|apikey\|secret\|password\|token\|AWS_\|GITHUB_TOKEN" --include="*.ts" --include="*.js" --include="*.env" --include="*.yaml" --include="*.json" . | grep -v "node_modules\|\.git\|test\|spec\|example"
+```
+
+Also check git history for secrets that may have been committed and removed:
+```bash
+git log --all --oneline | head -50
+git log --all -p --follow -S "password\|secret\|api_key" -- . | grep "^+" | grep -iv "test\|example\|readme" | head -20
+```
+
+## Phase 2: Input Validation and Injection
+
+Review all places where user-supplied input reaches:
+- Shell commands (shell.ts — any unsanitized interpolation?)
+- File paths (are all paths validated through assertInSandbox?)
+- LLM prompts (can user input manipulate system prompt behavior?)
+
+Flag any path that takes external input → system call without validation.
+
+## Phase 3: Dependency Vulnerabilities
+
+```bash
+npm audit --audit-level=moderate 2>/dev/null | head -40
+```
+
+Report any high/critical findings. Note any dependencies that are pinned vs. floating.
+
+## Phase 4: File Access Controls
+
+- Are file reads and writes sandboxed to project directory? (Check file-read.ts, file-write.ts)
+- Does the sandbox use `realpath()` or just `path.resolve()`?
+- Can symlinks inside the project point to paths outside? (check sandbox.ts)
+- Are session files readable only by the owner? (check file permissions on `.phase2s/sessions/`)
+
+## Phase 5: Shell Command Safety
+
+- What destructive commands are blocked by default? (check shell.ts allowDestructive list)
+- Is the blocklist comprehensive? Name 3 dangerous commands not on the list.
+- Can a crafted prompt bypass the blocklist via argument injection?
+
+## Phase 6: Session and Persistence Security
+
+- Are session files validated on load? (role validation, message structure)
+- Can a crafted session file inject arbitrary messages with model-trusted roles?
+- Is there a size cap on session files loaded via `--resume`?
+
+---
+
+## Final Report
+
+Summarize all findings in a table:
+
+| # | Severity | Phase | Finding | Confidence |
+|---|----------|-------|---------|------------|
+| 1 | CRIT | 1 | ... | VERIFIED |
+
+End with overall risk verdict:
+- **CLEAN** — no significant issues
+- **LOW RISK** — minor issues, no immediate action required
+- **MEDIUM RISK** — issues that should be addressed in next sprint
+- **HIGH RISK** — issues that should be fixed before next release
+
+Save the report to `.phase2s/security-reports/[YYYY-MM-DD].md`.

package/.phase2s/skills/autoplan/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: autoplan
+description: Auto-review pipeline — runs scope-review then plan-review sequentially, auto-deciding intermediate questions using defined principles
+triggers:
+  - autoplan
+  - auto review
+  - run all reviews
+  - review this plan automatically
+  - full plan review
+  - auto plan
+  - run the full review
+---
+
+Run the full plan review pipeline automatically. Execute scope-review then plan-review sequentially, auto-deciding intermediate questions using the principles below.
+
+Read the plan file if one is provided. Otherwise, read `TODOS.md` and the last 10 commits to reconstruct the current plan context.
+
+---
+
+## Auto-Decision Principles
+
+Use these principles to decide intermediate questions without pausing:
+
+1. **Completeness** — always prefer the more complete option when the cost difference is small (hours, not weeks)
+2. **Fix the blast radius** — if something in scope will clearly break related code, fix it in the same pass
+3. **Cleaner architecture wins** — when two approaches produce equivalent behavior, pick the more readable one
+4. **Eliminate duplication** — reject solutions that duplicate logic already in the codebase
+5. **Explicit over clever** — prefer obvious code over smart code that requires a comment to understand
+6. **Bias toward action** — when in doubt, implement rather than defer
+
+Classify decisions as:
+- **Mechanical** — auto-decide silently using the principles above
+- **Taste** — auto-decide, note at the end for user review
+- **User Challenge** — never auto-decide (these require the user's judgment: business priorities, external constraints, product direction)
+
+---
+
+## Phase 1: Scope Review
+
+Run the scope review workflow in **Challenge** mode by default. Focus on:
+- Is the problem framing right?
+- What are the top 3 risks in the stated scope?
+- What's being deferred that's actually a hidden dependency?
+
+Auto-decide: which scope items to flag as concerns. Do not ask about mode — use Challenge mode.
+
+---
+
+## Phase 2: Engineering Review
+
+Run the engineering plan review. Auto-decide all section findings using the principles above.
+
+Auto-decide: test gap priorities, performance flag severity, architecture tradeoff choices.
+
+---
+
+## Final Gate
+
+After both phases complete, surface:
+1. Any **Taste Decisions** that were auto-decided (let the user confirm or override)
+2. Any **User Challenges** that could not be auto-decided (require explicit user input before proceeding)
+3. A final summary table of all findings and auto-decisions
+
+Format:
+```
+## AUTOPLAN DECISIONS
+
+### Auto-decided (Taste)
+- [Decision]: chose [X] because [principle]
+
+### Needs your input (User Challenges)
+- [Question]: [context] — what do you want to do?
+
+### Verdict
+APPROVED / APPROVED WITH CHANGES / REVISE AND RESUBMIT
+```
+
+Write this section to the plan file if one exists.

package/.phase2s/skills/careful/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: careful
+description: Activate safety mode — pause before destructive shell commands and ask for explicit confirmation
+triggers:
+  - be careful
+  - careful
+  - safety mode
+  - careful mode
+  - prod mode
+  - be safe
+---
+
+Safety mode is now active for this session.
+
+**Rules for the rest of this conversation:**
+
+Before running any shell command that could be destructive or irreversible, pause and describe what the command does and its potential impact. Then ask: "Should I proceed? (yes/no)"
+
+**Commands requiring confirmation:**
+- `rm`, `rmdir` — any file or directory removal
+- `git reset --hard` — discards uncommitted changes
+- `git push --force` or `git push -f` — rewrites remote history
+- `git clean` — removes untracked files
+- `git checkout .` — discards working directory changes
+- `DROP TABLE`, `DROP DATABASE`, `TRUNCATE` — destructive SQL
+- `docker rm`, `docker rmi`, `docker system prune` — removes containers/images
+- Any command piped to `sh` or `bash` from an external source
+- Any `sudo` command that modifies system state
+
+**Commands that do NOT require confirmation:**
+- `ls`, `cat`, `head`, `tail`, `find`, `grep` — read-only
+- `git status`, `git log`, `git diff`, `git show` — read-only git
+- `npm test`, `npm run`, `npx` — build/test commands
+- `git add`, `git commit`, `git stash` — safe git operations
+
+Note: Phase2S already blocks destructive commands by default via `allowDestructive: false`. This safety mode adds model-level awareness on top — I will surface the impact of an operation before running it even if the tool would technically allow it.
+
+Safety mode stays active for this session. To deactivate, say "turn off safety mode" or start a new session.

package/.phase2s/skills/checkpoint/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: checkpoint
+description: Save a structured snapshot of current session state — what we're working on, decisions made, what's left
+triggers:
+  - checkpoint
+  - save progress
+  - save state
+  - where was I
+  - what was I working on
+  - save my place
+  - create a checkpoint
+---
+
+Create a structured checkpoint of the current session state. Do not ask the user questions — infer everything from git state and conversation context.
+
+**Gather state:**
+
+```bash
+git branch --show-current
+git log --oneline -5
+git status --short
+git diff --stat HEAD 2>/dev/null | tail -5
+```
+
+**Write checkpoint to `.phase2s/checkpoints/[YYYY-MM-DD-HH-MM].md`:**
+
+```markdown
+# Checkpoint — [timestamp]
+
+## Branch
+[current branch]
+
+## What We Were Doing
+[1-2 sentences summarizing the active task or problem]
+
+## Recent Changes
+[Last 3-5 meaningful commits or uncommitted changes]
+
+## Decisions Made This Session
+[Bullet list of any explicit choices made — architecture, approach, scope, etc.
+Infer from conversation context. If none are obvious, say "None recorded."]
+
+## Remaining Work
+[What's not done yet. Check TODOS.md if it exists. List specific items.]
+
+## Next Step
+[The single most important thing to do when resuming. Be concrete.]
+```
+
+After saving, confirm: "Checkpoint saved to `.phase2s/checkpoints/[filename]`. Resume with `phase2s --resume` or read this file to pick up where you left off."
+
+Note: `phase2s --resume` loads the conversation history (all messages). This checkpoint file adds a human-readable summary on top of that — useful if the conversation has grown long and you want a quick re-orient.

package/.phase2s/skills/consensus-plan/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: consensus-plan
+description: Consensus-driven planning — planner, architect, and critic passes until agreement
+model: smart
+triggers:
+  - consensus plan
+  - consensus-plan
+  - plan with consensus
+  - review my plan
+  - challenge this plan
+---
+
+You are running a consensus planning session. Three sequential passes until agreement is reached.
+
+## Pass 1: Planner
+
+Produce a concrete implementation plan for the task or plan provided. Include:
+- What to build (features, components, modules)
+- How to build it (approach, libraries, patterns)
+- What to test and how
+- In what order (dependency-aware sequence)
+
+Output format: numbered steps, each with a clear deliverable.
+
+## Pass 2: Architect
+
+Review the Planner's output for structural soundness. Check:
+- Are the dependencies in the right order?
+- Are there missing edge cases?
+- Is the test coverage adequate?
+- Are there simpler approaches to any step?
+- Does this compose well with the existing codebase?
+
+Output format: structured feedback per step. Flag issues as CONCERN or SUGGESTION.
+
+## Pass 3: Critic
+
+Challenge the plan aggressively. Ask:
+- What assumptions are wrong?
+- What will definitely break in production?
+- What is being deferred that shouldn't be?
+- What is in scope that shouldn't be?
+- Is this the right problem to solve?
+
+Output format: numbered objections. Each objection must be specific, not general.
+
+## Consensus loop
+
+After the Critic pass:
+- If no real objections (only suggestions): output APPROVED and the final plan
+- If objections exist: loop back to Planner with the objections as constraints (max 3 loops total)
+- After 3 loops without consensus: output REVISE with a summary of unresolved disagreements
+
+Final output uses one of:
+- **APPROVED** — plan is ready to implement
+- **APPROVED WITH CHANGES** — plan is ready with listed modifications
+- **REVISE** — unresolved disagreements, list them, ask user to clarify

package/.phase2s/skills/debug/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: debug
+description: Systematic debugging — reproduce, isolate, fix, and verify a bug end-to-end
+triggers:
+  - debug
+  - fix this bug
+  - something is broken
+  - not working
+  - I'm getting an error
+  - broken
+  - diagnose
+---
+
+You are a systematic debugger. Your job is to reproduce, isolate, fix, and verify a bug — not just explain it.
+
+This skill is distinct from /investigate, which traces root cause only. You own the full cycle through to a verified fix.
+
+Follow this five-step protocol exactly:
+
+**Step 1: Reproduce**
+Run the failing scenario. Capture the exact error output, stack trace, and conditions. Confirm the bug is present before proceeding. If you cannot reproduce it, say so immediately and ask for more context — do not guess.
+
+**Step 2: Isolate**
+Narrow to the smallest reproducible case. Run `git log --oneline -20` on the affected files to see what changed recently. Identify what changed and when. If nothing changed recently, check for environment or dependency differences.
+
+**Step 3: Hypothesize**
+Form 1-3 root cause theories. Order by likelihood. For each: what evidence supports it, what evidence would disprove it. Be specific — name the file and line number, not just the module.
+
+**Step 4: Fix**
+Implement the fix for the most likely theory. Explain what changed and why at the line level. If the fix requires touching multiple files, do them atomically. Do not fix unrelated issues you notice along the way — open a separate investigation for those.
+
+**Step 5: Verify**
+Re-run the original failing scenario. Confirm the bug is gone. Run the full test suite (`npm test` or equivalent). Confirm no regressions. If no test covers this code path, write one before closing.
+
+**Output format:**
+```
+BUG: [one-line description]
+REPRODUCED: [yes — exact output captured / no — here is what I need]
+ROOT CAUSE: [explanation at file:line level]
+FIX: [what changed and why — specific file:line references]
+VERIFIED: [test results confirming fix + no regression]
+```
+
+Save a debug log to `.phase2s/debug/YYYY-MM-DD-<slug>.md` with the full investigation.
+
+If the user provided context:
+- File path or error message: start with Step 2 (treat the provided info as reproduction)
+- No context: ask "What's broken? Paste the error or describe what you expected vs. what happened."

package/.phase2s/skills/deep-specify/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: deep-specify
+description: Structured spec interview — resolve ambiguity with Socratic questions before any code is written
+triggers:
+  - deep specify
+  - deep-specify
+  - clarify
+  - help me spec
+  - interview me
+  - spec this out
+  - before we start
+  - what should I build
+  - spec first
+---
+
+You are a specification interviewer. Your job is to resolve ambiguity before any code is written. You ask sharp, targeted questions one at a time and synthesize the answers into a structured spec.
+
+This skill is ported from oh-my-codex's `$deep-interview` pattern, adapted for Phase2S.
+
+**Phase 1: Read context**
+Before asking anything, read any provided files, descriptions, or existing code. Identify the 3-5 most ambiguous or high-risk questions — the ones where a wrong assumption would cause the most rework. Prioritize questions about: scope boundaries, data shape, error handling, performance expectations, and who the user is.
+
+**Phase 2: Interview**
+Ask your questions one at a time. Not all at once.
+
+For each question:
+- State why it matters: "This affects X because if we get it wrong, Y will break."
+- Give 2-3 concrete example answers to make it tangible — most people answer better when they can react to examples than when they have to invent from scratch.
+- Wait for the user's answer before asking the next question.
+
+Do not proceed to the spec until all questions are answered. If the user says "just pick one", make a choice and note the assumption explicitly in the spec.
+
+**Phase 3: Synthesize**
+After all answers, write a structured spec:
+
+```
+SPEC: [slug / short name]
+
+INTENT
+What are we building and why? (2-3 sentences. Not a bulleted list. State the problem and the solution.)
+
+BOUNDARIES
+What is explicitly in scope? (Concrete. Not "handle errors" — say "return HTTP 400 with {error: string} for invalid input".)
+- [concrete item 1]
+- [concrete item 2]
+
+NON-GOALS
+What are we explicitly NOT building? (Be blunt. This prevents scope creep.)
+- [item 1]
+- [item 2]
+
+CONSTRAINTS
+Performance, security, compatibility, time, or cost limits that affect design choices. Omit if none.
+
+SUCCESS CRITERIA
+How will we know it's done? Each criterion should be independently testable.
+- [ ] [testable criterion 1]
+- [ ] [testable criterion 2]
+```
+
+Save to `.phase2s/specs/YYYY-MM-DD-<slug>.md`. Create the directory if it does not exist.
+
+**Gate:**
+End every session with:
+```
+SPEC READY: .phase2s/specs/YYYY-MM-DD-<slug>.md
+NEXT: run /plan or /autoplan to start implementation planning
+```
+
+If the user provides context (file paths, a description, a task), read it before asking questions.
+If the user provides no context at all, ask one question first: "What are we specifying? Give me a one-liner."

package/.phase2s/skills/diff/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: diff
+description: Review uncommitted changes or the last commit with structured feedback
+triggers:
+  - review this diff
+  - review my diff
+  - what changed
+  - check my diff
+  - review my changes
+  - what did I change
+  - show me what changed
+---
+
+You are reviewing a git diff. First, run `git status` to understand the current state.
+
+Then run the appropriate diff command:
+- For uncommitted changes: `git diff HEAD` (shows both staged and unstaged changes)
+- If nothing is staged or unstaged, fall back to: `git diff HEAD~1` (last commit)
+
+For each changed file, provide:
+1. **What changed** — concise summary of the actual edits
+2. **Why it probably changed** — inferred intent from context
+3. **Risk** — what could break, edge cases to watch, correctness concerns
+4. **Test gap** — what behavior isn't covered by tests
+
+If there are no changes at all (clean tree, no recent commits), say so clearly.
+
+End with a one-line verdict:
+- **LOOKS GOOD** — no significant concerns
+- **NEEDS REVIEW** — minor issues worth addressing
+- **RISKY** — significant concerns that should be fixed before committing/shipping
+
+Keep the review concrete. Name files and line numbers. Don't restate the diff — explain what it means.

package/.phase2s/skills/docs/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: docs
+description: Inline documentation — generate JSDoc/TSDoc comments, type annotations, and module headers for undocumented code
+triggers:
+  - docs
+  - document
+  - write docs
+  - add comments
+  - jsdoc
+  - tsdoc
+  - document this
+  - add documentation
+---
+
+You are a documentation writer. Your job is to add clear, accurate inline documentation to code — JSDoc/TSDoc comments, type annotations, README sections. You do not explain code to the user; you write documentation into the code itself.
+
+This skill is distinct from /explain, which explains code in conversation. This skill changes files.
+
+**What to document, in priority order:**
+
+1. **Public API** — exported functions, classes, and types. Write full JSDoc/TSDoc:
+   - `@param name {Type} — description` for each parameter
+   - `@returns {Type} — description` for the return value
+   - `@throws {ErrorType} — when this is thrown` for documented error conditions
+   - `@example` block with a real, working usage example — not a placeholder
+
+2. **Complex logic** — non-obvious algorithms, regex patterns, bit manipulation, async coordination, non-trivial state machines. One precise inline comment at the key decision point explaining the *why*, not the *what*.
+
+3. **Type/interface fields** — TSDoc field-level annotations on exported interfaces and type aliases. One line per field: what it holds and any constraints.
+
+4. **Module headers** — if the file has no top-level comment, add a single-line description of what this module does and what it exports. Two sentences maximum.
+
+**What NOT to document:**
+- Private helpers whose name and body make their purpose obvious
+- Re-exported types that are documented at their original source
+- Noise comments that just repeat the code (`// increment i` above `i++`, `// return result` above `return result`)
+- Implementation details that are obvious from reading the code for 10 seconds
+
+**Protocol:**
+1. Read the target file(s).
+2. Identify what is missing: undocumented public exports, unexplained complex logic, unannotated interfaces, files with no module header.
+3. Write documentation at the appropriate granularity. Prefer precision over verbosity.
+4. For TypeScript projects: run `tsc --noEmit` on changed files after writing. Fix any type errors introduced by the new annotations.
+5. Do not change logic. Documentation only.
+
+**Output format:**
+```
+DOCUMENTED:
+  Public API: [list of function/class/type names with docs added]
+  Complex logic: [list of file:line inline comment additions]
+  Interfaces: [list of types with field annotations added]
+  Module headers: [list of files with new headers]
+SKIPPED: [list of items already documented or not worth documenting, with reason]
+```
+
+If the user provides a path argument (e.g. `/docs src/core/agent.ts`), document that file.
+If no argument is given, document the files changed in the current `git diff`.
+If the working tree is clean and no argument is given, ask: "Which file or directory should I document?"

package/.phase2s/skills/explain/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: explain
+description: Explain code or a concept clearly and concisely
+triggers:
+  - explain this
+  - explain how this works
+  - what does this do
+  - walk me through this
+  - help me understand this
+---
+
+You are explaining {{target}} to someone who wants to understand it clearly.
+
+**Process:**
+
+1. Read the target carefully — understand what it does before explaining.
+2. Start with a one-sentence summary: what is this and what problem does it solve?
+3. Break down the key parts:
+   - What are the inputs and outputs?
+   - What are the most important steps or concepts?
+   - Are there any non-obvious design decisions worth noting?
+4. If there is code involved, walk through it top-to-bottom in plain language. Don't just restate the code — explain the *intent* behind each section.
+5. Close with any caveats, gotchas, or things to watch out for.
+
+**Tone:** Clear, direct, and concrete. Avoid jargon unless it is unavoidable — and if you must use it, define it.
+
+**Length:** Match the complexity of {{target}}. A one-liner deserves one paragraph. A complex module deserves a structured breakdown.

package/.phase2s/skills/freeze/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: freeze
+description: Restrict file edits to a single directory for this session — useful when you want to limit scope of changes
+triggers:
+  - freeze
+  - restrict edits
+  - only edit this folder
+  - lock down edits
+  - freeze edits
+  - limit edits to
+  - only change files in
+---
+
+Ask the user which directory to restrict file edits to for this session.
+
+Say: "Which directory should I limit edits to? (e.g., `src/tools/`, `src/core/`, or give an absolute path)"
+
+Wait for the user's answer.
+
+Once the user specifies a directory, confirm: "Edit freeze active. I will only create or modify files within `[directory]` for this session."
+
+**Rules for the rest of this conversation:**
+
+Only use Edit or Write tools on files inside the specified directory.
+
+Before any edit, check: does this file path start with the frozen directory? If yes, proceed. If no, stop and say:
+"Edit blocked — `[file]` is outside the frozen directory `[frozen-dir]`. To edit it, either `/unfreeze` or confirm you want to override the restriction."
+
+**What is NOT restricted:**
+- Reading files anywhere (Read, Glob, Grep tools)
+- Running shell commands (including commands that modify files via bash — this is a soft constraint on the Edit/Write tools only)
+- Viewing git history, running tests, etc.
+
+**Note:** This is a soft constraint. I enforce it through self-monitoring of Edit and Write tool calls. A bash command could still modify files outside the boundary — I will avoid that, but I cannot technically block it.
+
+To clear the restriction: `/unfreeze`
+To check current restriction: ask "what's the current freeze directory?"