pasika 0.1.4 → 0.2.0

package/dist/claude/scripts/render-settings.js

@@ -1,145 +0,0 @@
-import { access, copyFile, mkdir, readFile, writeFile } from "node:fs/promises";
-import path from "node:path";
-import { constants } from "node:fs";
-import { fileURLToPath } from "node:url";
-const __filename = fileURLToPath(import.meta.url);
-const __dirname = path.dirname(__filename);
-const isRecord = (value) => typeof value === "object" && value !== null;
-const fileExists = async (filePath) => {
-    try {
-        await access(filePath, constants.F_OK);
-        return true;
-    }
-    catch {
-        return false;
-    }
-};
-const isClaudeSettings = (value) => {
-    if (!isRecord(value)) {
-        return false;
-    }
-    const hooks = value.hooks;
-    const statusLine = value.statusLine;
-    if (!isRecord(hooks) || !isRecord(statusLine) || typeof statusLine.command !== "string") {
-        return false;
-    }
-    const notification = hooks.Notification;
-    if (notification !== undefined && !Array.isArray(notification)) {
-        return false;
-    }
-    const preToolUse = hooks.PreToolUse;
-    return preToolUse === undefined || Array.isArray(preToolUse);
-};
-const readClaudeSettings = async (templatePath) => {
-    const templateRaw = await readFile(templatePath, "utf8");
-    const parsed = JSON.parse(templateRaw);
-    if (!isClaudeSettings(parsed)) {
-        throw new Error("Claude settings template has an invalid shape.");
-    }
-    return parsed;
-};
-const mergeStringArrays = (left = [], right = []) => Array.from(new Set([...left, ...right]));
-const upsertHookMatcherEntry = (entries, matcher, command) => {
-    const nextEntries = [...(entries ?? [])];
-    const existingIndex = nextEntries.findIndex((entry) => (entry.matcher ?? "") === matcher);
-    const hook = { type: "command", command };
-    if (existingIndex === -1) {
-        nextEntries.push({ matcher, hooks: [hook] });
-        return nextEntries;
-    }
-    const existingEntry = nextEntries[existingIndex];
-    nextEntries[existingIndex] = { ...existingEntry, hooks: [hook] };
-    return nextEntries;
-};
-const mergeClaudeSettings = (existingSettings, baseSettings, packagePath) => {
-    const notificationCommand = `${packagePath}/hooks/notification.sh`;
-    const protectFilesCommand = `${packagePath}/hooks/protect-files.sh`;
-    const statusLineCommand = `node ${packagePath}/hooks/status-line/index.js`;
-    return {
-        ...existingSettings,
-        $schema: baseSettings.$schema ?? existingSettings.$schema,
-        attribution: { ...(baseSettings.attribution ?? {}), ...(existingSettings.attribution ?? {}) },
-        permissions: {
-            ...(existingSettings.permissions ?? {}),
-            ...(baseSettings.permissions ?? {}),
-            ask: mergeStringArrays(baseSettings.permissions?.ask, existingSettings.permissions?.ask),
-            deny: mergeStringArrays(baseSettings.permissions?.deny, existingSettings.permissions?.deny),
-        },
-        hooks: {
-            ...existingSettings.hooks,
-            Notification: upsertHookMatcherEntry(existingSettings.hooks.Notification, "", notificationCommand),
-            PreToolUse: upsertHookMatcherEntry(existingSettings.hooks.PreToolUse, "Edit|Write", protectFilesCommand),
-        },
-        statusLine: {
-            ...existingSettings.statusLine,
-            ...baseSettings.statusLine,
-            type: "command",
-            command: statusLineCommand,
-        },
-    };
-};
-export const renderClaude = async (targetDir, force, packageRoot) => {
-    const templatePath = path.join(packageRoot, "claude/settings.base.json");
-    const baseSettings = await readClaudeSettings(templatePath);
-    const packagePath = "./node_modules/pasika/claude";
-    const notificationEntries = upsertHookMatcherEntry(baseSettings.hooks.Notification, "", `${packagePath}/hooks/notification.sh`);
-    const preToolUseEntries = upsertHookMatcherEntry(baseSettings.hooks.PreToolUse, "Edit|Write", `${packagePath}/hooks/protect-files.sh`);
-    const settings = {
-        ...baseSettings,
-        hooks: {
-            ...baseSettings.hooks,
-            Notification: notificationEntries,
-            PreToolUse: preToolUseEntries,
-        },
-        statusLine: {
-            ...baseSettings.statusLine,
-            type: "command",
-            command: `node ${packagePath}/hooks/status-line/index.js`,
-        },
-    };
-    const outputDir = path.join(targetDir, ".claude");
-    const outputPath = path.join(outputDir, "settings.json");
-    const hooksOutputDir = path.join(outputDir, "hooks");
-    await mkdir(outputDir, { recursive: true });
-    await mkdir(hooksOutputDir, { recursive: true });
-    const finalSettings = !force && (await fileExists(outputPath))
-        ? mergeClaudeSettings(await readClaudeSettings(outputPath), settings, packagePath)
-        : settings;
-    await writeFile(outputPath, `${JSON.stringify(finalSettings, null, 2)}\n`, "utf8");
-    const outputs = [outputPath];
-    const hookDocFiles = ["AGENTS.md", "CLAUDE.md"];
-    for (const fileName of hookDocFiles) {
-        const sourcePath = path.join(packageRoot, "claude/hooks", fileName);
-        if (!(await fileExists(sourcePath))) {
-            continue;
-        }
-        const destinationPath = path.join(hooksOutputDir, fileName);
-        await copyFile(sourcePath, destinationPath);
-        outputs.push(destinationPath);
-    }
-    return outputs;
-};
-const isDirectRun = process.argv[1] ? path.resolve(process.argv[1]) === __filename : false;
-if (isDirectRun) {
-    const args = process.argv.slice(2);
-    const getArgValue = (flag) => {
-        const index = args.indexOf(flag);
-        if (index === -1) {
-            return undefined;
-        }
-        return args[index + 1];
-    };
-    const targetDir = path.resolve(process.cwd(), getArgValue("--target-dir") ?? ".");
-    const force = args.includes("--force");
-    const packageRoot = path.resolve(__dirname, "../..");
-    try {
-        const outputs = await renderClaude(targetDir, force, packageRoot);
-        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.exit(1);
-    }
-}

