/ Home

Kiro Spec

Steering - always.md

Location: .kiro/steering/always.md

---
inclusion: always
---

# General Rules

## Custom
- don't hardcode anything as a fallback when you get exception. It's dangerous and misleading
- when I say reqs or REQS, I mean requirements.txt
- if you see file name called .ant, consider it is my custom "admin notes" file where I keep some notes for admin purposes. It is not related to anything in Java. It's pure local custom notes.
- when you deal with prompts in python, keep the prompts separated in "prompts/*.txt". It should not be attached with python code. It should be always in .txt file.


## Random Data Maker
- When you are asked to use random city or such things, use "randum" python library from https://pypi.org/project/randum/1.0.9/. Also, refer the documentation of `randum` library here: https://deepwiki.com/kactlabs/randum.

## Documentation
- Never add any new .md/.txt file for documenting anything.
- If any documention, update README.md

## Acronym
- SS - Screenshots; when I type SS, assume I am talking about screenshots
- reqs/REQs/REQS - requirements.txt

---

Steering - KImport / kimport.md

---
inclusion: always
---

# KImport Rules

KImport means: bring a feature from the code in a `/sample` reference folder and integrate it with the existing project.

## Core Principles

- Import only the functional aspects of the code (logic, routes, models, utilities, etc.)
- Do NOT import the color theme, CSS theme, or visual styling from the sample
- Do NOT introduce a new framework or change the existing framework pattern
- Adapt the imported code to match the existing project's UI theme, framework conventions, and code style
- The `/sample` folder is reference-only and will be deleted after KImport is complete

## Process

1. Read and understand the feature in `/sample`
2. Identify the functional logic to bring over (endpoints, business logic, data models, etc.)
3. Integrate that logic into the existing project structure, following the project's current patterns
4. Preserve the existing project's UI theme, styling, and framework choices
5. Do NOT copy-paste stylesheets, theme files, or framework boilerplate from `/sample`

Steering - ui-guidelines.md

Location: .kiro/streeting/ui-guidelines.md

---
inclusion: manual
---

# General Rules

## Documentation

Never add any new .md file for documenting anything.

# UI Guidelines

## Modal vs Alert

When a page has any popup option, use modal instead of `js-alert` (JavaScript alert dialogs).

**Why:** Modals provide better UX with custom styling, accessibility, and control over the interaction flow.

## Notifications

For notifications and user feedback, use a top-right toaster component instead of alerts.

**Implementation:**
- Display toaster notifications in the top-right corner of the viewport
- Use appropriate toast types: success, error, warning, info
- Auto-dismiss after appropriate duration (typically 3-5 seconds)
- Allow manual dismissal via close button

Steering - Python Environment

Location: .kiro/streeting/python-environment.md

# Python Environment

Always use the conda `test12` environment Python for all operations:

- Python binary: `/opt/miniconda3/envs/test12/bin/python`
- Pip: `/opt/miniconda3/envs/test12/bin/pip`
- All CLI tools (alembic, uvicorn, etc.) should be run via `/opt/miniconda3/envs/test12/bin/<tool>` or prefixed with `/opt/miniconda3/envs/test12/bin/python -m <module>`

Do NOT use the system Python (`/Users/csp/.local/bin/python`) — it is uv-managed and will reject package installs.