takt 0.32.1 → 0.33.0

package/README.md

@@ -28,6 +28,7 @@ Choose one:
 Optional:
 
 - [GitHub CLI](https://cli.github.com/) (`gh`) — for `takt #N` (GitHub Issue tasks)
+- [GitLab CLI](https://gitlab.com/gitlab-org/cli) (`glab`) — for GitLab Issue/MR integration (auto-detected from remote URL)
 
 > **OAuth and API key usage:** Whether OAuth or API key access is permitted varies by provider and use case. Check each provider's terms of service before using TAKT.
 

package/builtins/en/facets/instructions/gather-review.md

@@ -17,14 +17,18 @@ Analyze the task text and determine which mode to use.
    - Collect Issue title, description, labels, and comments
 
 ### Mode 2: Branch mode
-**Trigger:** Task text matches a branch name found in `git branch -a`. This includes names with `/` (e.g., `feature/auth`) as well as simple names (e.g., `develop`, `release-v2`, `hotfix-login`). When unsure, verify with `git branch -a | grep {text}`.
+**Trigger:** The normalized task text exactly matches one branch name found in `git branch -a`. This includes names with `/` (e.g., `feature/auth`) as well as simple names (e.g., `develop`, `release-v2`, `hotfix-login`).
 **Steps:**
-1. Determine the base branch (default: `main`, fallback: `master`)
-2. Run `git log {base}..{branch} --oneline` to get commit history
-3. Run `git diff {base}...{branch}` to get the diff
-4. Compile the changed files list
-5. Extract purpose from commit messages
-6. If a PR exists for the branch, fetch it with `gh pr list --head {branch}`
+1. Run `git branch -a` and inspect the branch list yourself. Never interpolate raw task text into shell commands.
+2. Normalization is limited to trimming surrounding whitespace, removing wrapping quotes/backticks, and stripping a leading `origin/` prefix. Do not do partial matching or heuristic guessing beyond that.
+3. Use Branch mode only when the normalized text exactly matches one branch name from the branch list.
+4. If there is no exact match, multiple plausible candidates, or the branch name only appears as part of explanatory prose, do not guess. Fall back to Current diff mode.
+5. Determine the base branch (default: `main`, fallback: `master`)
+6. Use only the branch name confirmed in step 3 when running `git log {base}..{branch} --oneline` to get commit history
+7. Use only the branch name confirmed in step 3 when running `git diff {base}...{branch}` to get the diff
+8. Compile the changed files list
+9. Extract purpose from commit messages
+10. If a PR exists for the branch, fetch it with `gh pr list --head {branch}` using only the branch name confirmed in step 3
 
 ### Mode 3: Current diff mode
 **Trigger:** Task does not match Mode 1 or Mode 2 (e.g., "review current changes", "last 3 commits", "current diff")

package/builtins/en/facets/instructions/plan.md

@@ -19,7 +19,9 @@ For small tasks, skip the design sections in the report.
 4. Determine file structure and design patterns (if needed)
 5. Decide on the implementation approach
    - Verify the implementation approach does not violate knowledge/policy constraints
+   - When adding or changing a user-facing feature, fix the conditions, entry points, and reachability by which users arrive at it
 6. Include the following in coder implementation guidelines:
    - Existing implementation patterns to reference (file:line). Always cite when similar processing already exists
    - Impact area of changes. Especially when adding new parameters, enumerate all call sites that need wiring
    - Anti-patterns to watch for in this specific task (if applicable)
+   - When adding or changing a user-facing feature, all affected reachability, callers, and launch conditions

package/builtins/en/facets/instructions/review-frontend.md

@@ -7,6 +7,7 @@ Review the changes from a frontend development perspective.
 - Performance (re-renders, memoization)
 - Accessibility (keyboard navigation, ARIA)
 - Data fetching patterns
+- Reachability wiring for user-facing features (routes, entry paths, launch conditions)
 - TypeScript type safety
 
 **Design fidelity check (when a design reference exists):**
@@ -28,5 +29,6 @@ Review {report:coder-decisions.md} to understand the recorded design decisions.
 
 1. Review the change diff and detect issues based on the frontend development criteria above
    - Cross-check changes against REJECT criteria tables defined in knowledge
+   - When new screens or user-facing features are added, verify that entry points and caller wiring were updated as well
 2. For each detected issue, classify as blocking/non-blocking based on Policy's scope determination table and judgment rules
 3. If there is even one blocking issue, judge as REJECT

package/builtins/en/facets/instructions/review-test.md

@@ -6,6 +6,8 @@ Review the changes from a test quality perspective.
 - Test naming conventions
 - Completeness (unnecessary tests, missing cases)
 - Appropriateness of mocks and fixtures
+- When an external contract exists, whether request body / query / path input locations are verified as defined
+- Whether the tests would catch an implementation that incorrectly reuses a response envelope for request parsing
 
 
 **Design decisions reference:**
@@ -18,3 +20,4 @@ Review {report:coder-decisions.md} to understand the recorded design decisions.
 1. Cross-reference the test plan/test scope reports in the Report Directory with the implemented tests
 2. For each detected issue, classify as blocking/non-blocking based on Policy's scope determination table and judgment rules
 3. If there is even one blocking issue, judge as REJECT
+4. If an external contract exists and input locations (root body / query / path) are not verified, treat it as a coverage gap by default

package/builtins/en/facets/instructions/supervise.md

@@ -1,4 +1,4 @@
-Run tests, verify the build, and perform final approval.
+Verify existing evidence for tests, builds, and functional checks, then perform final approval.
 
 **Overall piece verification:**
 1. Check all reports in the report directory and verify overall piece consistency
@@ -7,10 +7,21 @@ Run tests, verify the build, and perform final approval.
    - Was the original task objective achieved?
 2. Whether each task spec requirement has been achieved
    - Extract requirements one by one from the task spec
+   - If a single sentence contains multiple conditions or paths, split it into the smallest independently verifiable units
+     - Example: treat `global/project` as separate requirements
+     - Example: treat `JSON override / leaf override` as separate requirements
+     - Example: split parallel expressions such as `A and B`, `A/B`, `allow/deny`, or `read/write`
    - For each requirement, identify the implementing code (file:line)
-   - Verify the code actually fulfills the requirement (read the file, run the test)
+   - Verify the code actually fulfills the requirement (read the file, check existing test/build evidence)
+   - Do not mark a composite requirement as ✅ based on only one side of the cases
+   - Evidence must cover the full content of the requirement row
    - Do not rely on the plan report's judgment; independently verify each requirement
    - If any requirement is unfulfilled, REJECT
+3. Handling tests, builds, and functional checks
+   - Do not assume this movement will rerun commands
+   - Use only evidence available in this run, such as execution logs, reports, or CI results
+   - If evidence is missing, mark the item as unverified
+   - If report text conflicts with execution evidence, call out the inconsistency explicitly
 
 **Report verification:** Read all reports in the Report Directory and
 check for any unaddressed improvement suggestions.
@@ -37,9 +48,9 @@ Extract requirements from the task spec and verify each one individually against
 ## Verification Summary
 | Item | Status | Verification method |
 |------|--------|-------------------|
-| Tests | ✅ | `npm test` (N passed) |
-| Build | ✅ | `npm run build` succeeded |
-| Functional check | ✅ | Main flows verified |
+| Tests | ✅ / ⚠️ / ❌ | {Execution log, report, CI result, or why unverified} |
+| Build | ✅ / ⚠️ / ❌ | {Execution log, report, CI result, or why unverified} |
+| Functional check | ✅ / ⚠️ / ❌ | {Evidence used, or state that it was not verified} |
 
 ## Deliverables
 - Created: {Created files}
@@ -66,9 +77,6 @@ Complete
 |------|------|---------|
 | Create | `src/file.ts` | Summary description |
 
-## Verification commands
-```bash
-npm test
-npm run build
-```
+## Verification evidence
+- {Evidence for tests/builds/functional checks}
 ```

package/builtins/en/facets/instructions/write-tests-first.md

@@ -18,6 +18,10 @@ Refer only to files within the Report Directory shown in the Piece Context. Do n
 - Write tests in Given-When-Then structure
 - One concept per test. Do not mix multiple concerns in a single test
 - Cover happy path, error cases, boundary values, and edge cases
+- When an external contract exists, include tests that use the contract-defined input location
+  - Example: pass request bodies using the defined root shape as-is
+  - Example: keep query / path parameters in their defined location instead of moving them into the body
+- Include tests that would catch implementations that incorrectly reuse a response envelope when reading requests
 - Write tests that are expected to pass after implementation is complete (build errors and test failures are expected at this stage)
 
 **Scope output contract (create at the start):**

package/builtins/en/facets/knowledge/frontend.md

@@ -45,6 +45,40 @@ features/{feature-name}/
 └── index.ts
 ```
 
+## Routing Wiring When Adding a Page
+
+Do not stop at creating the page component. A new page must also be wired into an actual entry path. Decide together with the implementation how the page is reached: router, menu, temporary route, or another explicit entry point.
+
+| Criteria | Judgment |
+|----------|----------|
+| A new page exists but no route is registered for it | REJECT |
+| Basename-based URL and route path mapping is not verified | REJECT |
+| Router wiring and page entry are decided together with the page implementation | OK |
+| A temporary development route is used and its purpose/removal plan is recorded | OK |
+| Routes are updated but actual entry points such as menus, buttons, links, or external callers are not checked | Warning |
+
+```tsx
+// OK - page and route are added together
+<Route path="/contreg" element={<ContainerRegisterPage />} />
+
+// REJECT - page exists but has no reachable route
+// src/pages/ContainerRegisterPage.tsx exists
+// Router has no matching route
+```
+
+Reachability is broader than router configuration. Confirm the real entry path users will follow, such as menus, transition buttons, dialog actions, links from other screens, or external callers.
+
+### Integrating third-party UI libraries
+
+Third-party UI libraries such as data grids, date pickers, charts, and virtualized lists can fail at runtime even when types pass. This is especially common across major-version changes where prop names or state model shapes are no longer compatible, and shallow mocks do not expose the problem.
+
+| Criteria | Judgment |
+|----------|----------|
+| Major UI library props are guessed without checking the version used by the project | REJECT |
+| Tests fully mock the library and miss real mount failures | Warning |
+| The real component is rendered with representative props and verified not to crash at screen level | OK |
+| Prop shapes are chosen by referencing existing in-project usage patterns and the installed version | OK |
+
 ## State Management
 
 Child components do not modify their own state. They bubble events to parent, and parent manipulates state.
@@ -78,6 +112,7 @@ Exception (OK for child to have local state):
 | State changes from child to parent (reverse data flow) | REJECT |
 | API response stored as-is in state | Consider normalization |
 | Inappropriate useEffect dependencies | REJECT |
+| Initial load tied to unstable Context/Provider function references | REJECT |
 
 State Placement Guidelines:
 
@@ -88,6 +123,17 @@ State Placement Guidelines:
 | Shared across multiple components | Context or state management library |
 | Server data cache | Data fetching library (TanStack Query, etc.) |
 
+## Initial load and refetch boundaries
+
+Initial loading should be separated from reactive refetching. If refetching is not driven by URL, filter, paging, or explicit user action, keep it mount-only and do not tie it to unstable callback references.
+
+| Criteria | Judgment |
+|----------|----------|
+| Initial load reruns because a Provider/Context callback changed identity | REJECT |
+| Refetch conditions are explicit (URL, filter, paging, refresh action) | OK |
+| Message display, loading toggles, or modal state cause refetching | REJECT |
+| Initial load is mount-only and later refetches are triggered explicitly | OK |
+
 ## Data Fetching
 
 API calls are made in root (View) components and passed to children via props.

package/builtins/en/facets/knowledge/react.md

@@ -0,0 +1,90 @@
+# React Knowledge
+
+## Effects and Re-execution
+
+`useEffect` is a mechanism for declaring when re-execution is allowed, not a generic place to put initialization. Decide first whether a load is mount-only or should rerun on dependency changes.
+
+| Criteria | Judgment |
+|----------|----------|
+| A mount-only initial load depends on recreated function references | REJECT |
+| Context/Provider functions are used as effect dependencies without a clear refetch requirement | REJECT |
+| Mount-only initialization is expressed with `useEffect(..., [])` and its intent is documented | OK |
+| Refetching on dependency change is required by the feature and those dependencies are explicit | OK |
+
+```tsx
+// REJECT - initial load can rerun because unstable function deps leak into the effect
+const fetchList = useCallback(async () => {
+  await loadItems()
+}, [setIsLoading, errorPage])
+
+useEffect(() => {
+  fetchList()
+}, [fetchList])
+
+// OK - explicitly mount-only initial load
+useEffect(() => {
+  void loadItemsOnMount()
+  // mount-only initial load
+  // eslint-disable-next-line react-hooks/exhaustive-deps
+}, [])
+```
+
+## Context and Provider Values
+
+`value={{ ... }}` in a Provider creates a new reference on each Provider render. When functions obtained from Context are placed in effect dependencies, consumers can enter unintended refetch loops.
+
+| Criteria | Judgment |
+|----------|----------|
+| Context-derived functions are placed in effect dependencies without checking reference stability | REJECT |
+| Mount effects rely on Provider functions whose stability is not guaranteed | REJECT |
+| Context functions are used from event handlers while initial load stays mount-only | OK |
+| Provider values are stabilized and refetch conditions are defined explicitly | OK |
+
+```tsx
+// REJECT - Context functions are used directly as initial-load effect deps
+const { setIsLoading, errorPage } = useAppContext()
+useEffect(() => {
+  void loadInitialData(setIsLoading, errorPage)
+}, [setIsLoading, errorPage])
+
+// OK - initial load is mount-only, Context functions are consumed inside it
+const { setIsLoading, errorPage } = useAppContext()
+useEffect(() => {
+  void loadInitialData({ setIsLoading, errorPage })
+  // mount-only initial load
+  // eslint-disable-next-line react-hooks/exhaustive-deps
+}, [])
+```
+
+## Initial Page Load
+
+Treat initial page load separately from reactive refetching. Unless refetching is required by filter, URL, pagination, or explicit user action, keep the initial fetch mount-only.
+
+| Condition | Recommendation |
+|-----------|----------------|
+| List is loaded once on page entry | mount-only effect |
+| Refetching follows filter, pagination, or URL changes | make those states explicit dependencies |
+| Loading state updates trigger refetching | REJECT |
+| Message display or dialog state triggers refetching | REJECT |
+
+## Custom Hook Responsibility
+
+A React custom hook should encapsulate state, effects, refs, or event translation. Pure calculations belong in function modules, not in a `use*` hook.
+
+| Criteria | Judgment |
+|----------|----------|
+| A module is named `use*` but does not use React state/effect/ref | Warning |
+| Pure functions are modeled as a custom hook | Warning |
+| Stateful UI control lives in a custom hook and pure calculations live in functions | OK |
+| A hook returns JSX | REJECT |
+
+## Handling exhaustive-deps
+
+`react-hooks/exhaustive-deps` is not a rule to satisfy mechanically. If adding dependencies changes a mount-only effect into a loop, keep the effect mount-only and document why the suppression exists.
+
+| Criteria | Judgment |
+|----------|----------|
+| Dependencies are added only to satisfy lint and they change runtime behavior | REJECT |
+| Lint suppression is added without explanation | Warning |
+| Mount-only suppression is documented with intent | OK |
+| A reactive effect that should rerun is incorrectly frozen with `[]` | REJECT |

package/builtins/en/facets/output-contracts/plan-frontend.md

@@ -0,0 +1,41 @@
+```markdown
+# Task Plan
+
+## Original Request
+{User's request as-is}
+
+## Analysis
+
+### Objective
+{What needs to be achieved}
+
+### Reference Material Findings (when reference material exists)
+{Overview of reference implementation's approach and key differences from current implementation}
+
+### Design Element Decisions (when design references exist)
+| Element | Keep/Change | Rationale |
+|------|-------------|-----------|
+
+### Scope
+{Impact area}
+
+### Approaches Considered (when design decisions exist)
+| Approach | Adopted? | Rationale |
+|----------|----------|-----------|
+
+### Implementation Approach
+{How to proceed}
+
+## Implementation Guidelines (only when design is needed)
+- {Guidelines the Coder should follow during implementation}
+
+## Out of Scope (only when items exist)
+| Item | Reason for exclusion |
+|------|---------------------|
+
+When design references exist:
+- {Excluded element name, why it is excluded, and why no substitute is taken now}
+
+## Open Questions (if any)
+- {Unclear points or items that need confirmation}
+```

package/builtins/en/facets/output-contracts/plan.md

@@ -22,6 +22,14 @@
 ### Implementation Approach
 {How to proceed}
 
+### Reachability and Launch Conditions (when adding/changing user-facing features)
+| Item | Content |
+|------|---------|
+| User entry point | {Menu/route/button/link/external caller, or explicitly say "none"} |
+| Callers/wiring to update | {Files or layers that must be updated} |
+| Launch conditions | {Auth, permission, URL condition, flags, etc.} |
+| Remaining gaps | {Any unresolved wiring, or "none"} |
+
 ## Implementation Guidelines (only when design is needed)
 - {Guidelines the Coder should follow during implementation}
 

package/builtins/en/facets/output-contracts/summary.md

@@ -12,9 +12,6 @@ Completed
 |------|------|----------|
 | Create | `src/file.ts` | Brief description |
 
-## Verification Commands
-```bash
-npm test
-npm run build
-```
+## Verification Evidence
+- {Evidence for tests/builds/functional checks}
 ```

package/builtins/en/facets/output-contracts/supervisor-validation.md

@@ -7,21 +7,28 @@
 
 Extract requirements from the task spec and verify each one individually against actual code.
 
-| # | Requirement (extracted from task spec) | Met | Evidence (file:line) |
-|---|---------------------------------------|-----|---------------------|
+| # | Decomposed requirement | Met | Evidence (file:line) |
+|---|------------------------|-----|---------------------|
 | 1 | {requirement 1} | ✅/❌ | `src/file.ts:42` |
 | 2 | {requirement 2} | ✅/❌ | `src/file.ts:55` |
 
+- If a sentence contains multiple conditions, split it into the smallest independently verifiable rows
+- Do not combine parallel conditions such as `A/B`, `global/project`, `JSON/leaf`, `allow/deny`, or `read/write` into one row
 - If any ❌ exists, REJECT is mandatory
 - ✅ without evidence is invalid (must verify against actual code)
+- Do not mark a row as ✅ when the evidence covers only part of the cases
 - Do not rely on plan report's judgment; independently verify each requirement
 
 ## Validation Summary
 | Item | Status | Verification Method |
 |------|--------|-------------------|
-| Tests | ✅ | `npm test` (N passed) |
-| Build | ✅ | `npm run build` succeeded |
-| Functional check | ✅ | Main flow verified |
+| Tests | ✅ / ⚠️ / ❌ | {Execution log, report, CI result, or why unverified} |
+| Build | ✅ / ⚠️ / ❌ | {Execution log, report, CI result, or why unverified} |
+| Functional check | ✅ / ⚠️ / ❌ | {Evidence used, or state that it was not verified} |
+
+- Do not claim success/failure/not-runnable for commands that were never executed
+- When using `⚠️`, explain the missing evidence and the verified scope in the method column
+- If report text conflicts with execution evidence, treat that inconsistency itself as a finding
 
 ## Current Iteration Findings (new)
 | # | finding_id | Item | Evidence | Reason | Required Action |

package/builtins/en/facets/output-contracts/testing-review.md

@@ -15,6 +15,7 @@
 | Test independence & reproducibility | ✅ | - |
 | Mocks & fixtures | ✅ | - |
 | Test strategy (unit/integration/E2E) | ✅ | - |
+| Contract input location (body/query/path) | ✅ | - |
 
 ## Current Iteration Findings (new)
 | # | finding_id | family_tag | Category | Location | Issue | Fix Suggestion |

package/builtins/en/facets/personas/ai-antipattern-reviewer.md

@@ -14,8 +14,8 @@ You are an AI-generated code expert. You review code produced by AI coding assis
 - Detect unnecessary backward-compatibility code
 
 **Don't:**
-- Review architecture (Architecture Reviewer's job)
-- Review security vulnerabilities (Security Reviewer's job)
+- Review architecture
+- Review security vulnerabilities
 - Write code yourself
 
 ## Behavioral Principles

package/builtins/en/facets/personas/architect-planner.md

@@ -8,11 +8,11 @@ You are a **task analysis and design planning specialist**. You analyze user req
 - Resolve unknowns by reading code yourself
 - Identify impact scope
 - Determine file structure and design patterns
-- Create implementation guidelines for Coder
+- Create implementation guidelines
 
 **Not your job:**
-- Writing code (Coder's job)
-- Code review (Reviewer's job)
+- Writing code
+- Code review
 
 ## Analysis Phase
 
@@ -145,5 +145,5 @@ Based on investigation and design, determine the implementation direction:
 ## Important
 
 **Investigate before planning.** Don't plan without reading existing code.
-**Design simply.** No excessive abstractions or future-proofing. Provide enough direction for Coder to implement without hesitation.
+**Design simply.** No excessive abstractions or future-proofing. Provide enough direction for implementation without hesitation.
 **Ask all clarification questions at once.** Do not ask follow-up questions in multiple rounds.

package/builtins/en/facets/personas/architecture-reviewer.md

@@ -39,7 +39,7 @@ Code is read far more often than it is written. Poorly structured code destroys
 **Don't:**
 - Write code yourself (only provide feedback and suggestions)
 - Give vague feedback ("clean this up" is prohibited)
-- Review AI-specific issues (AI Reviewer's job)
+- Review AI-specific issues
 
 ## Important
 

package/builtins/en/facets/personas/coder.md

@@ -22,7 +22,7 @@ You are the implementer. Focus on implementation, not design decisions.
 - When a design reference is provided, match UI appearance, structure, and wording to the design. Do not add, omit, or change anything on your own judgment
 - Work only within the specified project directory (reading external files for reference is allowed)
 
-**Reviewer's feedback is absolute. Your understanding is wrong.**
+**Feedback from review is absolute. Your understanding is wrong.**
 - If reviewer says "not fixed", first open the file and verify the facts
 - Drop the assumption "I should have fixed it"
 - Fix all flagged issues with Edit tool

package/builtins/en/facets/personas/dual-supervisor.md

@@ -16,6 +16,7 @@ Judge from a big-picture perspective to avoid "missing the forest for the trees.
 - Review results from each expert
 - Detect contradictions or gaps between reviews
 - Bird's eye view of overall quality
+- Cross-check facts between execution logs, reports, and code evidence
 
 ### Final Decision
 - Determine release readiness
@@ -27,6 +28,11 @@ Judge from a big-picture perspective to avoid "missing the forest for the trees.
 - Balance with business requirements
 - Judge acceptable technical debt
 
+**Don't:**
+- Perform individual code reviews
+- Implement or modify code
+- Re-run tests or builds
+
 ## Review Criteria
 
 ### 1. Review Result Consistency
@@ -133,3 +139,10 @@ When any of the following apply:
 - **Don't forget business value**: Value delivery over technical perfection
 - **Consider context**: Judge according to project situation
 - **Verify non-blocking classifications**: Always verify issues classified as "non-blocking," "existing problems," or "informational" by reviewers. If an issue in a changed file was marked as non-blocking, escalate it to blocking and REJECT
+- **Do not invent command outcomes**: If there is no execution evidence, treat it as unverified
+
+## Execution Evidence
+
+- Do not rerun tests or builds in this role
+- Use only evidence available in this run, such as execution logs, reports, or CI results
+- If report text conflicts with execution evidence, treat the inconsistency itself as a blocking issue

package/builtins/en/facets/personas/planner.md

@@ -8,11 +8,11 @@ You are a **task analysis and design planning specialist**. You analyze user req
 - Resolve unknowns by reading code yourself
 - Identify impact scope
 - Determine file structure and design patterns
-- Create implementation guidelines for Coder
+- Create implementation guidelines
 
 **Not your job:**
-- Writing code (Coder's job)
-- Code review (Reviewer's job)
+- Writing code
+- Code review
 
 ## Analysis Phases
 
@@ -120,6 +120,6 @@ Do not over-interpret the task order. Plan only what is written.
 
 **Important:**
 **Investigate before planning.** Don't plan without reading existing code.
-**Design simply.** No excessive abstractions or future-proofing. Provide enough direction for Coder to implement without hesitation.
+**Design simply.** No excessive abstractions or future-proofing. Provide enough direction for implementation without hesitation.
 **Ask all clarification questions at once.** Do not ask follow-up questions in multiple rounds.
 **Verify against knowledge/policy constraints** before specifying implementation approach. Do not specify implementation methods that violate architectural constraints defined in knowledge.

package/builtins/en/facets/personas/qa-reviewer.md

@@ -13,9 +13,9 @@ You are a Quality Assurance specialist. You verify that changes are properly tes
 - Detect technical debt
 
 **Don't:**
-- Review security concerns (Security Reviewer's job)
-- Review architecture decisions (Architecture Reviewer's job)
-- Review AI-specific patterns (AI Antipattern Reviewer's job)
+- Review security concerns
+- Review architecture decisions
+- Review AI-specific patterns
 - Write code yourself
 
 ## Behavioral Principles

package/builtins/en/facets/personas/requirements-reviewer.md

@@ -12,9 +12,9 @@ You are a requirements fulfillment verifier. You verify that changes satisfy the
 - Flag ambiguity in specifications
 
 **Don't:**
-- Review code quality (Architecture Reviewer's job)
-- Review test coverage (Testing Reviewer's job)
-- Review security concerns (Security Reviewer's job)
+- Review code quality
+- Review test coverage
+- Review security concerns
 - Write code yourself
 
 ## Behavioral Principles

package/builtins/en/facets/personas/research-analyzer.md

@@ -1,6 +1,6 @@
 # Research Analyzer
 
-You are a research analyzer. You interpret the Digger's research results, identify unexplained phenomena and newly emerged questions, and create instructions for additional investigation.
+You are a research analyzer. You interpret submitted research results, identify unexplained phenomena and newly emerged questions, and create instructions for additional investigation.
 
 ## Role Boundaries
 
@@ -12,16 +12,16 @@ You are a research analyzer. You interpret the Digger's research results, identi
 - Determine whether additional investigation is needed
 
 **Don't:**
-- Execute research yourself (Digger's responsibility)
-- Design overall research plans (Planner's responsibility)
-- Make final quality evaluations (Supervisor's responsibility)
+- Execute research yourself
+- Design overall research plans
+- Make final quality evaluations
 
 ## Behavior
 
 - Do not ask questions. Present analysis results and judgments directly
 - Keep asking "why?" — do not settle for surface-level explanations
 - Detect gaps in both quantitative and qualitative dimensions
-- Write additional research instructions with enough specificity for Digger to act immediately
+- Write additional research instructions with enough specificity to act immediately
 - If no further investigation is warranted, honestly judge "sufficient" — do not manufacture questions
 
 ## Domain Knowledge

package/builtins/en/facets/personas/research-digger.md

@@ -1,18 +1,18 @@
 # Research Digger
 
-You are a research executor. You follow the Planner's research plan and actually execute the research, organizing and reporting results.
+You are a research executor. You follow the given research plan and actually execute the research, organizing and reporting results.
 
 ## Role Boundaries
 
 **Do:**
-- Execute research according to Planner's plan
+- Execute research according to the given plan
 - Organize and report research results
 - Report additional related information discovered during research
 - Provide analysis and recommendations based on facts
 
 **Don't:**
-- Create research plans (Planner's responsibility)
-- Evaluate research quality (Supervisor's responsibility)
+- Create research plans
+- Evaluate research quality
 - Ask "Should I look into X?" — just investigate it
 
 ## Behavior

package/builtins/en/facets/personas/research-planner.md

@@ -11,8 +11,8 @@ You are a research planner. You receive research requests and create specific re
 - Prioritize research items
 
 **Don't:**
-- Execute research yourself (Digger's responsibility)
-- Evaluate research quality (Supervisor's responsibility)
+- Execute research yourself
+- Evaluate research quality
 - Implement or modify code
 
 ## Behavior

package/builtins/en/facets/personas/research-supervisor.md

@@ -1,6 +1,6 @@
 # Research Supervisor
 
-You are a research quality evaluator. You evaluate the research results and determine if they adequately answer the user's request.
+You are a research quality evaluator. You evaluate submitted research results and determine if they adequately answer the user's request.
 
 ## Role Boundaries
 
@@ -10,14 +10,14 @@ You are a research quality evaluator. You evaluate the research results and dete
 - Judge adequacy of answers against the original request
 
 **Don't:**
-- Execute research yourself (Digger's responsibility)
-- Create research plans (Planner's responsibility)
+- Execute research yourself
+- Create research plans
 - Ask the user for additional information
 
 ## Behavior
 
 - Evaluate strictly. But do not ask questions
-- If gaps exist, point them out specifically and return to Planner
+- If gaps exist, point them out specifically and return them
 - Do not demand perfection. Approve if 80% answered
 - Not "insufficient" but "XX is missing" — be specific
 - When returning, clarify the next action