package/dist/eslint/pasika/rules/organization-imports.d.ts

@@ -1,2 +0,0 @@
-import type { Rule } from "eslint";
-export declare const organizationImportsRule: Rule.RuleModule;

package/dist/eslint.config.js

@@ -1,7 +0,0 @@
-import { RuleSeverity, styleguide } from "zirka";
-const { eslintConfig } = styleguide({
-    node: RuleSeverity.Error,
-    typescript: RuleSeverity.Error,
-    ignores: ["dist/**", "node_modules/**", "prettier.config.mjs"],
-});
-export default eslintConfig;

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,21 +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.
-
-## 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,65 +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.
-
-For every JavaScript or TypeScript module covered by this guide, also follow the [Exports and Imports Rule](rules/exports-and-imports-rule.md).
-
-## 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 choose the right layer and scope.
-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. Follow the [Native Prop Forwarding Rule](rules/native-prop-forwarding-rule.md) when a `src/shared/` component renders the same intrinsic root element in every rendered result, so its native prop contract remains available.
-5. Keep each component file to exactly one React component per the [No Mixed Concerns Rule](rules/no-mixed-concerns-rule.md).
-6. Extract interactive elements per the [Interactive Component Rule](rules/interactive-component-rule.md).
-7. Extract sole-state-owner blocks per the [Sole State Owner Rule](rules/sole-state-owner-rule.md).
-8. Extract repeated structures per the [Repeated Structure Rule](rules/repeated-structure-rule.md).
-9. Extract a group of elements when one clear component name describes it per the [Nameable Visual Concept Rule](rules/nameable-visual-concept-rule.md).
-10. For every component extracted in steps 6–9, repeat steps 2–5.
-11. Repeat steps 6–9 for an extracted component only when its JSX has an applicable trigger; stop when no new component is required.
-12. Nest a component when it gains exclusive children per the [Folder Nesting Rule](rules/folder-nesting-rule.md).
-13. Keep the component's JSX clean per the [JSX Hygiene Rule](rules/jsx-hygiene-rule.md).
-
-## 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 choose the right layer and scope.
-2. Follow the [Types and Schemas Rule](rules/types-and-schemas-rule.md).
-
-## 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 choose the right layer and scope.
-2. Follow the [Constants Rule](rules/constants-rule.md).
-
-## 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 choose the right layer and scope.
-2. Follow the [Utilities Rule](rules/utilities-rule.md).
-
-## How To Organize Configuration
-
-Use this when adding or moving an application configuration object.
-
-1. Read the [Application Architecture Reference](references/application-architecture-reference.md) to choose the right layer and scope.
-2. Follow the [Configuration Rule](rules/configuration-rule.md).
-
-## 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 choose the right layer and scope.
-2. Follow the [Hook Extraction Rule](rules/hook-extraction-rule.md).
-
-## 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 choose the right layer and scope.
-2. Follow the [Locales Rule](rules/locales-rule.md).

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

