@leejungkiin/awkit 1.7.4 → 1.7.6

package/docs/history/PRD.v1.md

@@ -0,0 +1,55 @@
+# Product Requirements Document (PRD) — MemoizedFibonacci
+
+## Revision History
+
+| Version | Date | Author | Description |
+| :--- | :--- | :--- | :--- |
+| 1.0 | 2026-06-22 | Antigravity Orchestrator | Initial draft for MemoizedFibonacci feature. |
+
+---
+
+## 1. Vision & Objectives
+
+* **Project Summary:** The `MemoizedFibonacci` feature provides a highly optimized, high-performance utility class/module for calculating Fibonacci sequences. It leverages an advanced caching (memoization) mechanism to avoid the exponential time complexity $O(2^n)$ associated with naive recursive methods, turning sequence generation into a linear time $O(n)$ or constant-time $O(1)$ operation for subsequent lookups.
+* **Problem Statement:** Standard recursive calculations of Fibonacci numbers quickly exhaust CPU resources and crash due to call stack size limits or integer overflows when $n \ge 79$ in standard floating-point representation. Naive memory caches can also grow indefinitely, leading to memory leaks in server environments.
+* **Target Audience:** Core application developers, backend engineers running mathematical modeling services, and background agents requiring sequence calculations.
+
+---
+
+## 2. Core Principles & Philosophy
+
+* **Performance & Scalability:** Constant lookups $O(1)$ for cached values, linear complexity $O(n)$ for first-time calculations.
+* **Robustness & Accuracy:** Complete support for `BigInt` calculations to prevent integer overflow beyond JS safe limit ($n > 78$).
+* **Memory Safety & Self-Regulation:** Integrated Least Recently Used (LRU) cache eviction strategy to guarantee a fixed maximum memory footprint.
+* **Non-Blocking Operation:** Heavy calculations ($n \ge 100,000$) must run asynchronously (chunked loops or offloaded execution) to prevent thread/event-loop blockage.
+
+---
+
+## 3. Scope & Feature List
+
+### In Scope
+* **Multiple Calculation Modes:** Synchronous calculations for small inputs; asynchronous (non-blocking) computation for larger values.
+* **Flexible Precision:** Standard JS numbers for fast calculations ($n \le 78$) and `BigInt` for arbitrarily large numbers.
+* **LRU Caching Strategy:** A bounded in-memory cache that automatically evicts least recently accessed Fibonacci numbers when the maximum cache capacity is reached.
+* **Cache Metrics:** Reporting of cache metrics such as hit rate, miss rate, current size, and eviction count.
+* **Resource Guardrails:** Hard limits on inputs to prevent CPU exhaustion.
+
+### Out of Scope
+* **Negative/Fractional Fibonacci:** No support for negative numbers or fractional inputs (standard integer sequence only).
+* **Distributed Cache integration:** No built-in Redis/Memcached integration (limited to localized, bounded memory cache with extensible hooks).
+
+---
+
+## 4. Key Performance Indicators (KPIs)
+
+* **Execution Time (Cached):** Sub-microsecond response time for any cached value.
+* **Execution Time (Uncached):** Linear scaling $O(n)$. Computing $F(10000)$ uncached must complete in under 5 milliseconds.
+* **Call Stack Safety:** Zero recursion-based Call Stack Size Exceeded errors.
+* **Memory Limit:** Strict enforcement of maximum cache entries (e.g. defaults to 1,000 values), keeping peak memory consumption under 25MB even for large BigInts.
+
+---
+
+## 5. Anti-Patterns (What NOT to do)
+* Do not use recursive calls without tail call optimization or loop conversion. Recursion is forbidden for calculations.
+* Do not store calculated BigInt values as standard floats since precision is lost.
+* Do not allow the cache size to grow indefinitely (bounded cache is mandatory).

package/docs/history/PRD.v2.md

