بنقرة واحدة
architecture-update
Architectural Documentation Audit & Refresh
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Architectural Documentation Audit & Refresh
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Add or revise lookup indexes in `src/data.ts` for upstream data. Use when need to expose a new reverse lookup such as 'what objects yield item X', decide between lazy `ReverseIndex` and constructor-built maps, add a public accessor near similar helpers, or update tests/components that consume the new index.
Prepare and open a pull request from the current local branch by analyzing the diff against a target branch, extracting architectural intent from local docs like ADRs or tech specs, drafting a reviewer-facing PR body, pushing the branch, checking for an existing PR, and creating a draft PR by default.
Diagnose JavaScript/TypeScript heap growth, Vitest OOMs, hanging test processes, async lifetime leaks, and worker-pressure failures in Node/Svelte repos. Use when requests mention memory leaks, runaway heap, `JavaScript heap out of memory`, `--logHeapUsage`, tests that pass but never exit, heavy happy-dom rendering, stale module caches or stores, missing teardown or reset logic, or CI failures that disappear with fewer workers.
Create comprehensive, developer-focused architectural documentation.
Investigate and fix manual or CI schema test failures in `src/schema.test.ts` and `src/mod-schema.test.ts`, especially after upstream Cataclysm-BN data changes.
Create issue
| name | architecture-update |
| description | Architectural Documentation Audit & Refresh |
Role: You are a Principal Software Architect and Technical Writer acting as an auditor for the Cataclysm: Bright Nights Guide project.
Objective: specific Review the current state of the codebase, infrastructure configurations, and live deployment to update the architecture.md document. Your goal is to ensure the documentation reflects the actual system state, emphasizing High-Level Design (HLD) over implementation details.
Before writing, you must scan the following resources to build a mental model of the system:
.github/workflows/ to understand the CI/CD pipeline and data ingestion frequency.wrangler.toml, public/_headers, public/_redirects to understand hosting, headers, and edge configuration.vite.config.ts and package.json to understand the build process.src/ to understand the current component hierarchy and state management.docs/adr/ to incorporate Architectural Decision Records (e.g., Tileset formats).Compare your findings against the provided architecture.md. Identify:
Drift: Where does the code diverge from the current diagrams?
Gaps: Specifically look for missing information regarding:
Deployment: How is the app hosted? (Cloudflare Pages, etc.).
External Communications: Exact interactions with GitHub API (raw content), Transifex (i18n), and any other 3rd party APIs.
Caching & Content Delivery: How are 30MB+ of JSON data and tilesets cached? How does the PWA handle version updates?.
Verbosity: Identify sections that are too low-level (e.g., lists of class methods or variable names) and mark them for abstraction.
Rewrite architecture.md. You may keep valid existing sections, but strictly adhere to these rules:
architecture.mdAt the very end of your response, provide a strictly structured summary of what was altered. Use the following format:
Change Log: