@codepassion/skills 1.0.0

package/README.md

@@ -0,0 +1,918 @@
+# CodePassion (C9N)
+
+## Table of Contents
+1. [Development Workflow](#1-development-workflow)
+2. [Git Branching Strategy](#2-git-branching-strategy)
+3. [Commit Message Convention](#3-commit-message-convention)
+4. [Pull Request (PR) Guidelines](#4-pull-request-pr-guidelines)
+5. [Code Review (Conventional Comments)](#5-code-review-conventional-comments)
+6. [Clean Code (TypeScript)](#6-clean-code-typescript)
+7. [TypeScript Rules (ESLint)](#7-typescript-rules-eslint)
+8. [Code Formatting](#8-code-formatting)
+9. [JSON:API Overview](#9-jsonapi-overview)
+10. [Go/No Go Release Step](#10-gono-go-release-step)
+11. [Deployment Guide (Semantic Versioning 2.0.0)](#11-deployment-guide-semantic-versioning-200)
+
+---
+
+## 1. Development Workflow
+A step-by-step guide for working on tickets from assignment to completion.
+
+### Workflow Diagram
+
+```mermaid
+sequenceDiagram
+    participant Dev as Developer
+    participant Jira as Jira Board
+    participant Repo as Repository
+    participant CI as CI/CD Pipeline
+    participant Env as Alpha Environment
+    participant QA as QA Team
+
+    Dev->>Jira: Pick ticket from Active Sprint
+    Dev->>Jira: Clarify requirements & acceptance criteria
+    Dev->>Jira: Move to "To Analyze"
+    Dev->>Dev: Analyze solution (diagrams, POCs, dependencies)
+    Dev->>Jira: Add size, start/end date & duration estimates
+    Dev->>Jira: Move to "Ready for Dev"
+    Dev->>Jira: Move to "Dev in Progress"
+    Dev->>Repo: Push working branch & create draft PR
+    Dev->>Jira: Update working status
+    Dev->>Repo: Write & run tests (unit, e2e, automation)
+    Dev->>Jira: Move to "Ready for Code Review"
+    Dev->>Repo: Update PR & request review
+
+    alt PR Approved
+        Dev->>Repo: Merge PR
+    else Changes Requested
+        Dev->>Repo: Resolve comments & update PR
+        Dev->>Repo: Request re-review
+        Dev->>Repo: Merge PR after approval
+    end
+
+    Dev->>Jira: Move to "Ready to Deploy"
+    Dev->>Repo: Pull latest develop & tag (vX.Y.Z-alpha)
+    Dev->>CI: Push tag to trigger deployment
+    CI->>Env: Deploy to Alpha
+    Dev->>Env: Validate changes in Alpha
+    Dev->>Jira: Move to "Ready for QA" & assign to QA
+
+    alt QA Passed
+        QA->>Jira: Close ticket as "Done"
+    else Issues Found
+        QA->>Jira: Move to "Reopened" & assign back to Dev
+        Dev->>Jira: Pick up ticket & repeat from clarification
+    end
+```
+
+### Steps of Work
+
+1. **Pick up your ticket** — Review your assigned tickets in Jira (For You page or Active Sprint).
+2. **Clarify requirements** — Before starting, confirm the requirements, acceptance criteria, steps to reproduce (for bugs), test cases, and definition of done with the reporter or your manager.
+3. **Analyze the ticket** — Move the ticket to **"To Analyze"**. Evaluate solutions, draw diagrams, identify dependencies, and complete any necessary POCs.
+4. **Provide estimates** — Add ticket size, start date, end date, and duration estimates (days/hours).
+5. **Mark ready for development** — Move the ticket to **"Ready for Dev"** once analysis is complete.
+6. **Start development** — Move the ticket to **"Dev in Progress"**. Push your working branch and create a draft pull request.
+7. **Keep status updated** — Regularly update your working status in the Jira ticket.
+8. **Write tests** — Add unit tests, e2e tests, and automation tests to cover all changes. Ensure no existing tests are broken.
+9. **Request code review** — Move the ticket to **"Ready for Code Review"**. Update your PR and assign another developer to review.
+10. **Address review feedback** — If changes are requested, resolve or fix all comments. Once approved, merge the PR.
+11. **Prepare for deployment** — Move the ticket to **"Ready to Deploy"**. Pull the latest changes from the develop branch, create a new tag (`vX.Y.Z`), and push it.
+12. **Validate in Alpha** — After the CI/CD pipeline completes, verify your changes in the Alpha environment.
+13. **Hand off to QA** — Move the ticket to **"Ready for QA"** and assign it to a QA team member.
+14. **QA verification** — If QA tests pass, the ticket is closed as **"Done"**. If issues are found, the ticket is moved to **"Reopened"** and assigned back to you with test results. Repeat from step 2.
+
+[⬆ Back to Top](#codepassion-c9n)
+
+## 2. Git Branching Strategy
+We follow the **Conventional Branch** specification to ensure branch names are human and machine-readable.
+
+### Format
+```
+<type>/<description>
+```
+
+### Branch Types
+
+| Type | Purpose | Example |
+|------|---------|---------|
+| `main` | Main development branch | `main`, `master`, `develop` |
+| `feature/` or `feat/` | New features | `feature/add-login-page` |
+| `bugfix/` or `fix/` | Bug fixes | `bugfix/fix-header-bug` |
+| `hotfix/` | Urgent fixes | `hotfix/security-patch` |
+| `release/` | Release preparation | `release/v1.2.0` |
+| `chore/` | Non-code tasks (dependencies, docs) | `chore/update-readme` |
+
+### Naming Rules
+
+| ✅ Do | ❌ Don't |
+|------|---------|
+| `feature/user-profile` | `Feature/User-Profile` (use lowercase) |
+| `feature/user-login-page` | `feature/user_login_page` (use hyphens) |
+| `feature/add-payment` | `feature/add-payment!` (avoid special chars) |
+| `feature/new-feature` | `feature/new--feature` (no consecutive separators) |
+| `feature/login-page` | `feature/-login-page` (no leading/trailing separators) |
+| `release/v1.2.0` | `feature/v1.2.0` (dots only in release branches) |
+| `feature/issue-123-add-login` | `feature/add-login` (include ticket number if exists) |
+| `feature/add-user-authentication` | `feature/updates` (be specific, not vague) |
+| `fix/resolve-memory-leak` | `fix/john-fixes` (no personal names) |
+| `hotfix/security-vulnerability-patch` | `feature/this-is-a-very-long-branch-name-that-exceeds-fifty-characters` (keep under 50 chars) |
+
+Reference: [Conventional Branch](https://conventional-branch.github.io)
+
+[⬆ Back to Top](#codepassion-c9n)
+
+## 3. Commit Message Convention
+We adhere to **Conventional Commits** to create an explicit commit history that supports automated Semantic Versioning.
+
+### Format
+```
+<type>[optional scope]: <description>
+
+[optional body]
+
+[optional footer(s)]
+```
+
+### Commit Types
+
+| Type | Purpose | SemVer Impact | Example |
+|------|---------|---------------|---------|
+| `feat:` | New feature | MINOR | `feat: add user authentication` |
+| `fix:` | Bug fix | PATCH | `fix: resolve login error` |
+| `docs:` | Documentation changes | - | `docs: update API documentation` |
+| `style:` | Code style changes (formatting) | - | `style: fix indentation` |
+| `refactor:` | Code refactoring | - | `refactor: simplify validation logic` |
+| `test:` | Add or update tests | - | `test: add unit tests for parser` |
+| `chore:` | Maintenance tasks | - | `chore: update dependencies` |
+| `ci:` | CI/CD changes | - | `ci: update build pipeline` |
+| `perf:` | Performance improvements | PATCH | `perf: optimize database queries` |
+
+### Breaking Changes
+A commit introducing a **breaking API change** (correlates with MAJOR version) must be indicated by:
+- Appending a `!` after the type/scope: `feat!: ...` or `fix(api)!: ...`
+- Or including a footer: `BREAKING CHANGE: <description>`
+
+### Writing Good Commit Messages
+
+| ✅ Do | ❌ Don't |
+|------|---------|
+| `feat: add user authentication` | `feat: added stuff` (be specific) |
+| `feat: add new feature` | `feat: Add new feature` (lowercase after colon) |
+| `docs: update README` | `docs: update README.` (no ending punctuation) |
+| `refactor: simplify logic` | `refactor: simplified logic` (use imperative mood) |
+| `feat: add password reset` | `feat: add a complete password reset functionality with email verification` (keep under 50 chars) |
+| `fix(api): handle null response` | `fix(api, auth, db): multiple fixes` (one scope only) |
+| ```feat: add password reset functionality<br><br>Allow users to reset their password via email.<br><br>Closes #123``` | ```feat: stuff<br><br>Updated some files.``` (provide clear description) |
+
+Reference: [Conventional Commits](https://www.conventionalcommits.org)
+
+[⬆ Back to Top](#codepassion-c9n)
+
+## 4. Pull Request (PR) Guidelines
+A consistent naming convention for PRs helps reviewers identify the context immediately.
+
+### Subject Format
+```
+#[Ticket_ID] PR description
+```
+
+### Pull Request Guidelines
+
+| ✅ Do | ❌ Don't |
+|------|---------|
+| `#CLS-23 Add user dashboard` | `Add user dashboard` (include ticket ID) |
+| `#CLS-23 Add feature` | `#CLS-23 Added feature` (use imperative mood) |
+| `#CLS-23 Add login page` | `#CLS-23 add login page` (capitalize first word) |
+| `#CLS-23 Add search feature` | `#CLS-23 Add search feature.` (no ending punctuation) |
+| `#CLS-23 Add OAuth authentication` | `#CLS-23 Add stuff` (be specific) |
+| ```#CLS-23 Add Edit on Github button to all pages<br><br>This change adds an "Edit on Github" button to improve<br>contributor experience. The button appears on every<br>documentation page and links to the source file.<br><br>- Added button component<br>- Integrated with page layout<br>- Tested on mobile and desktop<br><br>Closes #CLS-23``` | ```#cls-23 added edit button.``` (follow all conventions) |
+
+Reference: [Naming Convention (Pull Request)](https://namingconvention.org/git/pull-request-naming.html)
+
+[⬆ Back to Top](#codepassion-c9n)
+
+## 5. Code Review (Conventional Comments)
+To prevent misunderstandings and make feedback actionable, use **labels** to prefix comments.
+
+### Format
+```
+<label> [decorations]: <subject>
+```
+
+### Labels
+
+| Label | Purpose | When to Use | Example |
+|-------|---------|-------------|---------|
+| `praise:` | Highlight positive aspects | Something is well done | `praise: Great error handling here!` |
+| `nitpick:` | Trivial preferences | Minor style/formatting | `nitpick: Consider using single quotes` |
+| `suggestion:` | Propose improvements | Better approach exists | `suggestion: Use map() instead of forEach()` |
+| `issue:` | Highlight problems | Bug or technical issue | `issue: This will cause a memory leak` |
+| `question:` | Ask for clarification | Need more information | `question: Why is this timeout set to 5000ms?` |
+| `todo:` | Small necessary changes | Must be addressed | `todo: Add error handling for null case` |
+| `chore:` | Process/documentation tasks | Non-code updates needed | `chore: Update API docs before merging` |
+
+### Decorations
+
+Use decorations in parentheses to provide additional context:
+
+| Decoration | Meaning | Impact |
+|------------|---------|--------|
+| `(non-blocking)` | Optional feedback | Does not prevent approval |
+| `(blocking)` | Required change | Must be resolved before merge |
+| `(if-minor)` | Conditional | Resolve only if changes are small |
+
+### Review Comment Guidelines
+
+| Scenario | ✅ Do | ❌ Don't |
+|----------|------|---------|
+| **Suggesting improvements** | `suggestion: Extract this logic into a separate function for better readability` | `This code is bad` |
+| **Asking questions** | `question (non-blocking): Why did we choose setTimeout instead of setInterval here?` | `Why setTimeout??` |
+| **Reporting issues** | `issue (blocking): This will cause a null pointer exception when user is undefined` | `This will crash` |
+| **Style preferences** | `nitpick (non-blocking): Consider using single quotes for consistency with the rest of the codebase` | `Use single quotes` |
+| **Praising code** | `praise: Excellent test coverage and edge case handling!` | `Good job` |
+| **Requesting changes** | `todo: Add JSDoc comment for this public API method` | `Add comment` |
+
+Reference: [Conventional Comments](https://conventionalcomments.org)
+
+[⬆ Back to Top](#codepassion-c9n)
+
+## 6. Clean Code (TypeScript)
+We follow **Clean Code** principles adapted for TypeScript to produce readable, reusable, and refactorable software.
+
+### Variables
+
+| ✅ Do | ❌ Don't |
+|------|---------|
+| Use meaningful and pronounceable names | Use cryptic abbreviations |
+| Use searchable named constants | Use magic numbers or strings |
+| Use explanatory variables | Use mental mapping |
+| Use default arguments | Use short circuiting for defaults |
+| Use the same vocabulary for the same type | Use different names for the same concept |
+
+```typescript
+// ❌ Bad
+const d = 86400000;
+function between<T>(a1: T, a2: T, a3: T): boolean {
+  return a2 <= a1 && a1 <= a3;
+}
+
+// ✅ Good
+const MILLISECONDS_PER_DAY = 24 * 60 * 60 * 1000;
+function between<T>(value: T, left: T, right: T): boolean {
+  return left <= value && value <= right;
+}
+```
+
+### Functions
+
+| ✅ Do | ❌ Don't |
+|------|---------|
+| Keep arguments to 2 or fewer (use objects for more) | Pass many individual arguments |
+| Make functions do one thing | Make functions handle multiple responsibilities |
+| Use descriptive names that say what they do | Use vague or misleading names |
+| Keep one level of abstraction per function | Mix levels of abstraction |
+| Remove duplicate code | Copy-paste similar logic |
+
+```typescript
+// ❌ Bad
+function createMenu(title: string, body: string, buttonText: string, cancellable: boolean) {
+  // ...
+}
+createMenu('Foo', 'Bar', 'Baz', true);
+
+// ✅ Good
+type MenuOptions = {
+  title: string;
+  body: string;
+  buttonText: string;
+  cancellable: boolean;
+};
+
+function createMenu(options: MenuOptions) {
+  // ...
+}
+createMenu({ title: 'Foo', body: 'Bar', buttonText: 'Baz', cancellable: true });
+```
+
+### Objects and Data Structures
+
+| ✅ Do | ❌ Don't |
+|------|---------|
+| Use getters and setters with encapsulation | Access properties directly without control |
+| Use `readonly` for properties that should not change | Leave immutable properties mutable |
+| Use type aliases and interfaces for clarity | Use inline complex types repeatedly |
+
+```typescript
+// ❌ Bad
+type Car = {
+  carMake: string;
+  carModel: string;
+  carColor: string;
+};
+
+// ✅ Good
+type Car = {
+  make: string;
+  model: string;
+  color: string;
+};
+```
+
+### Classes
+
+| ✅ Do | ❌ Don't |
+|------|---------|
+| Prefer composition over inheritance | Overuse inheritance hierarchies |
+| Use method chaining when appropriate | Ignore fluent interfaces for builder-like classes |
+| Use `readonly` and access modifiers (`private`, `protected`) | Leave all class members public by default |
+
+```typescript
+// ❌ Bad
+class Dashboard {
+  getData() { /* ... */ }
+  renderChart() { /* ... */ }
+  handleClick() { /* ... */ }
+}
+
+// ✅ Good (Single Responsibility)
+class DashboardData {
+  getData() { /* ... */ }
+}
+
+class DashboardRenderer {
+  renderChart(data: DashboardData) { /* ... */ }
+}
+```
+
+### SOLID
+
+| Principle | Description |
+|-----------|-------------|
+| **S**ingle Responsibility | A class should have only one reason to change |
+| **O**pen/Closed | Open for extension, closed for modification |
+| **L**iskov Substitution | Subtypes must be substitutable for their base types |
+| **I**nterface Segregation | No client should depend on methods it does not use |
+| **D**ependency Inversion | Depend on abstractions, not concretions |
+
+```typescript
+// ❌ Bad (violates Interface Segregation)
+interface Worker {
+  work(): void;
+  eat(): void;
+}
+
+// ✅ Good
+interface Workable {
+  work(): void;
+}
+
+interface Feedable {
+  eat(): void;
+}
+
+class HumanWorker implements Workable, Feedable {
+  work() { /* ... */ }
+  eat() { /* ... */ }
+}
+
+class RobotWorker implements Workable {
+  work() { /* ... */ }
+}
+```
+
+### Error Handling
+
+| ✅ Do | ❌ Don't |
+|------|---------|
+| Use typed exceptions or error classes | Throw plain strings |
+| Always handle caught errors | Leave empty catch blocks |
+| Use `Error` types for thrown values | Throw non-Error values |
+
+```typescript
+// ❌ Bad
+throw 'Something went wrong';
+
+// ✅ Good
+class HttpError extends Error {
+  constructor(public statusCode: number, message: string) {
+    super(message);
+    this.name = 'HttpError';
+  }
+}
+
+throw new HttpError(404, 'User not found');
+```
+
+### Testing
+
+| ✅ Do | ❌ Don't |
+|------|---------|
+| Test one concept per test | Test multiple concepts in one test |
+| Use descriptive test names | Use vague test names |
+| Follow Arrange-Act-Assert (AAA) pattern | Mix setup, action, and verification |
+
+```typescript
+// ❌ Bad
+describe('User', () => {
+  it('should work', () => {
+    // tests multiple things at once
+  });
+});
+
+// ✅ Good
+describe('User', () => {
+  it('should throw when name is empty', () => {
+    expect(() => new User('')).toThrow(ValidationError);
+  });
+
+  it('should set the name correctly', () => {
+    const user = new User('John');
+    expect(user.name).toBe('John');
+  });
+});
+```
+
+Reference: [Clean Code TypeScript](https://github.com/labs42io/clean-code-typescript)
+
+[⬆ Back to Top](#codepassion-c9n)
+
+## 7. TypeScript Rules (ESLint)
+We use **ESLint** with **typescript-eslint** to enforce code quality and catch common mistakes at compile time.
+
+### Recommended Rules
+
+| Rule | Description | Why |
+|------|-------------|-----|
+| `@typescript-eslint/no-explicit-any` | Disallow the `any` type | Encourages proper typing over escape hatches |
+| `@typescript-eslint/explicit-function-return-type` | Require return types on functions | Improves readability and prevents unintended return types |
+| `@typescript-eslint/no-unused-vars` | Disallow unused variables | Keeps code clean and avoids dead code |
+| `@typescript-eslint/consistent-type-imports` | Enforce `import type` for type-only imports | Ensures types are erased at compile time |
+| `@typescript-eslint/no-floating-promises` | Require promises to be handled | Prevents silently ignored async errors |
+| `@typescript-eslint/strict-boolean-expressions` | Disallow implicit boolean coercions | Avoids truthy/falsy bugs with strings, numbers, and nulls |
+| `@typescript-eslint/naming-convention` | Enforce naming conventions | Ensures consistent casing across the codebase |
+| `@typescript-eslint/no-non-null-assertion` | Disallow non-null assertions (`!`) | Encourages proper null checks instead of overrides |
+| `@typescript-eslint/no-misused-promises` | Disallow passing promises where not expected | Prevents async bugs in callbacks and conditionals |
+| `@typescript-eslint/prefer-nullish-coalescing` | Prefer `??` over logical OR for nullish values | Avoids unintended falsy coercion with `0`, `""`, or `false` |
+
+### Example ESLint Configuration
+
+```javascript
+// eslint.config.mjs
+import eslint from '@eslint/js';
+import tseslint from 'typescript-eslint';
+
+export default tseslint.config(
+  eslint.configs.recommended,
+  ...tseslint.configs.strictTypeChecked,
+  ...tseslint.configs.stylisticTypeChecked,
+  {
+    languageOptions: {
+      parserOptions: {
+        projectService: true,
+        tsconfigRootDir: import.meta.dirname,
+      },
+    },
+    rules: {
+      '@typescript-eslint/no-explicit-any': 'error',
+      '@typescript-eslint/explicit-function-return-type': 'warn',
+      '@typescript-eslint/no-unused-vars': [
+        'error',
+        { argsIgnorePattern: '^_', varsIgnorePattern: '^_' },
+      ],
+      '@typescript-eslint/consistent-type-imports': [
+        'error',
+        { prefer: 'type-imports' },
+      ],
+      '@typescript-eslint/no-floating-promises': 'error',
+      '@typescript-eslint/strict-boolean-expressions': 'warn',
+      '@typescript-eslint/naming-convention': [
+        'error',
+        { selector: 'variable', format: ['camelCase', 'UPPER_CASE', 'PascalCase'] },
+        { selector: 'function', format: ['camelCase', 'PascalCase'] },
+        { selector: 'typeLike', format: ['PascalCase'] },
+      ],
+      '@typescript-eslint/no-non-null-assertion': 'error',
+      '@typescript-eslint/no-misused-promises': 'error',
+      '@typescript-eslint/prefer-nullish-coalescing': 'warn',
+    },
+  },
+);
+```
+
+### TypeScript Compiler Options
+
+Pair ESLint rules with strict TypeScript compiler settings for maximum safety:
+
+```jsonc
+// tsconfig.json
+{
+  "compilerOptions": {
+    "strict": true,
+    "noUncheckedIndexedAccess": true,
+    "noImplicitOverride": true,
+    "noPropertyAccessFromIndexSignature": true,
+    "forceConsistentCasingInFileNames": true,
+    "verbatimModuleSyntax": true,
+    "exactOptionalPropertyTypes": true
+  }
+}
+```
+
+Reference: [typescript-eslint](https://typescript-eslint.io) · [TSConfig Reference](https://www.typescriptlang.org/tsconfig)
+
+[⬆ Back to Top](#codepassion-c9n)
+
+## 8. Code Formatting
+We use **Prettier** for automatic code formatting and **EditorConfig** for consistent editor settings across IDEs.
+
+### Prettier Configuration
+
+```jsonc
+// .prettierrc
+{
+  "semi": false,
+  "singleQuote": true,
+  "trailingComma": "none",
+  "printWidth": 100,
+  "tabWidth": 2,
+  "useTabs": false,
+  "bracketSpacing": true,
+  "arrowParens": "always",
+  "endOfLine": "lf"
+}
+```
+
+### EditorConfig
+
+```ini
+# .editorconfig
+root = true
+
+[*]
+charset = utf-8
+indent_style = space
+indent_size = 2
+end_of_line = lf
+trim_trailing_whitespace = true
+insert_final_newline = true
+
+[*.md]
+trim_trailing_whitespace = false
+```
+
+### Formatting Guidelines
+
+| ✅ Do | ❌ Don't |
+|------|---------|
+| Use Prettier to format all TypeScript/JavaScript files | Format code manually or inconsistently |
+| Run formatting on save or as a pre-commit hook | Commit unformatted code |
+| Use `.prettierignore` to skip generated files | Format auto-generated or third-party code |
+| Keep Prettier and ESLint configs compatible | Use ESLint for formatting rules (use Prettier instead) |
+| Share `.editorconfig` in the repository | Rely on individual IDE settings |
+
+### Pre-commit Hook (lint-staged)
+
+Automate formatting and linting before each commit:
+
+```jsonc
+// package.json
+{
+  "lint-staged": {
+    "*.{ts,tsx}": ["prettier --write", "eslint --fix"],
+    "*.{json,md,yaml}": ["prettier --write"]
+  }
+}
+```
+
+Reference: [Prettier](https://prettier.io) · [EditorConfig](https://editorconfig.org) · [lint-staged](https://github.com/lint-staged/lint-staged)
+
+[⬆ Back to Top](#codepassion-c9n)
+
+## 9. JSON:API Overview
+We follow the **JSON:API** specification to build consistent, efficient, and predictable RESTful APIs.
+
+### Document Structure
+A JSON:API response uses a standardized top-level structure:
+
+```json
+{
+  "data": {},
+  "included": [],
+  "meta": {},
+  "links": {},
+  "errors": [],
+  "jsonapi": {}
+}
+```
+
+| Member | Purpose | Required |
+|--------|---------|----------|
+| `data` | Primary resource or collection | Yes (for successful responses) |
+| `errors` | Array of error objects | Yes (for error responses) |
+| `meta` | Non-standard meta-information | No |
+| `links` | URLs for pagination and navigation | No |
+| `included` | Related resources (compound documents) | No |
+| `jsonapi` | Server implementation info | No |
+
+### Resource Objects
+Every resource must have a `type` and `id`. Attributes and relationships are placed in their respective members.
+
+```json
+{
+  "data": {
+    "type": "articles",
+    "id": "1",
+    "attributes": {
+      "title": "JSON:API Overview",
+      "body": "A guide to the JSON:API specification."
+    },
+    "relationships": {
+      "author": {
+        "data": { "type": "people", "id": "9" }
+      }
+    },
+    "links": {
+      "self": "https://example.com/articles/1"
+    }
+  }
+}
+```
+
+### Relationships
+Use the `relationships` member to express connections between resources.
+
+| Type | Description | Example |
+|------|-------------|---------|
+| To-one | Links to a single related resource | `"author": { "data": { "type": "people", "id": "9" } }` |
+| To-many | Links to multiple related resources | `"comments": { "data": [{ "type": "comments", "id": "5" }, { "type": "comments", "id": "12" }] }` |
+
+Include related resources in the same response using the `included` array to reduce round-trips:
+
+```json
+{
+  "data": {
+    "type": "articles",
+    "id": "1",
+    "relationships": {
+      "author": {
+        "data": { "type": "people", "id": "9" }
+      }
+    }
+  },
+  "included": [
+    {
+      "type": "people",
+      "id": "9",
+      "attributes": {
+        "name": "John Doe"
+      }
+    }
+  ]
+}
+```
+
+### Links
+Use `links` for discoverability and navigation. They can appear at the top level, per resource, or per relationship.
+
+| Link | Purpose | Example |
+|------|---------|---------|
+| `self` | URL of the current resource or relationship | `"self": "https://example.com/articles/1"` |
+| `related` | URL of a related resource | `"related": "https://example.com/articles/1/author"` |
+| `first` | First page of a collection | `"first": "https://example.com/articles?page[number]=1"` |
+| `last` | Last page of a collection | `"last": "https://example.com/articles?page[number]=10"` |
+| `prev` | Previous page | `"prev": "https://example.com/articles?page[number]=3"` |
+| `next` | Next page | `"next": "https://example.com/articles?page[number]=5"` |
+
+### Error Objects
+Error responses must use the `errors` array instead of `data`:
+
+```json
+{
+  "errors": [
+    {
+      "status": "404",
+      "title": "Resource Not Found",
+      "detail": "The article with id '99' does not exist.",
+      "source": {
+        "pointer": "/data/attributes/article"
+      }
+    }
+  ]
+}
+```
+
+### API Design Guidelines
+
+| ✅ Do | ❌ Don't |
+|------|---------|
+| Use plural resource type names (`articles`, `users`) | Use singular names (`article`, `user`) |
+| Use `attributes` for resource data | Place attributes at the root of the resource object |
+| Use `relationships` to express connections | Nest related resources directly inside `attributes` |
+| Return compound documents with `included` to reduce requests | Require separate requests for every related resource |
+| Use `links` for pagination and discoverability | Hardcode URLs on the client side |
+| Return errors in the `errors` array with `status`, `title`, and `detail` | Return plain text error messages |
+| Use `meta` for non-standard information (e.g., total count) | Add custom top-level members outside the spec |
+| Use sparse fieldsets (`?fields[articles]=title,body`) to limit response size | Always return all fields for every resource |
+| Use `type` and `id` to uniquely identify every resource | Omit `type` or `id` from resource objects |
+
+Reference: [JSON:API](https://jsonapi.org)
+
+[⬆ Back to Top](#codepassion-c9n)
+
+## 10. Go/No Go Release Step
+A structured decision checkpoint that determines whether a release is ready to proceed to the production environment.
+
+### Overview
+The Go/No Go Release Step is a formal decision gate held after QA sign-off and before every production deployment. All required participants must align before the release proceeds.
+
+### Decision Diagram
+
+```mermaid
+flowchart TD
+    A([QA Sign-off Complete]) --> B[Go/No Go Meeting]
+    B --> C{All Criteria Met?}
+    C -- Yes --> D[✅ GO — Proceed to Release]
+    C -- No --> E[🚫 NO GO — Block Release]
+    D --> F[Deploy to Production]
+    F --> G[Monitor & Verify in Production]
+    E --> H[Log Blocking Issues]
+    H --> I[Assign & Resolve Issues]
+    I --> B
+```
+
+### Participants
+
+| Role | Responsibility |
+|------|---------------|
+| **Tech Lead** | Final decision authority; ensures technical readiness |
+| **Developer** | Confirms implementation completeness and deployment steps |
+| **QA Engineer** | Confirms all test cases passed and no critical defects remain |
+| **Product Manager / Owner** | Confirms business requirements and stakeholder readiness |
+
+### Go/No Go Checklist
+
+All items must be **✅ Go** for the release to proceed. A single **🚫 No Go** item blocks the release.
+
+#### Code & Build
+| Criteria | Status |
+|----------|--------|
+| All PRs merged to the release branch | ✅ / 🚫 |
+| CI/CD pipeline passes (build, lint, tests) | ✅ / 🚫 |
+| No known critical or high-severity bugs | ✅ / 🚫 |
+
+#### Testing
+| Criteria | Status |
+|----------|--------|
+| All acceptance criteria verified by QA | ✅ / 🚫 |
+| Regression tests passed | ✅ / 🚫 |
+| Performance benchmarks within acceptable thresholds | ✅ / 🚫 |
+
+#### Deployment Readiness
+| Criteria | Status |
+|----------|--------|
+| Release notes drafted and reviewed | ✅ / 🚫 |
+| Database migrations tested and ready | ✅ / 🚫 |
+| Rollback plan documented and validated | ✅ / 🚫 |
+| Environment configurations verified (env vars, secrets) | ✅ / 🚫 |
+
+#### Stakeholder Alignment
+| Criteria | Status |
+|----------|--------|
+| Product Owner has approved the release scope | ✅ / 🚫 |
+| Support team has been briefed on changes | ✅ / 🚫 |
+| Release window agreed upon by all participants | ✅ / 🚫 |
+
+### Go — Proceed to Release
+When all checklist items are ✅ Go:
+1. Tech Lead officially declares **Go**.
+2. Tag the release branch: `vX.Y.Z`.
+3. Trigger the production deployment pipeline.
+4. Monitor error rates, logs, and alerts post-deployment.
+5. Confirm successful deployment and close the release ticket.
+
+### No Go — Block Release
+When any checklist item is 🚫 No Go:
+1. Tech Lead officially declares **No Go** and states the blocking reason(s).
+2. Blocking issues are logged with owner and target resolution date.
+3. A follow-up Go/No Go meeting is scheduled once issues are resolved.
+4. The release tag is **not** created until all items are ✅ Go.
+
+### Decision Guidelines
+
+| ✅ Go | 🚫 No Go |
+|------|---------|
+| All tests pass with no critical failures | Any critical or high-severity bug unresolved |
+| Deployment steps are documented and rehearsed | Rollback plan is missing or untested |
+| All participants confirmed their readiness | A required participant is unavailable or has not confirmed |
+| Release window is a low-risk period | Release window conflicts with high-traffic or business-critical events |
+| Feature flags in place for incomplete features | Incomplete features are exposed without a feature flag |
+
+[⬆ Back to Top](#codepassion-c9n)
+
+## 11. Deployment Guide (Semantic Versioning 2.0.0)
+We follow **Semantic Versioning 2.0.0** (SemVer) to communicate the impact of every release clearly and predictably.
+
+> **Company standard:** Prefix every semantic version with a lowercase `v` (e.g., `v1.2.3`) to indicate it is a version number. This is the conventional way to express a version in English and aligns with Git tagging practices.
+
+### Version Format
+
+```
+vMAJOR.MINOR.PATCH
+```
+
+| Segment | Meaning | Example change |
+|---------|---------|----------------|
+| `MAJOR` | Incompatible API change | `v1.4.2` → `v2.0.0` |
+| `MINOR` | Backwards-compatible new feature | `v1.4.2` → `v1.5.0` |
+| `PATCH` | Backwards-compatible bug fix | `v1.4.2` → `v1.4.3` |
+
+### Version Increment Rules
+
+| Scenario | Increment | Example |
+|----------|-----------|---------|
+| Removing or renaming a public API, changing existing behaviour in a breaking way | MAJOR | `v2.0.0` |
+| Adding a new feature without breaking existing functionality | MINOR | `v1.5.0` |
+| Fixing a bug, applying a security patch, or making a performance improvement | PATCH | `v1.4.3` |
+| Starting development of the next version after a release | Reset MINOR and PATCH to `0` when MAJOR bumps; reset PATCH to `0` when MINOR bumps | — |
+
+### Pre-release Versions
+
+Append a hyphen and a dot-separated identifier after the version core:
+
+```
+vMAJOR.MINOR.PATCH-<pre-release>
+```
+
+| Identifier | Purpose | Example |
+|------------|---------|---------|
+| `alpha` | Internal, early-stage testing | `v1.5.0` |
+| `beta` | Feature-complete, wider testing | `v1.5.0-beta` |
+| `rc.1`, `rc.2`, … | Release candidate, final verification | `v1.5.0-rc.1` |
+
+Pre-release versions have **lower** precedence than the associated normal version:
+`v1.5.0` < `v1.5.0-beta` < `v1.5.0-rc.1`
+
+### Build Metadata
+
+Append a plus sign and a dot-separated identifier for build information (ignored in precedence comparisons):
+
+```
+v1.5.0+20250401.sha.abc1234
+```
+
+Build metadata is informational only and is **not** used to determine version precedence.
+
+### Tagging Convention
+
+| ✅ Do | ❌ Don't |
+|------|---------|
+| Use `v` prefix on every tag: `v1.2.3` | Omit the prefix: `1.2.3` |
+| Use all-lowercase identifiers: `v1.5.0` | Use mixed case: `v1.5.0` |
+| Reset lower segments on increment: `v2.0.0` after a breaking change | Carry over old MINOR/PATCH: `v2.4.3` |
+| Tag only verified, deployable commits | Tag commits that have not passed CI/CD |
+| Use annotated tags with a release message | Use lightweight tags for production releases |
+
+### Deployment Steps
+
+#### Alpha Environment
+1. Ensure all PRs for the sprint are merged into the `develop` branch.
+2. Pull the latest `develop` branch.
+3. Create and push an annotated pre-release tag:
+   ```bash
+   git tag -a v1.5.0 -m "Release v1.5.0"
+   git push origin v1.5.0
+   ```
+4. The CI/CD pipeline deploys to the Alpha environment automatically.
+5. Validate changes in Alpha and move tickets to **"Ready for QA"**.
+
+#### Production Environment (after Go decision)
+1. Confirm a **Go** decision from the [Go/No Go Release Step](#10-gono-go-release-step).
+2. Pull the latest release branch.
+3. Create a release on the project's repository.
+4. The CI/CD pipeline deploys to the Production environment automatically.
+5. Monitor error rates, logs, and alerts post-deployment.
+6. Confirm successful deployment and close the release ticket.
+
+### Version Precedence Examples
+
+```
+v1.0.0 < v1.0.0.1 < v1.0.0-beta < v1.0.0-rc.1 < v1.0.0
+v1.0.0 < v1.0.1 < v1.1.0 < v2.0.0
+```
+
+Reference: [Semantic Versioning 2.0.0](https://semver.org)
+
+[⬆ Back to Top](#codepassion-c9n)
+
+---
+
+Copyright: https://c9n.co
+
+---
+
+> **C9N** is a [numeronym](https://en.wikipedia.org/wiki/Numeronym) for **CodePassion**:
+> **C** – o[1] – d[2] – e[3] – P[4] – a[5] – s[6] – s[7] – i[8] – o[9] – **N**
+> (the 9 stands for the nine letters between the first letter **C** and the last letter **N**)
+
+*The guidelines and conventions in this document are provided for informational purposes only. They represent the recommended practices of the CodePassion team and are subject to change. No warranty, expressed or implied, is made regarding the accuracy, completeness, or suitability of these guidelines for any particular purpose.*