@@ -0,0 +1,57 @@
+# Product Requirement Document (PRD) - GreetingApp
+
+## Revision History
+| Version | Date | Description | Author |
+|---|---|---|---|
+| v1.0 | 2026-06-22 | Initial PRD for GreetingApp | Antigravity Orchestrator |
+
+---
+
+## 1. Executive Summary
+GreetingApp is a micro-application designed to deliver personalized, localized, and dynamic greetings to users. It adapts to the user's name, current time of day, and language preferences.
+
+## 2. Objectives & Goals
+- Provide dynamic greetings based on user local time (Morning, Afternoon, Evening, Night).
+- Support multi-language greetings (English, Vietnamese, Japanese).
+- Track user greeting history and statistics.
+- Expose both CLI and REST API interfaces.
+
+## 3. User Personas & Use Cases
+- **End User:** Wants to see a welcoming, contextual message when logging in or using the CLI.
+- **Developer:** Wants an easy-to-integrate greeting microservice API for downstream services.
+
+## 4. Functional Requirements
+1. **Dynamic Greeting Generation:**
+   - Detects local time of user.
+   - Personalizes with name (fallback to "Guest").
+2. **Localization (i18n):**
+   - Supports: English (`en`), Vietnamese (`vi`), Japanese (`ja`).
+3. **Greeting Analytics / History:**
+   - Stores logs of generated greetings (User, Timestamp, Language).
+   - Exposes statistics (e.g., total greetings generated, most active user).
+4. **Interfaces:**
+   - Command Line Interface (CLI): `awkit greet --name=Alice`
+   - REST API endpoint: `GET /api/greet?name=Alice&lang=vi`
+
+## 5. Non-Functional Requirements
+- **Performance:** Response time for greeting generation under 50ms.
+- **Reliability:** Storage fallback to memory if database/file storage is offline.
+- **Extensibility:** Easy configuration to add new languages.
+
+## 6. System Flow & Sequence Diagram
+```mermaid
+sequenceDiagram
+    autonumber
+    actor User
+    participant Client as CLI / API Client
+    participant Engine as Greeting Engine
+    participant DB as Storage / History DB
+
+    User->>Client: Triggers greeting command/request (name, lang)
+    Client->>Engine: Resolve greeting configuration
+    Engine->>Engine: Validate input & detect Time of Day
+    Engine->>DB: Log transaction (user, time, format)
+    DB-->>Engine: Log confirmation
+    Engine->>Client: Return formatted greeting string
+    Client->>User: Display greeting output
+```

package/docs/history/implementation_plan.v1.md

@@ -1,58 +1,62 @@
-# Add Game Development Skills (Unity, Godot, Expo)
+# Implementation Plan - GreetingApp Feature
 
-Implement dedicated game development skills inside `main-awf/skills` to enhance the orchestrator's capability in building games using Unity, Godot, and Expo.
-
-## User Review Required
-
-> [!NOTE]
-> All new skills will be created directly in `skills/` of `main-awf` workspace and then deployed to `~/.gemini/antigravity` via `awkit install`.
-
-## Proposed Changes
-
-### AWKit Skills
+## Revision History
+| Version | Date | Description | Author |
+|---|---|---|---|
+| v1.0 | 2026-06-22 | Initial implementation plan for GreetingApp | Antigravity Orchestrator |
 
 ---
 
-#### [NEW] [unity-game-development/SKILL.md](file:///Users/trungkientn/Dev/NodeJS/main-awf/skills/unity-game-development/SKILL.md)
-Contains high-density instructions for Unity game development, enforcing:
-- C# coding style (PascalCase public, camelCase private, `m_` fields prefix).
-- Component-based architecture and ScriptableObjects for data-driven game structures.
-- Performance optimization: avoiding `Find`/`GetComponent` in hot paths (`Update()`), caching, object pooling.
-- Separate Editor code via `#if UNITY_EDITOR`.
-- Direct Unity MCP server integration.
-
-#### [NEW] [godot-game-development/SKILL.md](file:///Users/trungkientn/Dev/NodeJS/main-awf/skills/godot-game-development/SKILL.md)
-Contains guidelines for Godot 4.x game development, enforcing:
-- Godot 4 API standards (rejecting Godot 3 syntax).
-- GDScript style preferences (`@export`, `@onready`, `await` signals).
-- Composition-first scene tree structure over deep class inheritance.
-- Signal connection best practices (`signal.connect(callback)`).
-- Physics and locomotion handling via parameterless `move_and_slide()`.
-
-#### [NEW] [expo-game-development/SKILL.md](file:///Users/trungkientn/Dev/NodeJS/main-awf/skills/expo-game-development/SKILL.md)
-Contains instructions for Expo/React Native game development, covering:
-- High-frequency drawing techniques (React Native Skia, Expo GL/Three.js).
-- State optimization: keeping physics/game tick loop decoupled from heavy React re-renders.
-- User input handling (React Native Gesture Handler).
-- Game loop implementations using `requestAnimationFrame`.
-- Asset management and sound effects via `expo-av`.
+## 1. Objectives
+Implement the GreetingApp feature within the `main-awf` workspace, integrating:
+- A shared Greeting Engine at `core/GreetingEngine`.
+- CLI Interface command `awkit greet` in `bin/awk.js`.
+- REST API endpoint `GET /api/greet` in `symphony/app/api/greet/route.js`.
+- Light history logging via JSON Lines at `~/.gemini/antigravity/greeting_history.jsonl` (and local project fallback).
 
 ---
 
