pasika 0.1.6 → 0.3.0

package/dist/scripts/pasika.js

@@ -1,59 +0,0 @@
-#!/usr/bin/env node
-import path from "node:path";
-import { fileURLToPath } from "node:url";
-import { renderClaude } from "../claude/scripts/render-settings.js";
-const __filename = fileURLToPath(import.meta.url);
-const __dirname = path.dirname(__filename);
-const packageRoot = path.basename(path.dirname(__dirname)) === "dist" ? path.resolve(__dirname, "../..") : path.resolve(__dirname, "..");
-const args = process.argv.slice(2);
-const helpText = `pasika
-
-Usage:
-  pasika claude [--target-dir <path>] [--force]
-
-Platforms:
-  claude
-
-Examples:
-  npx pasika claude
-  npx pasika claude --force
-
-Behavior:
-  merges into existing .claude/settings.json by default
-  replaces it only when --force is passed
-`;
-const getFlagValue = (flag) => {
-    const index = args.indexOf(flag);
-    if (index === -1) {
-        return undefined;
-    }
-    return args[index + 1];
-};
-const hasFlag = (flag) => args.includes(flag);
-const platform = args[0];
-if (!platform || hasFlag("--help") || hasFlag("-h")) {
-    process.stdout.write(helpText);
-    process.exit(platform ? 0 : 1);
-}
-const targetDir = path.resolve(process.cwd(), getFlagValue("--target-dir") ?? ".");
-const force = hasFlag("--force");
-const run = async () => {
-    switch (platform) {
-        case "claude":
-            return renderClaude(targetDir, force, packageRoot);
-        default:
-            throw new Error(`Unknown platform: ${platform}`);
-    }
-};
-try {
-    const outputs = await run();
-    process.stdout.write(`Initialized ${platform} in ${targetDir}\n`);
-    for (const output of outputs) {
-        process.stdout.write(`Wrote ${output}\n`);
-    }
-}
-catch (error) {
-    process.stderr.write(`${error instanceof Error ? error.message : String(error)}\n`);
-    process.stderr.write(helpText);
-    process.exit(1);
-}

package/docs/agent-conventions.md

@@ -1,27 +0,0 @@
-# Agent Conventions
-
-Repo-wide engineering rules and commit hygiene for AI agents.
-
-## Data Contracts
-
-- Use Zod schemas for runtime validation; prioritize them over ad hoc type guards.
-- Prefer strict-by-default data contracts. Make fields required unless real runtime evidence shows they must be nullable or optional.
-- Do not preserve backward compatibility by default. Prefer simplifying and updating all in-repo call sites unless the user explicitly asks for compatibility.
-
-## Code Quality
-
-- Never use `eslint-disable` directives. Fix issues properly.
-- Never commit with the `--no-verify` flag.
-
-## Browser Verification
-
-- Use `agent-browser` to verify browser behavior when a task requires it.
-- Before using `agent-browser`, run `agent-browser upgrade`.
-- Run `agent-browser --help` for available commands and `agent-browser <command> --help` for command-specific usage.
-
-## Vulyk
-
-- Make Vulyk registry changes with Vulyk commands, not by editing generated files.
-- Treat `AGENTS.md`, `docs/external`, `.agents/skills`, and `.vulyk` as generated output.
-- Use ephemeral commands such as `npx vulyk@latest ...`.
-- Do not add Vulyk to `package.json` only to run the CLI.

package/docs/claude/hooks.md

@@ -1,30 +0,0 @@
-# Claude Hooks
-
-`pasika` ships the reusable shared Claude hooks.
-
-## `status-line/index.js`
-
-Displays a two-line status view with:
-
-- model name
-- current folder
-- git branch when available
-- used context percentage as a 10-segment bar
-- session cost
-- session duration
-
-## `notification.sh`
-
-Sends a desktop notification when Claude needs attention.
-
-- macOS: `terminal-notifier` with click-to-focus VS Code behavior, falls back to `osascript`
-- Linux: `notify-send`
-- Windows: PowerShell message box
-
-## `protect-files.sh`
-
-Blocks edits to:
-
-- `.env` files
-- `package-lock.json`
-- files inside `.git/`

package/docs/code-organization-guide/code-organization-guide.md

