sdtk-kit 0.3.8 → 1.0.0

package/assets/toolkit/toolkit/templates/docs/specs/FLOW_ACTION_SPEC_CREATION_RULES.md

@@ -1,200 +0,0 @@
-# Flow Action Spec Creation Rules for AI Agents
-
-This document defines reusable rules for creating and updating screen flow-action specifications
-(for example `docs/specs/*_FLOW_ACTION_SPEC.md`).
-
-## 1. Scope and Goal
-
-- Produce a screen-level specification that is traceable from BA/ARCH to FE/BE implementation.
-- Keep one source of truth for:
-  - screen flow
-  - UI items and actions
-  - API calls per action
-  - screen-to-API mapping
-- Keep documentation implementation-aware and review-friendly.
-
-## 2. Mandatory Document Structure
-
-A flow-action spec should include, at minimum:
-
-1. `Abbreviations`
-2. `Feature overview`
-3. `Assumptions`
-4. `Screen flow action` (with PlantUML)
-5. `Screen layout spec by flow action`
-6. `System processing flow`
-7. `Open questions`
-8. `Screen - API mapping`
-9. `Document history`
-
-If a section is not in scope, keep the section and mark explicitly as `N/A` with reason.
-
-## 3. Table Standards
-
-- Every table must include a `No` column (sequential numbering).
-- Use stable headers for action tables:
-  - `No | Item Name | Item Type | Attribute | DB Column | Size | Default Value | Action | Description | Note`
-- Use stable headers for API mapping tables:
-  - `No | Trigger/When | UI item (No / Item Name) | API to call | Data usage / Notes`
-- Use stable headers for screen mapping:
-  - `No | Screen (section) | Screen ID | Read/Search APIs | Write APIs | Notes / Q&A refs`
-- Table rows must keep column count consistent with the header (no broken or merged rows).
-- Avoid single-line merged content that collapses multiple logical items into one table row.
-
-### 3.1 Action Table Mapping Completion Rules
-
-- After API endpoint spec and database spec are available, the action-table columns `Attribute`, `DB Column`, `Size`, and `Default Value` must not be left blank when the mapping can be derived from current source-of-truth inputs.
-- Fill these four columns only after the relevant API contract and DB schema are stable enough to be treated as the current source of truth for the active phase.
-- Source priority for filling the four columns:
-  1. `docs/api/*_ENDPOINTS.md` and OpenAPI YAML for request/response contract
-  2. `docs/database/DATABASE_SPEC_*.md` for physical column names, nullability, storage shape, and query-source aliases
-  3. confirmed flow/business rules for default state and behavior
-  4. design source (Figma/Excel) for screen label and control type only
-- `Attribute` rules:
-  - input item: use the canonical request payload path
-  - display item: use the canonical response path
-  - UI-only item: use `ui.*` namespace
-- `DB Column` rules:
-  - use physical DB column names or query-source aliases from the API/database spec
-  - if multiple columns participate, list them explicitly
-  - if the control is UI-only, write `N/A`
-- `Size` rules:
-  - document data format/type, not pixel width
-  - prefer canonical forms such as `uuid`, `DATE (YYYY-MM-DD)`, `DATETIME`, `TIME (HH:mm)`, `boolean`, `array[uuid]`, `enum(...)`, `JSON string`
-  - prefer DB storage type first; if not available, fall back to API schema type/format
-- `Default Value` rules:
-  - use confirmed business, UI, or runtime defaults
-  - if the default comes from settings or environment, state that clearly
-  - if not finalized, use `TBD` and keep or raise an open-question reference in `Note`
-- If screen labels conflict with canonical API/DB naming, preserve the original screen label in the visible screen columns, but keep `Attribute` and `DB Column` aligned to API/DB source of truth and explain the mismatch in `Note`.
-
-### 3.2 Language and Encoding Standards (EN Artifacts)
-
-- For EN artifacts (`docs/en/**` or explicitly requested EN version), narrative text must be English.
-- JP labels, if provided by the input, should be kept in a clearly marked appendix or note column, not in the default item table columns.
-- Do not leave mixed-language fragments in one sentence/cell (for example VI+EN mixed text).
-- If original VI/JP text is required for traceability, keep it in a clearly marked appendix block (`Original Text`), then provide EN translation.
-- Save files as UTF-8 and avoid mojibake/broken glyphs (`�`, `ↁE`, garbled sequences).
-- Keep canonical terminology stable across documents (for example: `bukken`, `sagyo`, `customer employee`).
-
-### 3.3 Markdown Structure Hygiene
-
-- Keep each heading on its own line; do not concatenate multiple headings/sections on one line.
-- Keep metadata blocks (`Information`, `Note`, `Behavior notes`) as structured bullet blocks, not single compressed lines.
-- Keep image, table, and separator (`---`) boundaries explicit to preserve parser/render stability.
-
-### 3.4 Assumptions Section
-
-- Every flow-action spec must include a top-level `## Assumptions` section.
-- Use this table format exactly: `# | Assumption | Verified | Risk if wrong`.
-- Keep assumptions explicit when downstream mapping or behavior depends on an unresolved decision.
-- If an assumption affects UI behavior, API mapping, or DB mapping, reflect the risk in `Note` and keep or raise the related `OQ-xx` item.
-
-## 4. Item Numbering and Duplication Rules
-
-- Use one numbering mode only: `global across document`.
-- Number values must increase across all action tables in the document.
-- Avoid duplicate item descriptions for the same UI control across screens unless behavior differs.
-- If duplicate number is intentional (rare), annotate reason in `Note`.
-
-## 5. Screen Section Rules
-
-For each screen section:
-
-- Provide metadata:
-  - official screen name
-  - Screen ID
-  - Design Source Type
-  - Design Source Reference
-- Embed one representative image per screen (from Figma, screenshot, or generated layout).
-- Provide one action table.
-- Provide one API mapping table.
-- If a screen has dialogs, create explicit dialog sub-sections with their own tables and API mapping.
-
-## 5.1 Design Source Modes
-
-Each screen section must declare a design source using one of these modes:
-
-| Mode | When | Design Source Reference |
-|------|------|----------------------|
-| `source-backed` | Figma URL or screenshot is available | Figma URL or screenshot path |
-| `generated-draft` | No Figma/screenshot, but feature has UI scope | Section reference in `docs/design/DESIGN_LAYOUT_[FEATURE_KEY].md` |
-| `none` | Feature has no UI scope for this screen | State `N/A - no UI scope` |
-
-Rules:
-- For UI-scope features, `none` is only valid when the specific screen truly has no visual layout.
-- When using `generated-draft`, the `DESIGN_LAYOUT_[FEATURE_KEY].md` must exist before the flow-action spec is finalized.
-- The flow-action spec and the design-layout doc must remain separate documents.
-- When Figma becomes available later, update the source mode from `generated-draft` to `source-backed`.
-
-## 6. API Traceability Rules
-
-- Every actionable UI event that changes state must map to a write API.
-- Every data-loading UI event must map to a read/search API.
-- If one endpoint serves multiple actions (initial load, search, refresh), state this explicitly.
-- If no API is called for an action, state `No API` and explain why.
-
-## 7. PlantUML Rules for Screen Flow
-
-- Use valid PlantUML syntax and renderability checks before handoff.
-- Use `\\n` for multi-line labels in nodes.
-- Keep diagram at navigation/action level (not low-level SQL or backend internals).
-- Ensure screen names in PlantUML match section names in layout spec.
-
-## 8. Data Source and Asset Rules
-
-- Prioritize source order:
-  1. Confirmed design source (for example Figma)
-  2. Confirmed requirement files (Excel/spec)
-  3. User-provided screenshots
-- Store images in repository-relative paths.
-- Do not keep temporary local absolute paths in markdown.
-
-### 8.1 Rendered Screen Images for Generated-Draft Screens
-
-When `Design Source Type` is `generated-draft`:
-- Screen preview images may be rendered from `DESIGN_LAYOUT_[FEATURE_KEY].md` PlantUML SALT wireframes.
-- Renderer: `toolkit/skills/sdtk-design-layout/scripts/render_design_layout_images.py`
-- Expected output path: `docs/specs/assets/<feature_snake>/screens/<screen_id>.svg`
-- If the rendered `.svg` file exists, use it as the `Screen image:` reference.
-- If rendering is unavailable or the `.svg` does not exist, replace the image line with:
-  `> Screen image not rendered in this environment. See Design Source Reference for layout.`
-- Do not leave a broken image reference pointing to a non-existent file.
-
-## 9. Consistency with Other Specs
-
-- Align terms with:
-  - BA spec glossary
-  - API endpoints spec
-  - Database spec
-- If terminology differs across docs, raise an open question and add a temporary mapping note.
-- Keep endpoint paths in flow-action spec consistent with API endpoint spec.
-
-## 10. Open Questions and Uncertainty Handling
-
-- Capture unresolved items in `Open questions` table.
-- Do not invent UI behavior or API contracts when source is ambiguous.
-- Mark uncertain mappings as `Draft` and include impacted files/sections.
-
-## 11. Change Management
-
-- On each update:
-  - update impacted screen sections
-  - update API mapping tables
-  - update screen-to-API mapping summary
-  - append one row in document history
-- Never overwrite past history rows.
-
-## 12. Final Checklist Before Handoff
-
-- PlantUML renders successfully.
-- All mandatory sections exist.
-- All tables include `No`.
-- Numbering is global across the document (no resets).
-- No broken image links (for `generated-draft` screens: `.svg` exists or render-skipped note is present).
-- Screen/API mappings are consistent with `*_ENDPOINTS.md`.
-- Assumptions section exists and unresolved assumptions are traceable.
-- Open questions are explicit and traceable.
-- For EN artifact: no leftover VI text outside allowed `Original Text` appendix blocks.
-- No mojibake/encoding corruption markers.
-- Headings/tables are structurally clean (no merged lines that break readability/traceability).

