xmatsuda2053/toybox

1. This repository is a small suite of standalone, browser-based applications built from one shared codebase. The top-level HTML entry points are separate artifacts for each app: hubaddress.html, stepnote.html, and toybox.html, with built outputs in dist/ and source-compatible copies in root/.

2. The technical stack is TypeScript with Lit-style component architecture and colocated SCSS styling. Most UI elements are split into small custom components, with matching .lit.scss files for scoped presentation. A Vite-based build pipeline is implied by vite.config.ts, with build.js likely orchestrating packaging.

3. The shared foundation lives under src/common and src/utils. common contains reusable UI primitives such as file upload, search input, copy button, date picker, markdown editor, help viewer, and data exporter. utils contains cross-cutting logic for dates, config, scheduling, events, and general helpers.

4. src/assets is the shared asset layer. It centralizes icons and related asset generation, so app features can reference a common visual vocabulary rather than duplicating image/icon handling.

5. The StepNote app is the largest subsystem. Its root bootstrap is src/apps/stepnote/step-note-app.ts, and it is organized around task tracking, journaling, configuration, navigation, and dashboard views. The feature set is split into components/{config,dashboard,journal,list,menu,nav,tab,task}.

6. StepNote has a clear data layer boundary under src/apps/stepnote/database. The repositories folder maps to persisted domain entities such as tasks, labels, notes, logs, quick access items, dashboards, and config. services and calculators add derived queries and metrics, especially for dashboard data and task statistics.

7. StepNote’s main data flow is: user actions in Lit components update repositories, repositories read/write the local app database, and query services derive aggregate views for dashboards and summaries. The models in src/apps/stepnote/models define the domain objects that move across this boundary, including tasks, labels, notes, logs, contacts, configs, and KPI values.

8. The StepNote UI is organized as a shell with navigation/menu on one side and task/journal/dashboard content in the main area. The menu subsystem includes embedded help pages in Markdown, which are rendered through shared help/markdown tooling. This app is designed around dense in-app workflows rather than broad page navigation.

9. The HubAddress app is a separate bounded subsystem with its own bootstrap in src/apps/hub-address.ts and implementation root in src/apps/hubaddress/hub-address-app.ts. Its main features are a menu, uploader, and viewer, indicating a workflow centered on ingesting address data and browsing it by division or staff.

10. HubAddress also uses a local database abstraction, src/apps/hubaddress/database/HaDB.ts, and domain models for Division, Staff, FileData, and SearchKeyword. The architecture suggests a pipeline of uploaded file data being parsed/stored locally, then searched and rendered in the viewer components.

11. The HubAddress viewer is split by entity type: one component for divisions and one for staff. That separation is important for the diagram because it means the presentation layer is not generic; it reflects the underlying domain model and likely switches views based on search or selection context.

12. The AppContainer/toybox area under src/apps/appcontainer appears to be a launcher or catalog app for tools, files, and storage-related entries. Its component grouping (app, file, storage, tool) and AppItem model indicate an index/navigation role rather than a single business workflow.

13. The repo’s architecture is therefore “multi-app, shared component library, local data-first.” There is no visible server-side application layer in this tree; the major boundary is between UI/component logic and browser-side persistence/query layers.

14. For an architecture diagram, the cleanest top-level boxes are: shared UI/utilities, StepNote, HubAddress, and AppContainer/Toybox, with each app pointing to its own database/models and also consuming shared widgets from src/common. The build output layer (dist/) sits below all of them as the packaged static delivery artifact.