-#### [MODIFY] [CATALOG.md](file:///Users/trungkientn/Dev/NodeJS/main-awf/skills/CATALOG.md)
-Add the three new skills to the active skills table.
-
-#### [MODIFY] [TRIGGER_INDEX.md](file:///Users/trungkientn/Dev/NodeJS/main-awf/skills/TRIGGER_INDEX.md)
-Register keywords and triggers for the new game skills.
+## 2. Proposed Changes
+
+### Phase A: Core Engine and Locales
+#### 1. Locales Definition
+Create locales JSON files under `core/GreetingEngine/locales/`:
+- `en.json`: English templates.
+- `vi.json`: Vietnamese templates.
+- `ja.json`: Japanese templates.
+
+#### 2. Greeting Engine (`core/GreetingEngine/index.js`)
+Create the core processor. It will:
+- Parse `name` (default: "Guest"), `lang` (default: "en"), and `timezone` (default: local).
+- Determine time-of-day period (`morning` 5-11:59, `afternoon` 12-17:59, `evening` 18-21:59, `night` 22-4:59).
+- Load localization strings, format the template by replacing `{name}`, and return the object.
+- Record transactions to `greeting_history.jsonl`.
+- Provide stats functions.
+
+### Phase B: CLI Integration
+#### 1. CLI Commands (`bin/awk.js`)
+- Register the `greet` subcommand in the main switch-case.
+- Parse flags: `--name` / `-n`, `--lang` / `-l`, and `--timezone` / `-t` (or use system timezone).
+- Print the generated greeting and save to the history log.
+
+### Phase C: REST API Integration
+#### 1. API Route Handler (`symphony/app/api/greet/route.js`)
+- Define `GET` handler.
+- Extract `name`, `lang`, and `timezone` query parameters.
+- Call the Greeting Engine.
+- Return structured JSON response following spec.
 
 ---
 
-## Verification Plan
+## 3. Verification Plan
 
-### Automated Verification
-- Run `awkit status` to inspect mapping diffs.
-- Deploy to runtime using `awkit install`.
-- Verify CLI integration and syntax using `awkit doctor`.
+### Automated/Unit Tests
+- Verify engine resolves times and timezones correctly.
+- Verify fallback to `en` on unrecognized language inputs.
+- Verify JSON structure matches specifications.
 
 ### Manual Verification
-- Ask the user to verify the added skills locally or confirm availability in future workspace tasks.
+- Execute `node bin/awk.js greet --name="Alice" --lang="vi"`.
+- Execute `node bin/awk.js greet --name="Bob" --lang="ja"`.
+- Query Symphony REST API `/api/greet?name=Charlie&lang=en` locally.
+- Inspect the history log at the designated path.

package/docs/history/implementation_plan.v2.md