package/assets/toolkit/toolkit/templates/docs/specs/FLOW_ACTION_SPEC_TEMPLATE.md

@@ -1,172 +0,0 @@
-# {{FEATURE_NAME}} - Screen Flow Action Specification
-
-**Document ID:** {{FEATURE_KEY}}_FLOW_ACTION_SPEC
-**Version:** 1.0.0
-**Date:** {{DATE}}
-**Author:** ARCH Agent
-**Status:** DRAFT
-**Related Specs:** `docs/specs/BA_SPEC_{{FEATURE_KEY}}.md`, `docs/api/{{FEATURE_KEY}}_ENDPOINTS.md`, `docs/database/DATABASE_SPEC_{{FEATURE_KEY}}.md`
-
----
-
-## Abbreviations
-
-| No | Abbreviation | Meaning |
-| ---: | --- | --- |
-| 1 | UI | User Interface |
-| 2 | UX | User Experience |
-| 3 | API | Application Programming Interface |
-| 4 | FE | Frontend |
-| 5 | BE | Backend |
-| 6 | OQ | Open Question |
-
----
-
-## 1) Feature overview
-
-### 1.1 Background and user needs
-- TBD
-
-### 1.2 Target features in scope
-- TBD
-
-### 1.3 Implementation direction
-- TBD
-
-## Assumptions
-
-| # | Assumption | Verified | Risk if wrong |
-| ---: | --- | --- | --- |
-| 1 | TBD | No | TBD |
-
----
-
-## 2) Screen flow action
-
-### 2.1 Flow diagram (PlantUML)
-
-```plantuml
-@startuml
-left to right direction
-skinparam shadowing false
-skinparam packageStyle rectangle
-
-rectangle "Screen A" as A
-rectangle "Screen B" as B
-rectangle "Dialog C" as C
-
-A --> B : action
-B --> C : open dialog
-@enduml
-```
-
-### 2.2 Mapping to major screens
-
-| No | Screen Group | Screen Name | Screen ID | Notes |
-| ---: | --- | --- | --- | --- |
-| 1 | Main | Screen A | SCR-01 | TBD |
-| 2 | Main | Screen B | SCR-02 | TBD |
-
----
-
-## 3) Screen layout spec by flow action
-
-> Standard item table format:
-> `No | Item Name | Item Type | Attribute | DB Column | Size | Default Value | Action | Description | Note`
-
-### 3.1 Screen A
-
-Information:
-- Screen ID: SCR-01
-- Design Source Type: source-backed | generated-draft | none
-- Design Source Reference: Figma URL | screenshot path | `docs/design/DESIGN_LAYOUT_{{FEATURE_KEY}}.md` section reference | `N/A - no UI scope`
-
-Screen image:
-![3.1 Screen A](assets/{{FEATURE_SNAKE}}/screens/scr_01.svg)
-
-<!-- If the .svg file does not exist (render unavailable), replace the image line above with: -->
-<!-- > Screen image not rendered in this environment. See Design Source Reference for layout. -->
-
-| No | Item Name | Item Type | Attribute | DB Column | Size | Default Value | Action | Description | Note |
-| ---: | --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| 1 | Item A | Button | - | - | - | - | Click | TBD | TBD |
-| 2 | Item B | Input | string | column_a | 100 | empty | Input | TBD | TBD |
-
-#### API Mapping (Draft)
-
-| No | Trigger/When | UI item (No / Item Name) | API to call | Data usage / Notes |
-| ---: | --- | --- | --- | --- |
-| 1 | Initial load | Main area | `GET /api/...` | Load initial dataset |
-| 2 | Click search | No 1 | `POST /api/.../search` | Refresh grid |
-
----
-
-### 3.2 Screen B
-
-Information:
-- Screen ID: SCR-02
-- Design Source Type: source-backed | generated-draft | none
-- Design Source Reference: Figma URL | screenshot path | `docs/design/DESIGN_LAYOUT_{{FEATURE_KEY}}.md` section reference | `N/A - no UI scope`
-
-Screen image:
-![3.2 Screen B](assets/{{FEATURE_SNAKE}}/screens/scr_02.svg)
-
-<!-- If the .svg file does not exist (render unavailable), replace the image line above with: -->
-<!-- > Screen image not rendered in this environment. See Design Source Reference for layout. -->
-
-| No | Item Name | Item Type | Attribute | DB Column | Size | Default Value | Action | Description | Note |
-| ---: | --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| 3 | Item C | Toggle | boolean | flag_a | - | false | Toggle | TBD | TBD |
-
-#### API Mapping (Draft)
-
-| No | Trigger/When | UI item (No / Item Name) | API to call | Data usage / Notes |
-| ---: | --- | --- | --- | --- |
-| 1 | Change mode | No 3 | `POST /api/.../edit/{uuid}` | Persist mode |
-
----
-
-## 4) System processing flow
-
-### 4.1 Initial load
-1. Validate screen permissions.
-2. Load settings/profile context.
-3. Load main dataset.
-
-### 4.2 Create/Update/Delete flow
-1. Validate request.
-2. Execute write API.
-3. Refresh read dataset.
-
----
-
-## 5) Notes
-
-- Keep item numbering strategy explicit (`global` or `per-screen`).
-- Do not duplicate item descriptions across screens unless behavior differs.
-
----
-
-## 6) Open questions
-
-| No | Scope | Question | Impact |
-| ---: | --- | --- | --- |
-| 1 | UI | TBD | TBD |
-| 2 | API | TBD | TBD |
-
----
-
-## 7) Screen - API Mapping
-
-| No | Screen (section) | Screen ID | Read/Search APIs | Write APIs | Notes / Q&A refs |
-| ---: | --- | --- | --- | --- | --- |
-| 1 | 3.1 Screen A | SCR-01 | `GET /api/...` | `POST /api/...` | TBD |
-| 2 | 3.2 Screen B | SCR-02 | `POST /api/.../search` | `POST /api/.../edit/{uuid}` | TBD |
-
----
-
-## Document History
-
-| No | Version | Date | Author | Changes |
-| ---: | --- | --- | --- | --- |
-| 1 | 1.0.0 | {{DATE}} | ARCH Agent | Initial template-based version |