@@ -1,69 +0,0 @@
-# Code Organization Guide
-
-This guide covers how to organize code in the repository's `src/` tree — placement, extraction, and module conventions — so structure stays consistent across contributors and reviewers.
-
-## How To Organize a Component
-
-Use this no matter whether you are adding a new component or extracting from existing code; the steps below apply in any case.
-
-1. Read the [Application Architecture Reference](references/application-architecture-reference.md) to identify where the item belongs in `src/`.
-2. Pick the component's placement per the [Component Placement Rule](rules/component-placement-rule.md).
-3. Classify the component as smart or dumb per the [Smart vs Dumb Component Rule](rules/smart-vs-dumb-component-rule.md).
-4. Keep each component file to exactly one React component per the [No Mixed Concerns Rule](rules/no-mixed-concerns-rule.md).
-5. Extract interactive elements per the [Interactive Component Rule](rules/interactive-component-rule.md).
-6. Extract sole-state-owner blocks per the [Sole State Owner Rule](rules/sole-state-owner-rule.md).
-7. Extract repeated structures per the [Repeated Structure Rule](rules/repeated-structure-rule.md).
-8. Extract a group of elements when one clear component name describes it per the [Nameable Visual Concept Rule](rules/nameable-visual-concept-rule.md).
-9. For every component extracted in steps 5–8, repeat steps 2–4.
-10. Repeat steps 5–8 for an extracted component only when one of those extraction conditions applies to its JSX; stop when no new component is required.
-11. Nest a component when it gains exclusive children per the [Folder Nesting Rule](rules/folder-nesting-rule.md).
-12. Keep the component's JSX clean per the [JSX Hygiene Rule](rules/jsx-hygiene-rule.md).
-13. Follow the [Exports and Imports Rule](rules/exports-and-imports-rule.md) so every component module has predictable exports and import paths.
-
-## How To Organize a Type or Schema
-
-Use this when adding or moving a type or schema.
-
-1. Read the [Application Architecture Reference](references/application-architecture-reference.md) to identify where the item belongs in `src/`.
-2. Follow the [Types and Schemas Rule](rules/types-and-schemas-rule.md).
-3. Follow the [Exports and Imports Rule](rules/exports-and-imports-rule.md) so the type or schema module has predictable exports and import paths.
-
-## How To Organize a Constant
-
-Use this when adding or moving a constant.
-
-1. Read the [Application Architecture Reference](references/application-architecture-reference.md) to identify where the item belongs in `src/`.
-2. Follow the [Constants Rule](rules/constants-rule.md).
-3. Follow the [Exports and Imports Rule](rules/exports-and-imports-rule.md) so the constant module has predictable exports and import paths.
-
-## How To Organize a Utility
-
-Use this when adding, extracting, or moving a pure function.
-
-1. Read the [Application Architecture Reference](references/application-architecture-reference.md) to identify where the item belongs in `src/`.
-2. Follow the [Utilities Rule](rules/utilities-rule.md).
-3. Follow the [Exports and Imports Rule](rules/exports-and-imports-rule.md) so the utility module has predictable exports and import paths.
-
-## How To Organize Configuration
-
-Use this when adding or moving an application configuration module.
-
-1. Read the [Application Architecture Reference](references/application-architecture-reference.md) to identify where the item belongs in `src/`.
-2. Follow the [Configuration Rule](rules/configuration-rule.md).
-3. Follow the [Exports and Imports Rule](rules/exports-and-imports-rule.md) so the configuration module has predictable exports and import paths.
-
-## How To Organize a Custom Hook
-
-Use this when extracting or moving a custom hook.
-
-1. Read the [Application Architecture Reference](references/application-architecture-reference.md) to identify where the item belongs in `src/`.
-2. Follow the [Hook Extraction Rule](rules/hook-extraction-rule.md).
-3. Follow the [Exports and Imports Rule](rules/exports-and-imports-rule.md) so the hook module has predictable exports and import paths.
-
-## How To Organize a Locale String
-
-Use this when adding or moving user-facing text.
-
-1. Read the [Application Architecture Reference](references/application-architecture-reference.md) to identify where the item belongs in `src/`.
-2. Follow the [Locales Rule](rules/locales-rule.md).
-3. Follow the [Exports and Imports Rule](rules/exports-and-imports-rule.md) so the locale module has predictable exports and import paths.