@@ -0,0 +1,87 @@
+# Implementation Plan - Codex Goal Mode Integration
+
+## Revision History
+| Version | Date | Description | Author |
+|---|---|---|---|
+| v1.0 | 2026-06-22 | Initial plan for Codex Goal Mode, skill, and workflow integration | Antigravity Orchestrator |
+
+---
+
+## Goal Description
+Implement a **Goal Mode** (including a new **Skill** and a **Workflow**) that utilizes the Codex goal-execution capabilities for centralized task orchestration. In this mode, Codex serves as the master coordinator (Goal Conductor), partitioning a high-level user goal into subtasks, tracking progress in Symphony, and delegating specific duties back to other specialized agents (Claude, Qwen, Gemini/AGY) or its own independent sub-agents (e.g., critic, coder, tester, ios-engineer) in a collaborative loop.
+
+---
+
+## User Review Required
+
+> [!IMPORTANT]
+> **Orchestration Loop Protocol:** Codex Goal Mode runs as a closed-loop execution system. Checkpoints are automatically bypassed when `goal_mode = true` (using best-effort AI verification) except for safety-critical, destructive, or security tasks.
+
+---
+
+## Open Questions
+- Do we want to support persistent background session resume for long-running goals (e.g., using `codex resume --last`)? *(Currently planned to support resume by storing execution states in `codex-reports/goals/`).*
+
+---
+
+## Proposed Changes
+
+### Core Orchestration Layer
+
+#### [NEW] [codex-goal.js](file:///Users/trungkientn/Dev/NodeJS/main-awf/scripts/codex-goal.js)
+Create a new script that coordinates the Goal loop:
+1. Initializes a goal workspace under `codex-reports/goals/<goal_id>/`.
+2. Sets `goal_mode = true` in the process context.
+3. Invokes Codex CLI to analyze the initial goal, parse it into subtasks, and map them to appropriate agents.
+4. Orchestrates task execution:
+   - For architecture & specs: Delegates to Claude via `scripts/claude-plan.js`.
+   - For coding/refactoring: Delegates to Qwen via `scripts/qwen-exec.js`.
+   - For general tasks/fallbacks: Delegates to AGY (Gemini).
+   - For reviews, tests, visual QA: Delegates to Codex sub-agents (`critic`, `tester`, `ios-visual-qa-strategist`).
+5. Tracks states, saves progress reports to `.md` files, and updates Symphony tickets.
+
+---
+
+### Workflows
+
+#### [NEW] [goal.md](file:///Users/trungkientn/Dev/NodeJS/main-awf/workflows/lifecycle/goal.md)
+Define the `/goal` workflow containing:
+- Pre-requisites checks for Codex CLI.
+- Workflow subcommands: `/goal "[objective]"`, `/goal:status`, `/goal:resume`, `/goal:pause`, `/goal:cancel`.
+- Detailed description of the autonomous goal execution loop.
+- Fallback policies and recovery steps.
+
+---
+
+### Skills
+
+#### [NEW] [SKILL.md](file:///Users/trungkientn/Dev/NodeJS/main-awf/skills/codex-goal/SKILL.md)
+Create a new skill for the Codex Goal Orchestrator defining:
+- Developer instructions for the master Goal Conductor role.
+- Task breakdown schemas and JSON mapping format.
+- Sub-agent specifications (definitions, system prompts, capabilities).
+- Call-back protocols for Claude, Qwen, and AGY.
+
+---
+
+### CLI & Code Integration
+
+#### [MODIFY] [awk.js](file:///Users/trungkientn/Dev/NodeJS/main-awf/bin/awk.js)
+1. Register `goal` in the CLI command list and register the command parser.
+2. Include the new `/goal` and `/goal-mode` commands in the help usage block.
+3. Add the `codex-goal` skill folder to the default runtime list, ensuring it gets synced during `awkit install`.
+
+#### [MODIFY] [codex-generators.js](file:///Users/trungkientn/Dev/NodeJS/main-awf/bin/codex-generators.js)
+Add `codex-goal` to `SPECIALIST_SKILLS` list so that a Codex-compatible `.toml` agent spec is automatically generated for it.
+
+---
+
+## Verification Plan
+
+### Automated Tests
+- Run `node bin/awk.js doctor` to check installation state.
+- Run `awkit status` to ensure all files are synchronized.
+
+### Manual Verification
+- Execute `node bin/awk.js goal "Build a simple greeting command line tool"` and verify that the orchestration loop initializes the plan, registers tasks, calls Qwen for implementation, and reviews using the critic sub-agent.
+- Verify status checks, pause, and resume capabilities.

package/docs/history/memoizedfibonacci_spec.v1.md