package/assets/toolkit/toolkit/templates/handoffs/ARCH_TO_DEV.md

@@ -1,31 +0,0 @@
-# ARCH to DEV Handoff
-
-## Required Inputs
-- `docs/architecture/ARCH_DESIGN_[FEATURE_KEY].md`
-- `docs/product/BACKLOG_[FEATURE_KEY].md`
-- when applicable:
-  - `docs/api/[FeaturePascal]_API.yaml`
-  - `docs/api/[FEATURE_KEY]_ENDPOINTS.md`
-  - `docs/database/DATABASE_SPEC_[FEATURE_KEY].md`
-  - `docs/design/DESIGN_LAYOUT_[FEATURE_KEY].md`
-  - `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md`
-
-## Required Outputs
-- `docs/dev/FEATURE_IMPL_PLAN_[FEATURE_KEY].md`
-- code and tests
-- Stage 1 and Stage 2 review evidence before QA handoff
-
-## Mandatory Checks
-- ARCH outputs are current and reference the same feature scope.
-- UI scope includes `DESIGN_LAYOUT` before `FLOW_ACTION_SPEC`.
-- API and DB source-of-truth files are available when implementation depends on them.
-
-## Forbidden Shortcuts
-- Do not start implementation before `FEATURE_IMPL_PLAN` is written and approved.
-- Do not treat architecture assumptions as verified facts without citing the source.
-
-## Handoff Message Shape
-- Feature: `[FEATURE_KEY]`
-- Required implementation slice: file or module scope
-- Required proving checks: test or lint or build commands
-- Upstream blockers or assumptions: explicit list