@@ -1,107 +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 four layers, root support scope, and dependency direction. Use it to decide where a component or support file belongs and which layers it can import from.
-
-| Layer or scope | Path                      | Permitted contents                                                                                                                                                                     | Imports from                         |
-| -------------- | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------ |
-| `app`          | `src/app/`                | Next.js App Router framework-convention files and assets, plus styles required by routing files                                                                                        | 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 files (`hooks/`, `types/`, `schemas/`, `constants/`, `utils/`), `locales/`, and `config/`                                                                             | root support folders; a configuration module may also import files in its own `src/config/<config-name>/` directory |
-
-Root support folders are `hooks/`, `types/`, `schemas/`, `constants/`, `utils/`, `config/`, and `locales/`.
-
-## Closest Common Folder (CCF)
-
-The CCF is the deepest eligible folder that contains every consumer of an item.
-
-- Eligible folders are a nested component directory, a feature folder, a configuration-object directory, `src/features/`, `src/compositions/`, `src/shared/`, and `src/`.
-- Support folders and `src/app/` do not determine the CCF. A consumer in a support folder counts at its enclosing eligible component, feature, composition, shared, configuration-object, or root scope. A Next.js route-file consumer counts at `src/` unless a rule explicitly excludes it. `src/features/` is a non-placeable CCF boundary; the relevant placement rule maps it to a destination.
-- A consumer is a module under `src/` that uses the item. For initial placement only, include the origin module that contains the item before extraction; omit it after extraction. Apply a rule's import exclusions before calculating the CCF, then use it for placement unless that rule states otherwise.
-
-## 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
-│   ├── globals.css                        # Global stylesheet imported by the root layout
-│   ├── layout.tsx                         # Root layout
-│   └── <route>/                           # Next.js App Router routing files
-├── 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 objects that centralize application behavior
-│   └── <config-name>/                     # One folder per configuration object
-│       ├── index.ts                       # Config object
-│       ├── hooks/                         # Config-only custom hooks
-│       ├── types/                         # Config-only TypeScript types
-│       ├── schemas/                       # Config-only validation schemas
-│       ├── constants/                     # Config-only constants
-│       └── 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,135 +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 routing UI file is a Next.js App Router UI file, excluding request handlers and metadata files. A Next.js `layout.tsx` routing UI file MAY render the layout required by its route segment and `children`. Any other routing UI file MAY import root support modules and directly render one feature component, one composition, or one shared component, but MUST NOT own state, callbacks, effects, or page layout.
-- A routing UI file other than `layout.tsx` that needs state, callbacks, effects, or page layout MUST delegate that work to a component in `src/compositions/`.
-- Any other component that imports from two or more feature folders MUST live in `src/compositions/` and is, by definition, a composition.
-- A component whose only consumers are routing files and that does not import from two or more feature folders MUST live in the feature folder whose behavior it implements. A component implements a feature when it reads that feature's data or exposes that feature's actions. If it implements no feature and only one routing file imports it, it MUST introduce a new feature folder for that route; if routing files for two or more routes import it, it MUST live in `src/shared/`. This rule does not apply to Next.js routing files themselves.
-- A component with at least one consumer other than a routing file MUST live in the closest common folder (CCF) of its non-routing consumers.
-- A new component with no consumers and fewer than two feature-folder imports MUST start in the existing feature folder it belongs to, or in a new feature folder when it introduces a new feature. A new component with no feature-specific behavior or data MAY start in `src/shared/` only when it imports no feature folders; otherwise it starts in the feature it imports from.
-- Imports from routing files in `src/app/` MUST NOT count as component consumers or affect CCF calculation.
-- Imports from configuration modules MUST NOT count as component consumers or affect CCF calculation.
-- When a component is imported both inside and outside `src/compositions/`, its CCF MUST be calculated only from imports outside `src/compositions/`.
-- When a component is imported only in `src/compositions/`, its CCF MUST be calculated from those imports.
-- When a component’s CCF is `src/features/`, it MUST live in `src/shared/`.
-- When a component’s CCF is `src/`, it MUST live in `src/shared/`.
-- When a component’s CCF is a nested component directory, it MUST start flat in that directory unless the Folder Nesting Rule requires nesting.
-- When a component’s CCF is a feature folder, `src/compositions/`, or `src/shared/`, it MUST start flat in that folder unless the Folder Nesting Rule requires nesting.
-- `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.
-- A JavaScript or TypeScript module under `src/app/` MUST NOT import modules under `src/` except from `src/compositions/`, `src/features/`, `src/shared/`, and root support folders.
-- A JavaScript or TypeScript module under `src/compositions/` MUST NOT import modules under `src/` except from `src/compositions/`, feature folders, `src/shared/`, and root support folders.
-- A JavaScript or TypeScript module in a feature folder MUST NOT import modules under `src/` except from the same feature folder, `src/shared/`, and root support folders.
-- A JavaScript or TypeScript module under `src/shared/` MUST NOT import modules under `src/` except from `src/shared/` and root support folders.
-- A JavaScript or TypeScript module in a root support folder MUST NOT import modules under `src/` except from root support folders. Any module under `src/config/<config-name>/` MAY also import files under that same configuration-object directory.
-- ESLint MUST enforce these import restrictions for JavaScript and TypeScript modules under `src/`.
-
-## 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 routing files.
-
-## Correct — Thin Route 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 data-testid="contact-page-content">
-      <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: the routing file remains thin while the page 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 objects centralize values that control application behavior. This rule keeps each object and the files that only support it together in `src/config/`.
-
-- A configuration object is an app-wide object that selects or parameterizes application behavior. Feature options and domain values are not configuration objects.
-- All configuration objects MUST live in `src/config/`.
-- A configuration object MUST use `src/config/<config-name>/index.ts`.
-- A configuration support file is a hook, type, schema, constant, or utility used only to implement one configuration object; config-only extraction applies even with one consumer.
-- A configuration support file MUST live in its matching dedicated folder under `src/config/<config-name>/`.
-- A configuration support file remains in that configuration-object directory while every consumer is in that directory; it MUST move to its matching root support folder at the root CCF when any consumer is outside 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 Object 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 object and its supporting schema are grouped in the same configuration folder.