@@ -0,0 +1,127 @@
+# Technical Specification — MemoizedFibonacci
+
+## Revision History
+
+| Version | Date | Author | Description |
+| :--- | :--- | :--- | :--- |
+| 1.0 | 2026-06-22 | Antigravity Orchestrator | Initial technical design with Mermaid diagram, class architecture, and caching strategy. |
+
+---
+
+## 1. System Architecture
+
+The `MemoizedFibonacci` feature consists of three primary layers:
+1. **API & Interface Layer:** Exposes synchronous and asynchronous methods to users.
+2. **LRU Cache Layer:** Manages in-memory storage of computed sequences with automatic eviction based on Least Recently Used patterns.
+3. **Computation Engine:** Performs iterative sequence calculations to prevent call stack overflow, handles dynamic upgrading to `BigInt` for large numbers, and schedules asynchronous chunks for heavy inputs.
+
+---
+
+## 2. API Design & Core Interface
+
+```typescript
+interface FibonacciConfig {
+  maxCacheSize?: number;      // Maximum number of entries in the cache (default: 1000)
+  useBigInt?: boolean;        // Force BigInt computation even for small inputs (default: false)
+  asyncThreshold?: number;    // Input size to trigger asynchronous execution (default: 50000)
+}
+
+interface CacheStats {
+  hits: number;
+  misses: number;
+  size: number;
+  evictions: number;
+}
+
+class MemoizedFibonacci {
+  private cache: Map<number, number | bigint>;
+  private lruList: number[]; // Tracks usage order (least recently used at the front)
+  private config: Required<FibonacciConfig>;
+  private stats: CacheStats;
+
+  constructor(config?: FibonacciConfig);
+
+  /**
+   * Calculates Fibonacci of n. Automatically picks sync/async mode based on threshold.
+   */
+  public async calculate(n: number): Promise<number | bigint>;
+
+  /**
+   * Synchronously calculates Fibonacci of n.
+   * Throws warning/error if n is larger than asyncThreshold.
+   */
+  public calculateSync(n: number): number | bigint;
+
+  /**
+   * Retreives cache usage statistics.
+   */
+  public getStats(): CacheStats;
+
+  /**
+   * Clears all cache entries and metrics.
+   */
+  public clearCache(): void;
+
+  /**
+   * Private helper implementing iterative Fibonacci sequence.
+   */
+  private computeIterative(n: number, isBigInt: boolean): number | bigint;
+}
+```
+
+---
+
+## 3. Detailed Logic Flow (Mermaid Diagram)
+
+The following diagram illustrates the routing, validation, precision selection, and caching logic:
+
+```mermaid
+graph TD
+    A[Start: Calculate F(n)] --> B{Validate input n >= 0}
+    B -- No --> C[Throw Error: Invalid Input]
+    B -- Yes --> D{Check Cache for n}
+    D -- Hit (Yes) --> E[Update LRU Order]
+    E --> F[Return Cached Value]
+    D -- Miss (No) --> G{Check Precision Mode: n > 78 or useBigInt}
+    G -- Standard Number (n <= 78) --> H[Compute using standard arithmetic]
+    G -- BigInt (n > 78) --> I{Is n >= asyncThreshold?}
+    I -- No (Sync BigInt) --> J[Compute iteratively using BigInt]
+    I -- Yes (Async BigInt) --> K[Offload computation to worker thread / chunked loop]
+    K --> L[Iterate asynchronously without blocking event loop]
+    H --> M[Store Result in Cache]
+    J --> M
+    L --> M
+    M --> N{Cache Size > maxCacheSize?}
+    N -- Yes --> O[Evict Least Recently Used entry]
+    O --> P[Return Computed Result]
+    N -- No --> P
+```
+
+---
+
+## 4. Key Implementation Mechanics
+
+### 4.1 LRU Eviction Implementation
+To avoid linear scanning for evictions, the cache is backed by:
+- A `Map` mapping `n` to the value (either `Number` or `BigInt`).
+- A doubly-linked list or ordered array (`lruList`) tracking usage keys. On a cache hit, the key is moved to the end. On a cache insertion, if the map exceeds `maxCacheSize`, the key at the front of `lruList` is deleted from both the list and the map.
+
+### 4.2 Precision Safeguards
+- **Standard Float Limits:** Standard numbers in JavaScript lose precision above $F(78)$ ($F(78) = 8944394323791464$, whereas $F(79) = 14472334024559020$ which exceeds `Number.MAX_SAFE_INTEGER`).
+- **Automatic BigInt Upgrade:** If the class configuration is not explicitly set, inputs $n \ge 79$ automatically upgrade execution to `BigInt` mode.
+
+### 4.3 Async Slicing / Non-blocking Loop
+For large values of $n$ (e.g. $n \ge 500,000$), calculating Fibonacci in a single synchronous loop blocks the JS single-threaded event loop for several milliseconds. The `MemoizedFibonacci` class handles this via:
+- **Chunked execution:** Splitting the loop into chunks of 10,000 iterations and yielding back control using `setImmediate` or `setTimeout(..., 0)` to allow standard event-loop ticks to execute.
+- Alternatively, utilizing **Worker Threads** via `node:worker_threads` for CPU offloading in Node.js environments.
+
+---
+
+## 5. Error Handling & Edge Cases
+
+| Condition | System Response |
+| :--- | :--- |
+| Negative Input ($n < 0$) | Throws `RangeError: Input must be a non-negative integer.` |
+| Floating point Input (e.g., $n = 3.5$) | Automatically truncated using `Math.floor(n)` with a console warning, or throws a `TypeError`. |
+| Out of Memory Risk ($n > 1,000,000$) | Rejects promise with a warning about resource exhaustion unless a `force` flag is set. |
+| Cache Collision (Standard vs BigInt) | Values in cache are stored with consistent type based on configuration to avoid mixed-type arithmetic downstream. |