package/assets/toolkit/toolkit/templates/handoffs/BA_TO_ARCH.md

@@ -1,28 +0,0 @@
-# BA to ARCH Handoff
-
-## Required Inputs
-- `docs/specs/BA_SPEC_[FEATURE_KEY].md`
-- `docs/product/PRD_[FEATURE_KEY].md`
-- `docs/product/BACKLOG_[FEATURE_KEY].md`
-- current `SHARED_PLANNING.md`
-
-## Required Outputs
-- `docs/architecture/ARCH_DESIGN_[FEATURE_KEY].md`
-- API, DB, and UI design artifacts when in scope
-- updated `SHARED_PLANNING.md`
-- updated `QUALITY_CHECKLIST.md`
-
-## Mandatory Checks
-- `REQ -> UC/BR/AC` traceability exists in BA output.
-- unresolved `OQ-xx` items are visible to ARCH.
-- ARCH knows whether API, DB, and UI scope are required.
-
-## Forbidden Shortcuts
-- Do not jump into implementation details before architecture scope is mapped.
-- Do not hide unresolved business rules inside architecture assumptions.
-
-## Handoff Message Shape
-- Feature: `[FEATURE_KEY]`
-- In-scope use cases: `UC-xx`
-- Key business rules: `BR-xx`
-- Blocking open questions: `OQ-xx` or `None`

