| name | kiseki-project |
| description | Use when working inside the Kiseki Input repository on CLI commands, configuration WebUI, screenshot capture, keyboard or mouse input, drawing-app automation, heartbeat notifications, platform backends, live Windows tests, Linux true-machine tests, build/test verification, or project documentation. |
Kiseki Project
Overview
Kiseki Input is a pure C++ CLI with an embedded local WebUI for configuration and local teaching-bundle inspection. Operational capabilities are CLI-only: screenshots, input simulation, teaching recording, notifications, daemon mode, capabilities, and diagnostics.
First Rules
- Keep WebUI non-operational. It may edit config and read user-selected local teaching bundles, but must not add input, screenshot, shell, daemon, process launch, or execution routes.
- Prefer small platform slices: input, screenshot, notification, config, WebUI, and CLI wiring should remain separable.
- For ambiguous automation or weak-model handoff, run or consult
kiseki modes --json first. Keep current-session commands, background commands, and verification screenshots in the same mode family.
- Use the integrated
kiseki background ... command group for background-operation docs and tests. Older direct background command families are removed and should be treated as errors.
- On Windows, use the Windows executable for live UI verification from WSL; WSL is only the orchestration shell.
- Do not claim Linux support from WSL-only results. Linux screenshot/input must be tested on a real Linux graphical session when the user asks for Linux proof.
- Do not overclaim game background input. It depends on whether the target accepts system window messages or public automation events.
- Optional CUA Driver background operation should be invoked through
kiseki background cua .... Do not claim it is live unless cua-driver is installed, status/permissions are checked, and a real target action is verified on that platform/session.
- Treat
kiseki input ... and kiseki screenshot ... as current-session/non-background command families. Treat kiseki background ... as background, isolated-session, or target-routed command families.
- On macOS, distinguish global/current-session
kiseki input ... commands from target-routed CUA kiseki background cua ... commands. Do not describe the CUA overlay cursor as the real system pointer.
- On macOS, when Screen Recording or Accessibility permission is missing or no prompt appears, run
kiseki permissions macos screen-recording --prompt --open-settings or kiseki permissions macos accessibility --prompt --open-settings from the same GUI Terminal/app that will run Kiseki; SSH-launched binaries may not receive the same TCC grant.
- On Windows, distinguish native selected-window/background screenshot support from optional CUA Driver support in the interactive desktop session.
- On Linux, distinguish X11/XTest, Xvfb isolated desktop, Wayland XDG Desktop Portal screenshots, and optional CUA Driver support. Wayland portal is current-session screenshot support only; do not claim Wayland global input from it.
- For drawing software work, read
references/drawing-apps.md before acting. Do not draw until the target window, operation mode, canvas area, tool, visible color, and before-screenshot are established.
- For screen teaching recordings, use
skills/kiseki-teach-recording/SKILL.md and validate the produced bundle before claiming it is effective.
Project Anchors
- Repo in WSL:
/mnt/f/่ผ่ฒ่ป่ณ/้
็ฎๆฌ้ซ
- Repo in Windows:
F:\่ผ่ฒ่ป่ณ\้
็ฎๆฌ้ซ
- Windows executable:
build/Debug/kiseki.exe
- Live-test artifacts:
artifacts/live-test/
- Windows IbInputSimulator source:
F:\่ผ่ฒ่ป่ณ\ๅๅงๅ่\IbInputSimulator
- CUA binary lookup:
$KISEKI_CUA_DRIVER, cua-driver on PATH, Windows %LOCALAPPDATA%\Programs\Cua\cua-driver\bin\cua-driver.exe, macOS /Applications/CuaDriver.app/Contents/MacOS/cua-driver, or Linux ~/.local/bin/cua-driver
Quick Verification
"/mnt/c/Program Files/CMake/bin/cmake.exe" --build build
"/mnt/c/Program Files/CMake/bin/ctest.exe" --test-dir build --output-on-failure
Before final claims, also run git diff --check after edits. For live Windows UI work, capture screenshots under artifacts/live-test/ and report the paths.
For CUA work, verify kiseki background cua status, launch, windows, state, screenshot, and at least one action command on a real logged-in GUI session before claiming live support. For drawing changes, inspect a before/after screenshot from the same target window. Do not treat WSL as Linux CUA proof.
References
- Full feature map:
references/features.md
- Architecture and extension points:
references/architecture.md
- Build, unit tests, and live UI recipes:
references/testing.md
- Drawing app operation guide:
references/drawing-apps.md