package/docs/specs/greetingapp_spec.md

@@ -0,0 +1,97 @@
+# Technical Specification - GreetingApp
+
+## Revision History
+| Version | Date | Description | Author |
+|---|---|---|---|
+| v1.0 | 2026-06-22 | Technical specification for GreetingApp | Antigravity Orchestrator |
+
+---
+
+## 1. System Architecture
+The GreetingApp consists of three major components:
+1. **Greeting Engine (Core):** Performs validation, detects time-of-day categories, maps to localization files, and builds the string.
+2. **Storage Layer:** A lightweight JSON/SQLite file logger to record history.
+3. **Interfaces:**
+   - CLI Controller: Handles flags and standard output formatting.
+   - REST Controller: Express.js routes and JSON responses.
+
+## 2. Detailed Component Specs
+
+### 2.1 Greeting Engine (`core/GreetingEngine`)
+- **Input:**
+  - `name`: string (optional, default: "Guest")
+  - `lang`: string (optional, default: "en")
+  - `timezone`: string (optional, default: system timezone)
+- **Time Periods:**
+  - `Morning`: 05:00 - 11:59
+  - `Afternoon`: 12:00 - 17:59
+  - `Evening`: 18:00 - 21:59
+  - `Night`: 22:00 - 04:59
+- **Localization Files (`locales/*.json`):**
+  - Example `en.json`:
+    ```json
+    {
+      "morning": "Good morning, {name}!",
+      "afternoon": "Good afternoon, {name}!",
+      "evening": "Good evening, {name}!",
+      "night": "Good night, {name}!"
+    }
+    ```
+
+### 2.2 Storage Schema
+A SQLite or JSON lines file containing:
+- `id`: UUID / Auto-increment integer
+- `name`: String
+- `language`: String
+- `timestamp`: ISO-8601 string
+- `greeting_message`: String
+
+## 3. Interface Design
+
+### 3.1 CLI Interface
+`awkit greet [options]`
+- `--name, -n`: Name of the user to greet.
+- `--lang, -l`: Language code (en, vi, ja).
+- `--help, -h`: Show usage description.
+
+### 3.2 REST API Specification
+`GET /api/greet`
+- **Query Parameters:**
+  - `name` (string)
+  - `lang` (string)
+- **Response (200 OK):**
+  - Content-Type: `application/json`
+  - Body:
+    ```json
+    {
+      "status": "success",
+      "data": {
+        "message": "Good morning, Alice!",
+        "name": "Alice",
+        "lang": "en",
+        "timestamp": "2026-06-22T05:35:15Z"
+      }
+    }
+    ```
+
+## 4. Error Handling
+- **Invalid Language:** Fallback to `en` and log warning.
+- **Invalid Input characters:** Sanitize inputs to prevent command line injection or XSS (on API side).
+
+## 5. Flow Diagram
+```mermaid
+graph TD
+    A[Start Request] --> B{Validate Inputs}
+    B -- Invalid --> C[Use Defaults: Guest/en]
+    B -- Valid --> D[Resolve User Local Time]
+    C --> D
+    D --> E{Determine Time of Day}
+    E -->|05:00-11:59| F[Morning Template]
+    E -->|12:00-17:59| G[Afternoon Template]
+    E -->|18:00-21:59| H[Evening Template]
+    E -->|22:00-04:59| I[Night Template]
+    F & G & H & I --> J[Replace {name} in Template]
+    J --> K[Log Transaction to History DB]
+    K --> L[Format Output CLI/REST]
+    L --> M[End Request]
+```