package/assets/toolkit/toolkit/templates/handoffs/DEV_STAGE1_SPEC_REVIEW.md

@@ -1,26 +0,0 @@
-# DEV Stage 1 Spec Review
-
-## Required Inputs
-- implementation diff or changed files
-- `docs/specs/BA_SPEC_[FEATURE_KEY].md`
-- `docs/api/[FeaturePascal]_API.yaml` and `docs/api/[FEATURE_KEY]_ENDPOINTS.md` when API scope exists
-- `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md` when UI scope exists
-- `docs/database/DATABASE_SPEC_[FEATURE_KEY].md` when data scope exists
-
-## Required Outputs
-- PASS or FAIL verdict
-- mismatch table with exact file references
-- explicit handoff decision to Stage 2 or back to DEV
-
-## Mandatory Checks
-- code matches BA, API, DB, and flow-action requirements line by line
-- missing mappings and drift are called out explicitly
-- unresolved assumptions that affect behavior are treated as blockers
-
-## Verification Evidence
-- quote the exact specification text before declaring a match or mismatch
-- use: `Spec says: "[exact quote]" -> Evidence: [match/mismatch + file reference]`
-
-## Forbidden Shortcuts
-- Do not start with style or maintainability feedback.
-- Do not trust the implementer report without checking artifacts directly.