package/docs/code-organization-guide/references/application-architecture-reference.md

@@ -1,149 +0,0 @@
-# Application Architecture Reference
-
-Use this reference to look up the canonical shape of the repository's `src/` tree and its Layer Model.
-
-## Layer Model
-
-This section describes the repository's five layers and their dependency direction. Use it to decide where a component or support file belongs and which layers it can import from.
-
-| Layer          | Path                      | Permitted contents                                                                                                                                                                     | Imports from                         |
-| -------------- | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------ |
-| `app`          | `src/app/`                | [Next.js App Router routing files](https://nextjs.org/docs/app/getting-started/project-structure#routing-files), [metadata assets](https://nextjs.org/docs/app/getting-started/project-structure#metadata-file-conventions), and [styles required by routing files](https://nextjs.org/docs/app/getting-started/css) | compositions, features, shared, root |
-| `compositions` | `src/compositions/`       | Components and support files (`hooks/`, `types/`, `schemas/`, `constants/`, `utils/`)                                                                                                  | compositions, features, shared, root |
-| `features`     | `src/features/<feature>/` | Components and support files (`hooks/`, `types/`, `schemas/`, `constants/`, `utils/`). `src/features/` itself holds feature folders only — never components or support folders         | same feature, shared, root           |
-| `shared`       | `src/shared/`             | Components and support files (`hooks/`, `types/`, `schemas/`, `constants/`, `utils/`)                                                                                                  | shared, root                         |
-| `root`         | `src/`                    | App-wide support folders: `hooks/`, `types/`, `schemas/`, `constants/`, `utils/`, `config/`, and `locales/`                                                                          | root |
-
-## Closest Common Folder (CCF)
-
-The CCF determines the placement of components, hooks, types, schemas, constants, and utilities. It is the closest folder shared by the files under `src/` that use the item.
-
-```text
-src/features/payments/payment-card.tsx
-src/features/payments/payment-history.tsx
-└─ both import StatusBadge
-
-CCF: src/features/payments/
-Location: src/features/payments/status-badge.tsx
-```
-
-For components, imports from `src/app/` and configuration modules do not affect the CCF. A component used by `src/app/` and a feature therefore stays with the feature.
-
-```text
-src/app/products/page.tsx                ─┐
-src/features/products/product-card.tsx   ─┴─ imports ProductPrice
-
-CCF and location: src/features/products/product-price.tsx
-```
-
-A component with no consumers outside `src/app/` or configuration modules stays in the feature it represents or supports. When no existing feature applies, it creates a feature folder.
-
-```text
-src/app/search/page.tsx  → SearchForm  → src/features/search/search-form.tsx
-
-src/app/account/page.tsx ─┐
-src/app/orders/page.tsx  ─┴→ AccountNav → src/features/account/account-nav.tsx
-```
-
-When a component has consumers both inside and outside `src/compositions/`, only the consumers outside `src/compositions/` count. When all consumers are in `src/compositions/`, that folder counts.
-
-```text
-src/compositions/checkout.tsx             ─┐
-src/features/payments/payment-summary.tsx ─┴→ Total → src/features/payments/total.tsx
-
-src/compositions/checkout.tsx ─┐
-src/compositions/receipt.tsx  ─┴→ Total → src/compositions/total.tsx
-```
-
-A component stays at a nested component folder, feature folder, `src/compositions/`, or `src/shared/`. A CCF of `src/features/` places it in `src/shared/`.
-
-```text
-src/features/payments/payment-card.tsx ─┐
-src/features/orders/order-card.tsx     ─┴→ StatusBadge → src/shared/status-badge.tsx
-```
-
-For a support file imported by a file under `src/app/`, use the matching root support folder, such as `src/hooks/` or `src/utils/`. Otherwise, the CCF passes through a support folder to its parent folder, and the file lives in the matching support folder directly below that parent.
-
-```text
-src/app/products/page.tsx                    → useSearch    → src/hooks/use-search.ts
-src/features/payments/hooks/use-payment.ts   → formatAmount → src/features/payments/utils/format-amount.ts
-src/features/payments/payment-card.tsx       ─┐
-src/features/orders/order-card.tsx           ─┴→ formatDate → src/utils/format-date.ts
-```
-
-## Application Structure
-
-This tree shows the canonical directory layout and naming conventions for files and folders inside `src/`. It is included so readers can verify their structure matches the project standard at a glance.
-
-```
-src/
-├── app/                                   # Next.js framework-convention files, assets, and route styles
-├── compositions/                          # Components stay flat siblings by default
-│   ├── <ComponentA>.tsx                   # Smart component (PascalCase-named)
-│   ├── <component-b>.tsx                  # Dumb component (kebab-case-named)
-│   ├── <component-part>.tsx               # Dumb component — shared by A and B, so it stays flat too
-│   ├── <NestedComponent>/                 # Smart (PascalCase-named) — or kebab-case-named for dumb; nested only once it gains exclusive children
-│   │   ├── index.ts                       # Named-re-exports only the nested parent
-│   │   ├── <NestedComponent>.tsx          # Smart (PascalCase-named) — or kebab-case-named for dumb
-│   │   ├── <nested-part>.tsx              # Exclusive child — not in index.ts
-│   │   ├── hooks/                         # Nested-scoped support folders
-│   │   ├── types/
-│   │   ├── schemas/
-│   │   ├── constants/
-│   │   └── utils/
-│   ├── hooks/                             # Composition-scoped custom hooks
-│   ├── types/                             # Composition-scoped TypeScript types
-│   ├── schemas/                           # Composition-scoped validation schemas
-│   ├── constants/                         # Composition-scoped constants
-│   └── utils/                             # Composition-scoped pure functions
-├── features/                              # Feature folders only — no components, no support folders here
-│   └── <feature>/                         # One folder per feature — a feature can hold several components
-│       ├── <ComponentA>.tsx               # Smart component (PascalCase-named)
-│       ├── <component-b>.tsx              # Dumb component (kebab-case-named)
-│       ├── <component-part>.tsx           # Dumb component — shared by A and B, so it stays flat too
-│       ├── <NestedComponent>/             # Smart (PascalCase-named) — or kebab-case-named for dumb; nested only once it gains exclusive children
-│       │   ├── index.ts                   # Named-re-exports only the nested parent
-│       │   ├── <NestedComponent>.tsx      # Smart (PascalCase-named) — or kebab-case-named for dumb
-│       │   ├── <nested-part>.tsx          # Exclusive child — not in index.ts
-│       │   ├── hooks/                     # Nested-scoped support folders
-│       │   ├── types/
-│       │   ├── schemas/
-│       │   ├── constants/
-│       │   └── utils/
-│       ├── hooks/                         # Feature-scoped custom hooks
-│       ├── types/                         # Feature-scoped TypeScript types
-│       ├── schemas/                       # Feature-scoped validation schemas
-│       ├── constants/                     # Feature-scoped constants
-│       └── utils/                         # Feature-scoped pure functions
-├── shared/                                # Components stay flat siblings by default
-│   ├── <ComponentA>.tsx                   # Smart component (PascalCase-named)
-│   ├── <component-b>.tsx                  # Dumb component (kebab-case-named)
-│   ├── <component-part>.tsx               # Dumb component — shared by A and B, so it stays flat too
-│   ├── <NestedComponent>/                 # Smart (PascalCase-named) — or kebab-case-named for dumb; nested only once it gains exclusive children
-│   │   ├── index.ts                       # Named-re-exports only the nested parent
-│   │   ├── <NestedComponent>.tsx          # Smart (PascalCase-named) — or kebab-case-named for dumb
-│   │   ├── <nested-part>.tsx              # Exclusive child — not in index.ts
-│   │   ├── hooks/                         # Nested-scoped support folders
-│   │   ├── types/
-│   │   ├── schemas/
-│   │   ├── constants/
-│   │   └── utils/
-│   ├── hooks/                             # Shared-scoped custom hooks
-│   ├── types/                             # Shared-scoped TypeScript types
-│   ├── schemas/                           # Shared-scoped validation schemas
-│   ├── constants/                         # Shared-scoped constants
-│   └── utils/                             # Shared-scoped pure functions
-├── hooks/                                 # App-wide custom hooks
-├── types/                                 # App-wide TypeScript types
-├── schemas/                               # App-wide validation schemas
-├── constants/                             # App-wide constants
-├── utils/                                 # App-wide pure functions
-├── config/                                # Configuration modules that centralize application behavior
-│   └── <config-name>/                     # One folder per configuration module
-│       ├── index.ts                       # Configuration-module entry point
-│       ├── types/                         # Config-only TypeScript types
-│       ├── schemas/                       # Config-only validation schemas
-│       └── utils/                         # Config-only pure functions
-└── locales/                               # App-wide locale strings
-    └── index.ts                           # Single locale-registration file
-```

package/docs/code-organization-guide/rules/component-placement-rule.md

@@ -1,119 +0,0 @@
-# Component Placement Rule
-
-Without clear placement, it is hard to tell where a component belongs and reuse can create tangled dependencies. This rule gives each component a specific place in the application structure.
-
-- A component that imports from two or more feature folders MUST live in `src/compositions/` and is, by definition, a composition.
-- A component with no consumers outside `src/app/` or configuration modules, and that does not import from two or more feature folders, MUST live in the feature folder it represents or supports. If no existing feature applies, it MUST introduce a new feature folder.
-- A component with at least one consumer outside `src/app/` and configuration modules MUST live in its CCF, calculated without imports from `src/app/` or configuration modules.
-- When calculating a component's CCF, consumers under `src/compositions/` MUST count only when no consumer is outside `src/compositions/`.
-- A component whose CCF is `src/features/` MUST live in `src/shared/`.
-- `src/app/` MUST contain [Next.js App Router framework-convention files and assets](https://nextjs.org/docs/app/getting-started/project-structure#routing-files), plus styles required by routing files, but MUST NOT contain ordinary components or support folders.
-## Incorrect — Cross-Feature Component Duplicated
-
-```text
-src/features/
-├── donation/
-│   ├── DonationCard.tsx
-│   └── status-badge.tsx
-└── stream/
-    ├── StreamCard.tsx
-    └── status-badge.tsx
-```
-
-Why: two feature folders contain duplicate copies because neither feature may import from the other.
-
-## Correct — Cross-Feature Component in `src/shared/`
-
-```text
-src/
-├── features/
-│   ├── donation/
-│   │   └── DonationCard.tsx
-│   └── stream/
-│       └── StreamCard.tsx
-└── shared/
-    └── status-badge.tsx
-```
-
-Why: the component's CCF is `src/features/`, so it lives in `src/shared/`.
-
-## Incorrect — Multi-Feature Composition Inside One Feature
-
-```tsx
-// src/features/billing/billing-aggregate-view.tsx
-import { BillingPanel } from "./BillingPanel";
-import { HomeBanner } from "@/features/home/HomeBanner";
-```
-
-Why: the component imports from two feature folders, so it cannot live in either feature folder.
-
-## Correct — Multi-Feature Component in `src/compositions/`
-
-```tsx
-// src/compositions/billing-aggregate-view.tsx
-import { BillingPanel } from "@/features/billing/BillingPanel";
-import { HomeBanner } from "@/features/home/HomeBanner";
-```
-
-Why: the component imports from two feature folders, so it lives in `src/compositions/`.
-
-## Incorrect — Ordinary Component Under `src/app/`
-
-```text
-src/app/contact/
-├── _components/
-│   └── contact-page-content.tsx
-└── page.tsx
-```
-
-Why: the route folder contains ordinary component structure even though `src/app/` is reserved for framework-convention files, assets, and styles.
-
-## Correct — `src/app/` Imports a Page Composition
-
-```text
-src/
-├── app/contact/
-│   └── page.tsx
-├── compositions/
-│   └── contact-page-content.tsx
-└── features/
-    ├── contact/
-    │   └── contact-information.tsx
-    └── location/
-        └── office-location.tsx
-```
-
-```tsx
-// src/compositions/contact-page-content.tsx
-import { ContactInformation } from "@/features/contact/contact-information";
-import { OfficeLocation } from "@/features/location/office-location";
-import { locales } from "@/locales";
-
-export function ContactPageContent(): React.JSX.Element {
-  return (
-    <main>
-      <header>
-        <h1>{locales.contactPageTitle}</h1>
-        <p>{locales.contactPageDescription}</p>
-      </header>
-      <section>
-        <h2>{locales.contactInformationHeading}</h2>
-        <ContactInformation />
-      </section>
-      <section>
-        <h2>{locales.officeLocationHeading}</h2>
-        <OfficeLocation />
-      </section>
-    </main>
-  );
-}
-
-// src/app/contact/page.tsx
-import { ContactPageContent } from "@/compositions/contact-page-content";
-
-export default function Page(): React.JSX.Element {
-  return <ContactPageContent />;
-}
-```
-
-Why: `src/app/` contains the routing file while the composition provides the contact page layout and combines components from two feature folders.

package/docs/code-organization-guide/rules/configuration-rule.md

@@ -1,42 +0,0 @@
-# Configuration Rule
-
-Configuration modules centralize values that control application behavior. This rule keeps each module and the files that only support it together in `src/config/`.
-
-- A configuration module is an app-wide module that selects or parameterizes application behavior.
-- All configuration modules MUST live in `src/config/`.
-- A configuration module MUST be one `src/config/<config-name>/` folder with `index.ts` as its entry point.
-- A type, schema, or utility used only to implement one configuration module MUST be extracted even with one consumer.
-- An extracted configuration type, schema, or utility MUST live in its matching dedicated folder under `src/config/<config-name>/`.
-- An extracted configuration type, schema, or utility MUST move to its matching root support folder when a consumer outside its configuration module imports it.
-
-## Incorrect — Supporting Schema Outside Its Config Folder
-
-```text
-src/config/
-├── home-feed/
-│   └── index.ts
-└── home-feed-schema.ts
-```
-
-Why: the schema sits outside the `home-feed/` configuration folder.
-
-## Correct — Configuration Module with Its Supporting Schema
-
-```text
-src/config/
-└── home-feed/
-    ├── index.ts
-    └── schemas/
-        └── index.ts
-```
-
-```ts
-// src/config/home-feed/index.ts
-import { homeFeedConfigSchema } from "./schemas";
-
-export const homeFeedConfig = homeFeedConfigSchema.parse({
-  freshVideoMaxAgeDays: 7,
-});
-```
-
-Why: the configuration module and its supporting schema are grouped in the same configuration folder.

package/docs/code-organization-guide/rules/constants-rule.md

@@ -1,74 +0,0 @@
-# Constants Rule
-
-Duplicated constants are hard to keep in sync, while extracting every single-use value creates unnecessary files. This rule keeps reused constants in one file and leaves single-use values close to their consumer.
-
-- A value MUST remain in its declaring component or file until another file imports it independently; it MUST then be extracted as a constant.
-- Extracted constants MUST live in a `constants/` folder at the closest common folder (CCF) of their consumers.
-- Consumers MUST import an extracted constant through the `index.ts` in that constant's `constants/` folder.
-- A `constants/` folder MUST either define its constants directly in `index.ts` or group related constants in kebab-case files that `index.ts` named-re-exports.
-- When a constant's CCF is `src/features/`, it MUST move to `src/constants/`.
-- A constant MAY live in `src/config/<module>/` instead of a `constants/` folder when a developer determines that it configures application behavior and is best understood alongside the configuration that parameterizes it, even when consumers exist outside the config module.
-
-## Incorrect — Constant Imported Without `constants/index.ts`
-
-```ts
-// src/features/billing/constants/max-retries.ts
-export const maxRetries = 3;
-```
-
-```ts
-// src/features/billing/hooks/use-retry-payment.ts
-import { maxRetries } from "../constants/max-retries";
-```
-
-Why: the consumer bypasses the feature's `constants/index.ts`.
-
-## Correct — Grouped Constants Re-Exported from `constants/index.ts`
-
-```ts
-// src/features/billing/constants/retry.ts
-export const maxRetries = 3;
-export const retryDelayMs = 1_000;
-
-// src/features/billing/constants/index.ts
-export { maxRetries, retryDelayMs } from "./retry";
-```
-
-```ts
-// src/features/billing/hooks/use-retry-payment.ts
-import { maxRetries } from "../constants";
-```
-
-Why: the constants are available through the feature's `constants/index.ts`.
-
-## Incorrect — Feature and Composition Constant Kept in a Feature
-
-```ts
-// src/features/billing/constants/index.ts
-export const paymentRetryDelayMs = 1_000;
-
-// src/features/billing/hooks/use-retry-payment.ts
-import { paymentRetryDelayMs } from "../constants";
-
-// src/compositions/BillingDashboard.tsx
-import { paymentRetryDelayMs } from "@/features/billing/constants";
-```
-
-Why: the feature and composition have `src/` as their CCF, but the constant remains in the billing feature.
-
-## Correct — Feature and Composition Constant in `src/constants/`
-
-```ts
-// src/constants/index.ts
-export const paymentRetryDelayMs = 1_000;
-```
-
-```tsx
-// src/features/billing/hooks/use-retry-payment.ts
-import { paymentRetryDelayMs } from "@/constants";
-
-// src/compositions/BillingDashboard.tsx
-import { paymentRetryDelayMs } from "@/constants";
-```
-
-Why: the feature and composition have `src/` as their CCF, so the constant lives in `src/constants/`.

package/docs/code-organization-guide/rules/exports-and-imports-rule.md

@@ -1,84 +0,0 @@
-# Exports and Imports Rule
-
-Without consistent exports, import paths, and layer boundaries, it is harder to tell what a file contains and which files may depend on it. This rule gives each file a predictable export style and keeps imports consistent with the application structure.
-
-- A file that exports values MUST use named exports unless a framework or third-party package requires a different export style for that file.
-- Imports MUST use relative paths for the same folder, a direct subfolder, or one folder up.
-- Imports MUST use the `@/*` alias for anything beyond one folder up.
-- A file under `src/compositions/` MUST NOT import from `src/app/`.
-- A file in a feature folder MUST NOT import from another feature folder, `src/compositions/`, or `src/app/`.
-- A file under `src/shared/` MUST NOT import from `src/app/`, `src/compositions/`, or a feature folder.
-- A file in the `root` layer MUST NOT import from `src/app/`, `src/compositions/`, a feature folder, or `src/shared/`.
-- A configuration module MUST import only from root support folders and its own files.
-## Incorrect — Single-Export Utility Uses a Default Export
-
-```ts
-// src/utils/format-duration.ts
-export default function formatDuration(seconds: number): string {
-  const minutes = Math.floor(seconds / 60);
-  const remainder = seconds % 60;
-  return `${minutes}:${String(remainder).padStart(2, "0")}`;
-}
-```
-
-Why: files use named exports even when they expose one item.
-
-## Correct — Single-Export Utility Uses a Named Export
-
-```ts
-// src/utils/format-duration.ts
-export function formatDuration(seconds: number): string {
-  const minutes = Math.floor(seconds / 60);
-  const remainder = seconds % 60;
-  return `${minutes}:${String(remainder).padStart(2, "0")}`;
-}
-```
-
-Why: the utility uses the same named-export form as every other file that does not have a package-required export contract.
-
-## Incorrect — Deep Relative Path
-
-```ts
-// src/features/stream/StreamBoard/schedule.ts
-import { debounce } from "../../../utils/debounce";
-```
-
-Why: reaching more than one folder up hides the cross-scope dependency in relative path traversal.
-
-## Correct — Alias Across Scopes and Relative Paths Nearby
-
-```ts
-// src/features/stream/StreamBoard/schedule.ts
-import { debounce } from "@/utils/debounce";
-import { formatSlot } from "./utils/format-slot";
-import { type StreamSlot } from "./types";
-import { buildSchedule } from "../schedule-builder";
-```
-
-Why: the alias identifies the distant dependency while nearby files keep short relative paths.
-
-## Incorrect — Next.js Page Uses a Named Export
-
-```tsx
-// src/app/contact/page.tsx
-import { locales } from "@/locales";
-
-export function Page(): React.JSX.Element {
-  return <main>{locales.contactUs}</main>;
-}
-```
-
-Why: Next.js requires a `page.tsx` file to default-export its page component.
-
-## Correct — Next.js Page Uses a Default Export
-
-```tsx
-// src/app/contact/page.tsx
-import { locales } from "@/locales";
-
-export default function Page(): React.JSX.Element {
-  return <main>{locales.contactUs}</main>;
-}
-```
-
-Why: the page follows the export contract Next.js requires.