|
8 | 8 |
|
9 | 9 | --- |
10 | 10 |
|
| 11 | + |
11 | 12 | ## 2. INPUT PROCESSING & COGNITION |
12 | 13 | * **SPEECH-TO-TEXT INTERPRETATION PROTOCOL:** |
13 | 14 | * **Context:** User inputs may contain phonetic errors (homophones, typos). |
|
21 | 22 |
|
22 | 23 | --- |
23 | 24 |
|
| 25 | + |
24 | 26 | ## 3. CONTEXT-AWARE APEX TECH STACKS (LATE 2025 STANDARDS) |
25 | | -**Directives:** Detect the project type and apply the corresponding **Apex Toolchain**. This repository, `DevCore-Software-Design-Principles-Handbook`, is a documentation and knowledge-base project. |
| 27 | +**Directives:** Detect the project type and apply the corresponding **Apex Toolchain**. This repository, `DevCore-Software-Design-Principles-Handbook`, is a documentation and knowledge-sharing project. |
26 | 28 |
|
27 | | -* **PRIMARY SCENARIO: DOCUMENTATION / KNOWLEDGE BASE / HANDBOOK** |
28 | | - * **Stack:** This project is primarily static content with potential for Markdown rendering and search functionality. We will leverage standard documentation tools. |
29 | | - * **Static Site Generator (Optional but Recommended for Professional Presentation):** Consider **Astro** for its performance and flexibility in rendering Markdown with potential for modern JavaScript integration. Alternatively, a robust Markdown renderer within a simple tooling setup. |
30 | | - * **Content Format:** **Markdown** (CommonMark/GFM) is the primary format. Structure is paramount. |
31 | | - * **Versioning:** Git for source control. Tags for releases. |
32 | | - * **Architecture:** A clear, hierarchical structure. Content is King. The architecture supports discoverability and maintainability of knowledge. |
33 | | - * **Verification:** Automated checks for broken links, proper Markdown syntax, and consistent formatting. |
| 29 | +* **PRIMARY SCENARIO: DOCUMENTATION / KNOWLEDGE BASE (Markdown)** |
| 30 | + * **Stack:** This project is primarily a **Markdown-based knowledge repository**. Core tooling includes **MkDocs** for static site generation, **Material for MkDocs** theme for a professional presentation, and ** tumbuhan-lint/markdownlint** for consistent Markdown formatting. |
| 31 | + * **Architecture:** Utilizes a **Hierarchical / Topical structure** for organizing knowledge, ensuring logical flow and easy navigation. Adheres to principles of clear, concise documentation suitable for a handbook. |
| 32 | + * **Verification:** Content integrity is maintained through **manual review** and automated checks for broken links and consistent formatting. |
34 | 33 |
|
35 | | -* **SECONDARY SCENARIO A: WEB / APP / EXTENSION (TypeScript) - *Not directly applicable, but principles for maintainable codebases apply.*** |
| 34 | +* **SECONDARY SCENARIO A: WEB / APP / EXTENSION (TypeScript) - *Not applicable for this project's primary function.*** |
36 | 35 | * **Stack:** TypeScript 6.x (Strict), Vite 7 (Rolldown), Tauri v2.x (Native), WXT (Extensions). |
37 | 36 | * **State:** Signals (Standardized). |
38 | | - |
39 | | -* **TERTIARY SCENARIO B: SYSTEMS / PERFORMANCE (Rust/Go) - *Not applicable.*** |
40 | | - * **Stack:** Rust (Cargo) or Go (Modules). |
41 | | - * **Lint:** Clippy / GolangCI-Lint. |
42 | | - * **Architecture:** Hexagonal Architecture (Ports & Adapters). |
43 | | - |
44 | | -* **QUATERNARY SCENARIO C: DATA / AI / SCRIPTS (Python) - *Not applicable.*** |
45 | | - * **Stack:** uv (Manager), Ruff (Linter), Pytest (Test). |
46 | | - * **Architecture:** Modular Monolith or Microservices. |
47 | | - |
48 | | ---- |
49 | | - |
50 | | -## 4. OPERATIONAL DIRECTIVES (APEX PROTOCOL ALPHA) |
51 | | -* **CODE QUALITY & CONSISTENCY:** |
52 | | - * **LINTING & FORMATTING:** Enforce rigorous linting and formatting standards. For documentation projects, this translates to Markdown linters (e.g., `markdownlint`) and style consistency. ALL content MUST pass these checks. |
53 | | - * **TESTING:** Automated checks for documentation integrity. This includes: |
54 | | - * **Link Checkers:** Verify all internal and external hyperlinks are valid. |
55 | | - * **Markdown Syntax Validation:** Ensure correct Markdown structure. |
56 | | - * **Spell Check:** Integrated spell-checking mechanisms. |
57 | | - * **PRINCIPLES:** Adherence to **SOLID, DRY, KISS, YAGNI** applies to the *structure* and *management* of the documentation, not just code. |
58 | | - |
59 | | -* **SECURITY & COMPLIANCE (The "Standard 11" & Beyond):** |
60 | | - * **LICENSE:** All code and documentation MUST be under **CC BY-NC 4.0**. |
61 | | - * **CONTRIBUTING:** Clearly defined contribution guidelines (`CONTRIBUTING.md`). |
62 | | - * **ISSUE TEMPLATES:** Standardized templates for bug reports and feature requests (`.github/ISSUE_TEMPLATE/`). |
63 | | - * **PULL REQUEST TEMPLATES:** Standardized templates for PRs (`.github/PULL_REQUEST_TEMPLATE.md`). |
64 | | - * **SECURITY POLICY:** A dedicated security policy file (`.github/SECURITY.md`). |
65 | | - * **CI/CD:** Robust CI pipeline (`.github/workflows/ci.yml`) to automate checks and builds. |
66 | | - * **BADGES:** Comprehensive badge implementation (`badges.yml`) for visibility. |
67 | | - * **GITIGNORE:** Maintain a clean `.gitignore` file. |
68 | | - |
69 | | -* **DOCUMENTATION AS AN ARTIFACT:** |
70 | | - * **ARCHIVAL:** Even archived projects must be meticulously documented and professionally presented. |
71 | | - * **PROFESSIONAL PRESENTATION:** ALL repositories will have a **Hero-Tier README.md**, a `PROPOSED_README.md` outlining agent directives, and a comprehensive `AGENTS.md` detailing operational protocols. |
72 | | - * **AGENT INTERACTION:** The `AGENTS.md` file serves as the **direct instruction set** for AI agents interacting with this repository. Ensure it is specific, actionable, and aligned with the project's nature. |
73 | | - |
74 | | ---- |
75 | | - |
76 | | -## 5. AGENT DIRECTIVES FOR THIS REPOSITORY (`DevCore-Software-Design-Principles-Handbook`) |
77 | | - |
78 | | -**Repository URL:** `https://github.com/chirag127/DevCore-Software-Design-Principles-Handbook` |
79 | | - |
80 | | -* **PRIMARY FUNCTION:** To serve as a definitive, high-authority handbook on software engineering principles and design patterns. |
81 | | - |
82 | | -* **CONTENT FOCUS:** |
83 | | - * Deep dives into SOLID principles. |
84 | | - * Comprehensive catalog of design patterns (Gang of Four, architectural patterns, etc.). |
85 | | - * Best practices for clean code, maintainability, scalability, and testability. |
86 | | - * Explanations of architectural concepts. |
87 | | - * Comparative analysis of different approaches. |
88 | | - |
89 | | -* **TECHNOLOGY STACK CONSIDERATIONS FOR AGENTS:** |
90 | | - * **Content Management:** Agents must interact with Markdown files (`.md`). Primary tools for content generation or editing should be Markdown-aware. |
91 | | - * **Validation Tools:** Agents must be capable of utilizing Markdown linters (e.g., `markdownlint` via `npm install -g markdownlint-cli` or similar equivalent for Python if integrated) and link checkers (e.g., `markdown-link-check` via `npm` or Python equivalents). Spell-checking tools should also be integrated. |
92 | | - * **CI/CD Integration:** Agents must understand that their outputs will be subject to CI/CD pipelines defined in `.github/workflows/ci.yml`. Ensure generated or modified content is compliant. |
93 | | - |
94 | | -* **OPERATIONAL AGENT TASKS:** |
95 | | - 1. **Content Enhancement:** Identify areas for deeper explanation, additional examples, or improved clarity. Suggest and implement (if authorized) these improvements in Markdown. |
96 | | - 2. **Pattern & Principle Identification:** Proactively identify instances where specific principles or patterns are discussed or could be applied within the handbook's content. |
97 | | - 3. **Consistency Checks:** Ensure terminology, formatting, and structural consistency across the entire handbook. |
98 | | - 4. **Broken Link Detection & Correction:** Regularly scan for and fix broken hyperlinks. |
99 | | - 5. **Feature Requests:** Log potential new sections or topics for future expansion. |
100 | | - 6. **Cross-referencing:** Establish and maintain links between related concepts and patterns. |
101 | | - |
102 | | -* **DO NOT:** Do not attempt to compile code, run complex algorithms, or interact with APIs unrelated to documentation management or knowledge synthesis for this handbook. |
103 | | - |
104 | | -* **DO:** Focus on the quality, accuracy, and accessibility of the knowledge presented. |
105 | | - |
106 | | ---- |
107 | | - |
108 | | -## 6. COMMUNICATION PROTOCOL |
109 | | -* **DIRECTIVES:** All commands and interactions with agents must be explicit and referential. Use the structure defined in this document. |
110 | | -* **FEEDBACK:** Agents should report adherence to directives and any encountered obstacles. |
111 | | - |
112 | | ---- |
113 | | - |
114 | | -**END OF AGENTS.MD** |
| 37 | +... |
0 commit comments