package/assets/toolkit/toolkit/templates/handoffs/DEV_STAGE2_CODE_QUALITY_REVIEW.md

@@ -1,20 +0,0 @@
-# DEV Stage 2 Code Quality Review
-
-## Required Inputs
-- Stage 1 review result marked PASS
-- implementation diff or changed files
-- relevant test or lint outputs
-
-## Required Outputs
-- PASS or FAIL verdict
-- quality findings with file references
-- recommendation for QA handoff readiness
-
-## Mandatory Checks
-- Stage 1 spec review already passed
-- naming, structure, tests, and maintainability are reviewed
-- verification commands cited are fresh and relevant to the current diff
-
-## Forbidden Shortcuts
-- Do not reopen Stage 1 requirement matching as a substitute for quality review.
-- Do not declare QA-ready without confirming Stage 1 PASS and fresh verification evidence.

package/assets/toolkit/toolkit/templates/handoffs/DEV_TO_QA.md

@@ -1,23 +0,0 @@
-# DEV to QA Handoff
-
-## Required Inputs
-- `docs/dev/FEATURE_IMPL_PLAN_[FEATURE_KEY].md`
-- implementation diff summary
-- Stage 1 spec review PASS evidence
-- Stage 2 code-quality review PASS evidence
-- fresh test or lint outputs used for QA handoff
-
-## Required Outputs
-- QA test scope
-- explicit release-risk notes
-- updated `SHARED_PLANNING.md`
-- updated `QUALITY_CHECKLIST.md`
-
-## Mandatory Checks
-- both DEV review gates are PASS
-- verification evidence is fresh
-- known limitations or assumptions are recorded, not hidden
-
-## Forbidden Shortcuts
-- Do not hand off to QA with only one review gate complete.
-- Do not describe expected behavior as if it were verified runtime evidence.

package/assets/toolkit/toolkit/templates/handoffs/PM_TO_BA.md

@@ -1,26 +0,0 @@
-# PM to BA Handoff
-
-## Required Inputs
-- `docs/product/PROJECT_INITIATION_[FEATURE_KEY].md`
-- source requirement notes or attachments
-- current `SHARED_PLANNING.md`
-
-## Required Outputs
-- `docs/specs/BA_SPEC_[FEATURE_KEY].md`
-- updated `SHARED_PLANNING.md`
-- updated `QUALITY_CHECKLIST.md`
-
-## Mandatory Checks
-- `REQ-xx` scope is explicit and testable.
-- in-scope and out-of-scope are visible.
-- unresolved ambiguities are logged as `OQ-xx`, not hidden.
-
-## Forbidden Shortcuts
-- Do not skip glossary, BR, UC, AC, or traceability expectations.
-- Do not invent missing stakeholder decisions without logging them.
-
-## Handoff Message Shape
-- Feature: `[FEATURE_KEY]`
-- PM scope summary: 3 to 7 bullets
-- Known open questions: `OQ-xx` list or `None`
-- Expected BA focus: rules, use cases, acceptance criteria, NFRs

package/assets/toolkit/toolkit/templates/handoffs/QA_RELEASE_DECISION.md

@@ -1,21 +0,0 @@
-# QA Release Decision
-
-## Required Inputs
-- `docs/qa/QA_RELEASE_REPORT_[FEATURE_KEY].md`
-- Stage 1 and Stage 2 DEV review PASS evidence
-- fresh proving checks or benchmark-mode evidence
-- open defect list with severity
-
-## Required Outputs
-- `APPROVED` or `REJECTED`
-- explicit evidence summary
-- unresolved risks and assumptions list
-
-## Mandatory Checks
-- verdict is backed by fresh command evidence or benchmark policy
-- specification quotes are used for requirement-based validation
-- defects and known gaps are visible in the decision
-
-## Forbidden Shortcuts
-- Do not issue `APPROVED` based on planned checks.
-- Do not hide environment limitations; state when runtime verification was not possible.

package/bin/sdtk.js

@@ -1,15 +0,0 @@
-#!/usr/bin/env node
-
-"use strict";
-
-const { run } = require("../src/index");
-
-run(process.argv.slice(2))
-  .then((exitCode) => {
-    process.exitCode = Number.isInteger(exitCode) ? exitCode : 0;
-  })
-  .catch((error) => {
-    console.error(`sdtk: ${error.message}`);
-    process.exitCode =
-      typeof error.exitCode === "number" ? error.exitCode : 4;
-  });

package/src/commands/auth.js

@@ -1,85 +0,0 @@
-"use strict";
-
-const { clearAuthState, readAuthState, writeAuthState } = require("../lib/state");
-const { parseFlags } = require("../lib/args");
-const { checkRepoAccess } = require("../lib/github-access");
-const { ValidationError } = require("../lib/errors");
-
-const FLAG_DEFS = {
-  token: { type: "string" },
-  status: { type: "boolean" },
-  logout: { type: "boolean" },
-  verify: { type: "boolean" },
-};
-
-/**
- * Redact a token for safe display (show first 4 chars only).
- */
-function redactToken(token) {
-  if (!token || token.length < 8) return "****";
-  return token.slice(0, 4) + "****";
-}
-
-async function cmdAuth(args) {
-  const { flags } = parseFlags(args, FLAG_DEFS);
-
-  if (flags.status) {
-    const state = readAuthState();
-    if (!state.authenticated) {
-      console.log("Auth status: not authenticated");
-      console.log('Run "sdtk auth --token <value>" to authenticate.');
-      return 1;
-    }
-    console.log("Auth status: authenticated");
-    console.log(`Token: ${redactToken(state.token)}`);
-    return 0;
-  }
-
-  if (flags.logout) {
-    clearAuthState();
-    console.log("Auth state cleared.");
-    return 0;
-  }
-
-  // Process --token first, then optionally --verify in the same invocation.
-  // This supports: sdtk auth --token <value> --verify
-  if (flags.token) {
-    const { path: authFile, hardened } = writeAuthState(flags.token);
-    if (hardened) {
-      console.log("Token stored securely.");
-    } else {
-      console.log("Token stored (file permission hardening was not applied).");
-    }
-    console.log(`Auth file: ${authFile}`);
-
-    if (flags.verify) {
-      console.log("");
-      console.log("Verifying repository access...");
-      const result = await checkRepoAccess(flags.token);
-      console.log(result.message);
-      return result.hasAccess ? 0 : 1;
-    }
-
-    console.log('Run "sdtk auth --verify" to check repository access.');
-    return 0;
-  }
-
-  if (flags.verify) {
-    const state = readAuthState();
-    if (!state.authenticated) {
-      console.log("Not authenticated. Store a token first with --token.");
-      return 1;
-    }
-    const result = await checkRepoAccess(state.token);
-    console.log(result.message);
-    return result.hasAccess ? 0 : 1;
-  }
-
-  throw new ValidationError(
-    "Usage: sdtk auth --token <value> [--verify] | --status | --logout"
-  );
-}
-
-module.exports = {
-  cmdAuth,
-};