diff --git a/LLM_DEV_PROMPTS/.dockerignore b/LLM_DEV_PROMPTS/.dockerignore
new file mode 100644
index 0000000..5414d56
--- /dev/null
+++ b/LLM_DEV_PROMPTS/.dockerignore
@@ -0,0 +1,3 @@
+.git
+node_modules
+.DS_Store
diff --git a/LLM_DEV_PROMPTS/.gitignore b/LLM_DEV_PROMPTS/.gitignore
new file mode 100644
index 0000000..afdb9cf
--- /dev/null
+++ b/LLM_DEV_PROMPTS/.gitignore
@@ -0,0 +1,26 @@
+# OS
+.DS_Store
+Thumbs.db
+
+# Editors
+*.swp
+*.swo
+*~
+*.bak
+.idea/
+.vscode/
+*.sublime-*
+
+# Node
+node_modules/
+
+# Environment / secrets
+.env
+.env.*
+*.pem
+*.key
+
+# Prompts
+prompts/
+*prompts
+prompts*
\ No newline at end of file
diff --git a/LLM_DEV_PROMPTS/ANGULAR PROJECTS/ANGULAR_BEST_PRACTICES.md b/LLM_DEV_PROMPTS/ANGULAR PROJECTS/ANGULAR_BEST_PRACTICES.md
new file mode 100644
index 0000000..8ecf0d6
--- /dev/null
+++ b/LLM_DEV_PROMPTS/ANGULAR PROJECTS/ANGULAR_BEST_PRACTICES.md	
@@ -0,0 +1,1561 @@
+## Introduction
+
+1. This guide covers a range of style conventions for Angular application code. These recommendations
+are not required for Angular to work, but instead establish a set of coding practices that promote
+consistency across the Angular ecosystem. A consistent set of practices makes it easier to share
+code and move between projects.
+
+2. This guide does _not_ cover TypeScript or general coding practices unrelated to Angular. For
+TypeScript, check
+out [Google's TypeScript style guide](https://google.github.io/styleguide/tsguide.html).
+
+### When in doubt, prefer consistency
+
+1. Whenever you encounter a situation in which these rules contradict the style of a particular file,
+prioritize maintaining consistency within a file. Mixing different style conventions in a single
+file creates more confusion than diverging from the recommendations in this guide.
+
+## Naming
+
+### Separate words in file names with hyphens
+
+1. Separate words within a file name with hyphens (`-`). For example, a component named `UserProfile`
+has a file name `user-profile.ts`.
+
+### Use the same name for a file's tests with `.spec` at the end
+
+1. For unit tests, end file names with `.spec.ts`. For example, the unit test file for
+the `UserProfile` component has the file name `user-profile.spec.ts`.
+
+### Match file names to the TypeScript identifier within
+
+1. File names should generally describe the contents of the code in the file. When the file contains a
+TypeScript class, the file name should reflect that class name. For example, a file containing a
+component named `UserProfile` has the name `user-profile.ts`.
+
+2. If the file contains more than one primary namable identifier, choose a name that describes the
+common theme to the code within. If the code in a file does not fit within a common theme or feature
+area, consider breaking the code up into different files. Do not use overly generic file names
+like `helpers.ts`, `utils.ts`, or `common.ts`.
+
+### Use the same file name for a component's TypeScript, template, and styles
+
+1. Components typically consist of one TypeScript file, one template file, and one style file. These
+files should share the same name with different file extensions. For example, a `UserProfile`
+component can have the files `user-profile.ts`, `user-profile.html`, and `user-profile.css`.
+
+2. If a component has more than one style file, append the name with additional words that describe the
+styles specific to that file. For example, `UserProfile` might have style
+files `user-profile-settings.css` and `user-profile-subscription.css`.
+
+## Project structure
+
+### All the application's code goes in a directory named `src`
+
+1. All of your Angular UI code (TypeScript, HTML, and styles) should live inside a directory
+named `src`. Code that's not related to UI, such as configuration files or scripts, should live
+outside the `src` directory.
+
+2. This keeps the root application directory consistent between different Angular projects and creates
+a clear separation between UI code and other code in your project.
+
+### Bootstrap your application in a file named `main.ts` directly inside `src`
+
+1. The code to start up, or **bootstrap**, an Angular application should always live in a file
+named `main.ts`. This represents the primary entry point to the application.
+
+### Group closely related files together in the same directory
+
+1. Angular components consist of a TypeScript file and, optionally, a template and one or more style
+files. You should group these together in the same directory.
+
+2. Unit tests should live in the same directory as the code-under-test. Do not collect unrelated
+tests into a single `tests` directory.
+
+### Organize your project by feature areas
+
+1. Organize your project into subdirectories based on the features of your application or common themes
+to the code in those directories. For example, the project structure for a movie theater site,
+MovieReel, might look like this:
+
+```
+src/
+├─ movie-reel/
+│ ├─ show-times/
+│ │ ├─ film-calendar/
+│ │ ├─ film-details/
+│ ├─ reserve-tickets/
+│ │ ├─ payment-info/
+│ │ ├─ purchase-confirmation/
+```
+
+2. Do not create subdirectories based on the type of code that lives in those directories. For
+example, do not create directories like `components`, `directives`, and `services`.
+
+3. Do not put so many files into one directory that it becomes hard to read or navigate. As the
+number of files in a directory grows, consider splitting further into additional sub-directories.
+
+### One concept per file
+
+1. Prefer focusing source files on a single _concept_. For Angular classes specifically, this usually
+means one component, directive, or service per file. However, it's okay if a file contains more than
+one component or directive if your classes are relatively small and they tie together as part of a
+single concept.
+
+2. When in doubt, go with the approach that leads to smaller files.
+
+## Dependency injection
+
+### Prefer the `inject` function over constructor parameter injection
+
+1. Prefer using the [`inject`](/api/core/inject) function over injecting constructor parameters. The [`inject`](/api/core/inject) function works the same way as constructor parameter injection, but offers several style advantages:
+
+- [`inject`](/api/core/inject) is generally more readable, especially when a class injects many dependencies.
+- It's more syntactically straightforward to add comments to injected dependencies
+- [`inject`](/api/core/inject) offers better type inference.
+- When targeting ES2022+ with [`useDefineForClassFields`](https://www.typescriptlang.org/tsconfig/#useDefineForClassFields), you can avoid separating field declaration and initialization when fields read on injected dependencies.
+
+2. [You can refactor existing code to `inject` with an automatic tool](reference/migrations/inject-function).
+
+## Components and directives
+
+### Choosing component selectors
+
+1. See
+the [Components guide for details on choosing component selectors](guide/components/selectors#choosing-a-selector).
+
+### Naming component and directive members
+
+1. See the Components guide for details
+on [naming input properties](guide/components/inputs#choosing-input-names)
+and [naming output properties](guide/components/outputs#choosing-event-names).
+
+### Choosing directive selectors
+
+1. Directives should use the
+same [application-specific prefix](guide/components/selectors#selector-prefixes)
+as your components.
+
+2. When using an attribute selector for a directive, use a camelCase attribute name. For example, if
+your application is named "MovieReel" and you build a directive that adds a tooltip to an element,
+you might use the selector `[mrTooltip]`.
+
+### Group Angular-specific properties before methods
+
+1. Components and directives should group Angular-specific properties together, typically near the top
+of the class declaration. This includes injected dependencies, inputs, outputs, and queries. Define
+these and other properties before the class's methods.
+
+2. This practice makes it easier to find the class's template APIs and dependencies.
+
+### Keep components and directives focused on presentation
+
+1. Code inside your components and directives should generally relate to the UI shown on the page. For
+code that makes sense on its own, decoupled from the UI, prefer refactoring to other files. For
+example, you can factor form validation rules or data transformations into separate functions or
+classes.
+
+### Do not use overly complex logic in templates
+
+1. Angular templates are designed to
+accommodate [JavaScript-like expressions](guide/templates/expression-syntax).
+You should take advantage of these expressions to capture relatively straightforward logic directly
+in template expressions.
+
+2. When the code in a template gets too complex, refactor logic into the TypeScript code (typically with a [computed](guide/signals#computed-signals)).
+
+3. There's no one hard-and-fast rule that determines what constitutes "complex". Use your best
+judgement.
+
+### Use `protected` on class members that are only used by a component's template
+
+1. A component class's public members intrinsically define a public API that's accessible via
+dependency injection and [queries](guide/components/queries). Prefer `protected`
+access for any members that are meant to be read from the component's template.
+
+```ts
+@Component({
+  ...,
+  template: `<p>{{ fullName() }}</p>`,
+})
+export class UserProfile {
+  firstName = input();
+  lastName = input();
+
+// `fullName` is not part of the component's public API, but is used in the template.
+  protected fullName = computed(() => `${this.firstName()} ${this.lastName()}`);
+}
+```
+
+### Use `readonly` for properties that shouldn't change
+
+1. Mark component and directive properties initialized by Angular as `readonly`. This includes
+properties initialized by `input`, `model`, `output`, and queries. The readonly access modifier
+ensures that the value set by Angular is not overwritten.
+
+```ts
+@Component({
+  /*...*/
+})
+export class UserProfile {
+  readonly userId = input();
+  readonly userSaved = output();
+  readonly userName = model();
+}
+```
+
+2. For components and directives that use the decorator-based `@Input`, `@Output`, and query APIs, this
+advice applies to output properties and queries, but not input properties.
+
+```ts
+@Component({
+  /*...*/
+})
+export class UserProfile {
+  @Output() readonly userSaved = new EventEmitter<void>();
+  @ViewChildren(PaymentMethod) readonly paymentMethods?: QueryList<PaymentMethod>;
+}
+```
+
+### Prefer `class` and `style` over `ngClass` and `ngStyle`
+
+1. Prefer `class` and `style` bindings over using the [`NgClass`](/api/common/NgClass) and [`NgStyle`](/api/common/NgStyle) directives.
+
+```html
+{prefer}
+<div [class.admin]="isAdmin" [class.dense]="density === 'high'">
+  <div [style.color]="textColor" [style.background-color]="backgroundColor">
+    <!-- OR -->
+    <div [class]="{admin: isAdmin, dense: density === 'high'}">
+      <div [style]="{'color': textColor, 'background-color': backgroundColor}"></div>
+    </div>
+  </div>
+</div>
+```
+
+```html
+{avoid}
+<div [ngClass]="{admin: isAdmin, dense: density === 'high'}">
+  <div [ngStyle]="{'color': textColor, 'background-color': backgroundColor}"></div>
+</div>
+```
+
+2. Both `class` and `style` bindings use a more straightforward syntax that aligns closely with
+standard HTML attributes. This makes your templates easier to read and understand, especially for
+developers familiar with basic HTML.
+
+3. Additionally, the `NgClass` and `NgStyle` directives incur an additional performance cost compared
+to the built-in `class` and `style` binding syntax.
+
+4. For more details, refer to the [bindings guide](/guide/templates/binding#css-class-and-style-property-bindings)
+
+### Name event handlers for what they _do_, not for the triggering event
+
+1. Prefer naming event handlers for the action they perform rather than for the triggering event:
+
+```html
+{prefer}
+<button (click)="saveUserData()">Save</button>
+```
+
+```html
+{avoid}
+<button (click)="handleClick()">Save</button>
+```
+
+2. Using meaningful names like this makes it easier to tell what an event does from reading the
+template.
+
+3. For keyboard events, you can use Angular's key event modifiers with specific handler names:
+
+```html
+<textarea (keydown.control.enter)="commitNotes()" (keydown.control.space)="showSuggestions()">
+```
+
+4. Sometimes, event handling logic is especially long or complex, making it impractical to declare a
+single well-named handler. In these cases, it's fine to fall back to a name like 'handleKeydown' and
+then delegate to more specific behaviors based on the event details:
+
+```ts
+@Component({
+  /*...*/
+})
+class RichText {
+  handleKeydown(event: KeyboardEvent) {
+    if (event.ctrlKey) {
+      if (event.key === 'B') {
+        this.activateBold();
+      } else if (event.key === 'I') {
+        this.activateItalic();
+      }
+      // ...
+    }
+  }
+}
+```
+
+### Keep lifecycle methods simple
+
+1. Do not put long or complex logic inside lifecycle hooks like `ngOnInit`. Instead, prefer creating
+well-named methods to contain that logic and then _call those methods_ in your lifecycle hooks.
+Lifecycle hook names describe _when_ they run, meaning that the code inside doesn't have a
+meaningful name that describes what the code inside is doing.
+
+```ts
+{prefer}
+ngOnInit() {
+  this.startLogging();
+  this.runBackgroundTask();
+}
+```
+
+```ts
+{avoid}
+ngOnInit() {
+  this.logger.setMode('info');
+  this.logger.monitorErrors();
+  // ...and all the rest of the code that would be unrolled from these methods.
+}
+```
+
+### Use lifecycle hook interfaces
+
+1. Angular provides a TypeScript interface for each lifecycle method. When adding a lifecycle hook to
+your class, import and `implement` these interfaces to ensure that the methods are named correctly.
+
+```ts
+import {Component, OnInit} from '@angular/core';
+
+@Component({
+  /*...*/
+})
+export class UserProfile implements OnInit {
+  // The `OnInit` interface ensures this method is named correctly.
+  ngOnInit() {
+    /* ... */
+  }
+}
+```
+
+2. Components are the main building blocks of Angular applications. Each component represents a part of a larger web page. Organizing an application into components helps provide structure to your project, clearly separating code into specific parts that are easy to maintain and grow over time.
+
+## Defining a component
+
+1. Every component has a few main parts:
+
+    1. A `@Component`[decorator](https://www.typescriptlang.org/docs/handbook/decorators.html) that contains some configuration used by Angular.
+    2. An HTML template that controls what renders into the DOM.
+    3. A [CSS selector](https://developer.mozilla.org/docs/Learn/CSS/Building_blocks/Selectors) that defines how the component is used in HTML.
+    4. A TypeScript class with behaviors, such as handling user input or making requests to a server.
+
+2. Here is a simplified example of a `UserProfile` component.
+
+```typescript
+// user-profile.ts
+@Component({
+  selector: 'user-profile',
+  template: `
+    <h1>User profile</h1>
+    <p>This is the user profile page</p>
+  `,
+})
+export class UserProfile {
+  /* Your component code goes here */
+}
+```
+
+3. The `@Component` decorator also optionally accepts a `styles` property for any CSS you want to apply to your template:
+
+```typescript
+// user-profile.ts
+@Component({
+  selector: 'user-profile',
+  template: `
+    <h1>User profile</h1>
+    <p>This is the user profile page</p>
+  `,
+  styles: `
+    h1 {
+      font-size: 3em;
+    }
+  `,
+})
+export class UserProfile {
+  /* Your component code goes here */
+}
+```
+
+### Separating HTML and CSS into separate files
+
+1. You can define a component's HTML and CSS in separate files using `templateUrl` and `styleUrl`:
+
+```typescript
+// user-profile.ts
+@Component({
+  selector: 'user-profile',
+  templateUrl: 'user-profile.html',
+  styleUrl: 'user-profile.css',
+})
+export class UserProfile {
+  // Component behavior is defined in here
+}
+```
+
+```html
+<!-- user-profile.html -->
+<h1>User profile</h1>
+<p>This is the user profile page</p>
+```
+
+```css
+/* user-profile.css */
+h1 {
+  font-size: 3em;
+}
+```
+
+## Using components
+
+1. You build an application by composing multiple components together. For example, if you are building a user profile page, you might break the page up into several components like this:
+
+```mermaid
+flowchart TD
+    A[UserProfile]-->B
+    A-->C
+    B[UserBiography]-->D
+    C[ProfilePhoto]
+    D[UserAddress]
+```
+
+2. Here, the `UserProfile` component uses several other components to produce the final page.
+
+3. To import and use a component, you need to:
+
+    1. In your component's TypeScript file, add an `import` statement for the component you want to use.
+    2. In your `@Component` decorator, add an entry to the `imports` array for the component you want to use.
+    3. In your component's template, add an element that matches the selector of the component you want to use.
+
+4. Here's an example of a `UserProfile` component importing a `ProfilePhoto` component:
+
+```typescript
+// user-profile.ts
+import {ProfilePhoto} from 'profile-photo.ts';
+
+@Component({
+  selector: 'user-profile',
+  imports: [ProfilePhoto],
+  template: `
+    <h1>User profile</h1>
+    <profile-photo />
+    <p>This is the user profile page</p>
+  `,
+})
+export class UserProfile {
+  // Component behavior is defined in here
+}
+```
+
+5. TIP: Want to know more about Angular components? See the [In-depth Components guide](guide/components) for the full details.
+
+## Next Step
+
+1. Now that you know how components work in Angular, it's time to learn how we add and manage dynamic data in our application.
+# Component selectors
+
+1. TIP: This guide assumes you've already read the [Essentials Guide](essentials). Read that first if you're new to Angular.
+
+2. Every component defines
+a [CSS selector](https://developer.mozilla.org/docs/Web/CSS/CSS_selectors) that determines how
+the component is used:
+
+```typescript
+{highlight: [2]}
+@Component({
+  selector: 'profile-photo',
+  ...
+})
+export class ProfilePhoto { }
+```
+
+3. You use a component by creating a matching HTML element in the templates of _other_ components:
+
+```typescript
+{highlight: [3]}
+@Component({
+  template: `
+    <profile-photo />
+    <button>Upload a new profile photo</button>`,
+  ...,
+})
+export class UserProfile { }
+```
+
+4. **Angular matches selectors statically at compile-time**. Changing the DOM at run-time, either via
+Angular bindings or with DOM APIs, does not affect the components rendered.
+
+5. **An element can match exactly one component selector.** If multiple component selectors match a
+single element, Angular reports an error.
+
+6. **Component selectors are case-sensitive.**
+
+## Types of selectors
+
+1. Angular supports a limited subset
+of [basic CSS selector types](https://developer.mozilla.org/docs/Web/CSS/CSS_Selectors) in
+component selectors:
+
+| **Selector type**  | **Description**                                                                                                 | **Examples**                  |
+| ------------------ | --------------------------------------------------------------------------------------------------------------- | ----------------------------- |
+| Type selector      | Matches elements based on their HTML tag name, or node name.                                                    | `profile-photo`               |
+| Attribute selector | Matches elements based on the presence of an HTML attribute and, optionally, an exact value for that attribute. | `[dropzone]` `[type="reset"]` |
+| Class selector     | Matches elements based on the presence of a CSS class.                                                          | `.menu-item`                  |
+
+2. For attribute values, Angular supports matching an exact attribute value with the equals (`=`)
+operator. Angular does not support other attribute value operators.
+
+3. Angular component selectors do not support combinators, including
+the [descendant combinator](https://developer.mozilla.org/docs/Web/CSS/Descendant_combinator)
+or [child combinator](https://developer.mozilla.org/docs/Web/CSS/Child_combinator).
+
+4. Angular component selectors do not support
+specifying [namespaces](https://developer.mozilla.org/docs/Web/SVG/Namespaces_Crash_Course).
+
+### The `:not` pseudo-class
+
+1. Angular supports [the `:not` pseudo-class](https://developer.mozilla.org/docs/Web/CSS/:not).
+You can append this pseudo-class to any other selector to narrow which elements a component's
+selector matches. For example, you could define a `[dropzone]` attribute selector and prevent
+matching `textarea` elements:
+
+```typescript
+{highlight: [2]}
+@Component({
+  selector: '[dropzone]:not(textarea)',
+  ...
+})
+export class DropZone { }
+```
+
+2. Angular does not support any other pseudo-classes or pseudo-elements in component selectors.
+
+### Combining selectors
+
+1. You can combine multiple selectors by concatenating them. For example, you can match `<button>`
+elements that specify `type="reset"`:
+
+```typescript
+{highlight: [2]}
+@Component({
+  selector: 'button[type="reset"]',
+  ...
+})
+export class ResetButton { }
+```
+
+2. You can also define multiple selectors with a comma-separated list:
+
+```typescript
+{highlight: [2]}
+@Component({
+  selector: 'drop-zone, [dropzone]',
+  ...
+})
+export class DropZone { }
+```
+
+3. Angular creates a component for each element that matches _any_ of the selectors in the list.
+
+## Choosing a selector
+
+1. The vast majority of components should use a custom element name as their selector. All custom
+element names should include a hyphen as described
+by [the HTML specification](https://html.spec.whatwg.org/multipage/custom-elements.html#valid-custom-element-name).
+By default, Angular reports an error if it encounters a custom tag name that does not match any
+available components, preventing bugs due to mistyped component names.
+
+2. See [Advanced component configuration](guide/components/advanced-configuration) for details on
+using [native custom elements](https://developer.mozilla.org/docs/Web/Web_Components) in
+Angular templates.
+
+### Selector prefixes
+
+1. The Angular team recommends using a short, consistent prefix for all the custom components
+defined inside your project. For example, if you were to build YouTube with Angular, you might
+prefix your components with `yt-`, with components like `yt-menu`, `yt-player`, etc. Namespacing
+your selectors like this makes it immediately clear where a particular component comes from. By
+default, the Angular CLI uses `app-`.
+
+2. IMPORTANT: Angular uses the `ng` selector prefix for its own framework APIs. Never use `ng` as a selector prefix for your own custom components.
+
+### When to use an attribute selector
+
+1. You should consider an attribute selector when you want to create a component on a standard native
+element. For example, if you want to create a custom button component, you can take advantage of the
+standard `<button>` element by using an attribute selector:
+
+```typescript
+{highlight: [2]}
+@Component({
+  selector: 'button[yt-upload]',
+   ...
+})
+export class YouTubeUploadButton { }
+```
+
+2. This approach allows consumers of the component to directly use all the element's standard APIs
+without extra work. This is especially valuable for ARIA attributes such as `aria-label`.
+
+3. Angular does not report errors when it encounters custom attributes that don't match an available
+component. When using components with attribute selectors, consumers may forget to import the
+component or its NgModule, resulting in the component not rendering.
+See [Importing and using components](guide/components#imports-in-the-component-decorator) for more information.
+
+4. Components that define attribute selectors should use lowercase, dash-case attributes. You can
+follow the same prefixing recommendation described above.
+# Styling components
+
+1. TIP: This guide assumes you've already read the [Essentials Guide](essentials). Read that first if you're new to Angular.
+
+2. Components can optionally include CSS styles that apply to that component's DOM:
+
+```typescript
+{highlight:[4]}
+@Component({
+  selector: 'profile-photo',
+  template: `<img src="profile-photo.jpg" alt="Your profile photo" />`,
+  styles: `
+    img {
+      border-radius: 50%;
+    }
+  `,
+})
+export class ProfilePhoto {}
+```
+
+3. You can also choose to write your styles in separate files:
+
+```typescript
+{highlight:[4]}
+@Component({
+  selector: 'profile-photo',
+  templateUrl: 'profile-photo.html',
+  styleUrl: 'profile-photo.css',
+})
+export class ProfilePhoto {}
+```
+
+4. When Angular compiles your component, these styles are emitted with your component's JavaScript
+output. This means that component styles participate in the JavaScript module system. When you
+render an Angular component, the framework automatically includes its associated styles, even when
+lazy-loading a component.
+
+5. Angular works with any tool that outputs CSS,
+including [Sass](https://sass-lang.com), [less](https://lesscss.org),
+and [stylus](https://stylus-lang.com).
+
+## Style scoping
+
+1. Every component has a **view encapsulation** setting that determines how the framework scopes a
+component's styles. There are four view encapsulation modes: `Emulated`, `ShadowDom`, `ExperimentalIsolatedShadowDom`, and `None`.
+You can specify the mode in the `@Component` decorator:
+
+```typescript
+{highlight:[3]}
+@Component({
+  ...,
+  encapsulation: ViewEncapsulation.None,
+})
+export class ProfilePhoto { }
+```
+#### `::ng-deep`
+
+1. Angular's emulated encapsulation mode supports a custom pseudo class, `::ng-deep`.
+**The Angular team strongly discourages new use of `::ng-deep`**. These APIs remain
+exclusively for backwards compatibility.
+
+## Defining styles in templates
+
+1. You can use the `<style>` element in a component's template to define additional styles. The component's view encapsulation mode applies to styles defined this way.
+
+2. Angular does not support bindings inside of style elements.
+
+## Referencing external style files
+
+1. Component templates can
+use [the `<link>` element](https://developer.mozilla.org/docs/Web/HTML/Element/link) to reference CSS files. Additionally, your CSS may use [the `@import`at-rule](https://developer.mozilla.org/docs/Web/CSS/@import) to reference
+CSS files. Angular treats these references as _external_ styles. External styles are not affected by emulated view encapsulation.
+# Accepting data with input properties
+
+1. TIP: This guide assumes you've already read the [Essentials Guide](essentials). Read that first if you're new to Angular.
+
+2. TIP: If you're familiar with other web frameworks, input properties are similar to _props_.
+
+3. When you use a component, you commonly want to pass some data to it. A component specifies the data that it accepts by declaring
+**inputs**:
+
+```ts
+{highlight:[8]}
+import {Component, input} from '@angular/core';
+
+@Component({
+  /*...*/
+})
+export class CustomSlider {
+  // Declare an input named 'value' with a default value of zero.
+  value = input(0);
+}
+```
+
+4. This lets you bind to the property in a template:
+
+```html
+<custom-slider [value]="50" />
+```
+
+5. If an input has a default value, TypeScript infers the type from the default value:
+
+```ts
+@Component({
+  /*...*/
+})
+export class CustomSlider {
+  // TypeScript infers that this input is a number, returning InputSignal<number>.
+  value = input(0);
+}
+```
+
+6. You can explicitly declare a type for the input by specifying a generic parameter to the function.
+
+7. If an input without a default value is not set, its value is `undefined`:
+
+```ts
+@Component({
+  /*...*/
+})
+export class CustomSlider {
+  // Produces an InputSignal<number | undefined> because `value` may not be set.
+  value = input<number>();
+}
+```
+
+8. **Angular records inputs statically at compile-time**. Inputs cannot be added or removed at run-time.
+
+9. The `input` function has special meaning to the Angular compiler. **You can exclusively call `input` in component and directive property initializers.**
+
+10. When extending a component class, **inputs are inherited by the child class.**
+
+11. **Input names are case-sensitive.**
+
+## Reading inputs
+
+1. The `input` function returns an `InputSignal`. You can read the value by calling the signal:
+
+```ts
+{highlight:[11]}
+import {Component, input, computed} from '@angular/core';
+
+@Component({
+  /*...*/
+})
+export class CustomSlider {
+  // Declare an input named 'value' with a default value of zero.
+  value = input(0);
+
+  // Create a computed expression that reads the value input
+  label = computed(() => `The slider's value is ${this.value()}`);
+}
+```
+
+2. Signals created by the `input` function are read-only.
+
+## Required inputs
+
+1. You can declare that an input is `required` by calling `input.required` instead of `input`:
+
+```ts
+{highlight:[6]}
+@Component({
+  /*...*/
+})
+export class CustomSlider {
+  // Declare a required input named value. Returns an `InputSignal<number>`.
+  value = input.required<number>();
+}
+```
+
+2. Angular enforces that required inputs _must_ be set when the component is used in a template. If you try to use a component without specifying all of its required inputs, Angular reports an error at build-time.
+
+3. Required inputs do not automatically include `undefined` in the generic parameter of the returned `InputSignal`.
+
+## Configuring inputs
+
+1. The `input` function accepts a config object as a second parameter that lets you change the way that input works.
+
+### Input transforms
+
+You can specify a `transform` function to change the value of an input when it's set by Angular.
+
+```ts
+{highlight:[6]}
+@Component({
+  selector: 'custom-slider',
+  /*...*/
+})
+export class CustomSlider {
+  label = input('', {transform: trimString});
+}
+
+function trimString(value: string | undefined): string {
+  return value?.trim() ?? '';
+}
+```
+
+```html
+<custom-slider [label]="systemVolume" />
+```
+
+2. In the example above, whenever the value of `systemVolume` changes, Angular runs `trimString` and sets `label` to the result.
+
+3. The most common use-case for input transforms is to accept a wider range of value types in templates, often including `null` and `undefined`.
+
+4. **Input transform function must be statically analyzable at build-time.** You cannot set transform functions conditionally or as the result of an expression evaluation.
+
+5. **Input transform functions should always be [pure functions](https://en.wikipedia.org/wiki/Pure_function).** Relying on state outside the transform function can lead to unpredictable behavior.
+
+#### Type checking
+
+1. When you specify an input transform, the type of the transform function's parameter determines the types of values that can be set to the input in a template.
+
+```ts
+@Component({
+  /*...*/
+})
+export class CustomSlider {
+  widthPx = input('', {transform: appendPx});
+}
+
+function appendPx(value: number): string {
+  return `${value}px`;
+}
+```
+
+2. In the example above, the `widthPx` input accepts a `number` while the `InputSignal` property returns a `string`.
+
+#### Built-in transformations
+
+1. Angular includes two built-in transform functions for the two most common scenarios: coercing values to boolean and numbers.
+
+```ts
+import {Component, input, booleanAttribute, numberAttribute} from '@angular/core';
+
+@Component({
+  /*...*/
+})
+export class CustomSlider {
+  disabled = input(false, {transform: booleanAttribute});
+  value = input(0, {transform: numberAttribute});
+}
+```
+
+2. `booleanAttribute` imitates the behavior of standard HTML [boolean attributes](https://developer.mozilla.org/docs/Glossary/Boolean/HTML), where the
+_presence_ of the attribute indicates a "true" value. However, Angular's `booleanAttribute` treats the literal string `"false"` as the boolean `false`.
+
+3. `numberAttribute` attempts to parse the given value to a number, producing `NaN` if parsing fails.
+
+### Input aliases
+
+1. You can specify the `alias` option to change the name of an input in templates.
+
+```ts
+{highlight:[5]}
+@Component({
+  /*...*/
+})
+export class CustomSlider {
+  value = input(0, {alias: 'sliderValue'});
+}
+```
+
+```html
+<custom-slider [sliderValue]="50" />
+```
+
+2. This alias does not affect usage of the property in TypeScript code.
+
+3. While you should generally not alias inputs for components, this feature can be useful for renaming properties while preserving an alias for the original name or for avoiding collisions with the name of native DOM element properties.
+
+## Model inputs
+
+1. **Model inputs** are a special type of input that enable a component to propagate new values back to its parent component.
+
+2. When creating a component, you can define a model input similarly to how you create a standard input.
+
+3. Both types of input allow someone to bind a value into the property. However, **model inputs allow the component author to write values into the property**. If the property is bound with a two-way binding, the new value propagates to that binding.
+
+```ts
+@Component({
+  /* ... */
+})
+export class CustomSlider {
+  // Define a model input named "value".
+  value = model(0);
+
+  increment() {
+    // Update the model input with a new value, propagating the value to any bindings.
+    this.value.update((oldValue) => oldValue + 10);
+  }
+}
+
+@Component({
+  /* ... */
+  // Using the two-way binding syntax means that any changes to the slider's
+  // value automatically propagate back to the `volume` signal.
+  // Note that this binding uses the signal *instance*, not the signal value.
+  template: `<custom-slider [(value)]="volume" />`,
+})
+export class MediaControls {
+  // Create a writable signal for the `volume` local state.
+  volume = signal(0);
+}
+```
+
+4. In the above example, the `CustomSlider` can write values into its `value` model input, which then propagates those values back to the `volume` signal in `MediaControls`. This binding keeps the values of `value` and `volume` in sync. Notice that the binding passes the `volume` signal instance, not the _value_ of the signal.
+
+5. In other respects, model inputs work similarly to standard inputs. You can read the value by calling the signal function, including in [reactive contexts](guide/signals#reactive-contexts) like `computed` and `effect`.
+
+6. See [Two-way binding](guide/templates/two-way-binding) for more details on two-way binding in templates.
+
+### Two-way binding with plain properties
+
+1. You can bind a plain JavaScript property to a model input.
+
+```typescript
+@Component({
+  /* ... */
+  // `value` is a model input.
+  // The parenthesis-inside-square-brackets syntax (aka "banana-in-a-box") creates a two-way binding
+  template: '<custom-slider [(value)]="volume" />',
+})
+export class MediaControls {
+  protected volume = 0;
+}
+```
+
+2. In the example above, the `CustomSlider` can write values into its `value` model input, which then propagates those values back to the `volume` property in `MediaControls`. This binding keeps the values of `value` and `volume` in sync.
+
+### Implicit `change` events
+
+1. When you declare a model input in a component or directive, Angular automatically creates a corresponding [output](guide/components/outputs) for that model. The output's name is the model input's name suffixed with "Change".
+
+```ts
+@Directive({
+  /* ... */
+})
+export class CustomCheckbox {
+  // This automatically creates an output named "checkedChange".
+  // Can be subscribed to using `(checkedChange)="handler()"` in the template.
+  checked = model(false);
+}
+```
+
+2. Angular emits this change event whenever you write a new value into the model input by calling its `set` or `update` methods.
+
+3. See [Custom events with outputs](guide/components/outputs) for more details on outputs.
+
+### Customizing model inputs
+
+1. You can mark a model input as required or provide an alias in the same way as a [standard input](guide/components/inputs).
+
+2. Model inputs do not support input transforms, so do not attempt them.
+
+### When to use model inputs
+
+1. Use model inputs when you want a component to support two-way binding. This is typically appropriate when a component exists to modify a value based on user interaction. Most commonly, custom form controls, such as a date picker or combobox, should use model inputs for their primary value.
+
+## Choosing input names
+
+1. Do not choose input names that collide with properties on DOM elements like HTMLElement. Name collisions introduce confusion about whether the bound property belongs to the component or the DOM element.
+
+2. Do not add prefixes for component inputs like you would with component selectors. Since a given element can only host one component, any custom properties can be assumed to belong to the component.
+
+## Declaring inputs with the `@Input` decorator
+
+1. While the Angular team recommends using the signal-based `input` function for new projects, the original decorator-based `@Input` API is fully supported.
+
+2. You can alternatively declare component inputs by adding the `@Input` decorator to a property:
+
+```ts
+{highlight:[5]}
+@Component({
+  /*...*/
+})
+export class CustomSlider {
+  @Input() value = 0;
+}
+```
+
+3. Binding to an input is the same in both signal-based and decorator-based inputs:
+
+```html
+<custom-slider [value]="50" />
+```
+
+### Customizing decorator-based inputs
+
+1. The `@Input` decorator accepts a config object that lets you change the way that input works.
+
+#### Required inputs
+
+1. You can specify the `required` option to enforce that a given input must always have a value.
+
+```ts
+{highlight:[5]}
+@Component({
+  /*...*/
+})
+export class CustomSlider {
+  @Input({required: true}) value = 0;
+}
+```
+
+2. If you try to use a component without specifying all of its required inputs, Angular reports an error at build-time.
+
+#### Input transforms
+
+1. You can specify a `transform` function to change the value of an input when it's set by Angular. This transform function works identically to transform functions for signal-based inputs described above.
+
+```ts
+{highlight:[6]}
+@Component({
+  selector: 'custom-slider',
+  ...
+})
+export class CustomSlider {
+  @Input({transform: trimString}) label = '';
+}
+
+function trimString(value: string | undefined) {
+  return value?.trim() ?? '';
+}
+```
+
+#### Input aliases
+
+1. You can specify the `alias` option to change the name of an input in templates.
+
+```ts
+{highlight:[5]}
+@Component({
+  /*...*/
+})
+export class CustomSlider {
+  @Input({alias: 'sliderValue'}) value = 0;
+}
+```
+
+```html
+<custom-slider [sliderValue]="50" />
+```
+
+2. The `@Input` decorator also accepts the alias as its first parameter in place of the config object.
+
+3. Input aliases work the same way as for signal-based inputs described above.
+
+### Inputs with getters and setters
+
+1. When using decorator-based inputs, a property implemented with a getter and setter can be an input:
+
+```ts
+export class CustomSlider {
+  @Input()
+  get value(): number {
+    return this.internalValue;
+  }
+
+  set value(newValue: number) {
+    this.internalValue = newValue;
+  }
+
+  private internalValue = 0;
+}
+```
+
+2. You can even create a _write-only_ input by only defining a public setter:
+
+```ts
+export class CustomSlider {
+  @Input()
+  set value(newValue: number) {
+    this.internalValue = newValue;
+  }
+
+  private internalValue = 0;
+}
+```
+
+3. **Prefer using input transforms instead of getters and setters** if possible.
+
+4. Do not use complex or costly getters and setters. Angular may invoke an input's setter multiple times, which may negatively impact application performance if the setter performs any costly behaviors, such as DOM manipulation.
+
+## Specify inputs in the `@Component` decorator
+
+1. In addition to the `@Input` decorator, you can also specify a component's inputs with the `inputs` property in the `@Component` decorator. This can be useful when a component inherits a property from a base class:
+
+```ts
+{highlight:[4]}
+// `CustomSlider` inherits the `disabled` property from `BaseSlider`.
+@Component({
+  ...,
+  inputs: ['disabled'],
+})
+export class CustomSlider extends BaseSlider { }
+```
+
+2. You can additionally specify an input alias in the `inputs` list by putting the alias after a colon in the string:
+
+```ts
+{highlight:[4]}
+// `CustomSlider` inherits the `disabled` property from `BaseSlider`.
+@Component({
+  ...,
+  inputs: ['disabled: sliderDisabled'],
+})
+export class CustomSlider extends BaseSlider { }
+```
+# Custom events with outputs
+
+1. TIP: This guide assumes you've already read the [Essentials Guide](essentials). Read that first if you're new to Angular.
+
+2. Angular components can define custom events by assigning a property to the `output` function:
+
+```ts
+{highlight:[3]}
+@Component({
+  /*...*/
+})
+export class ExpandablePanel {
+  panelClosed = output<void>();
+}
+```
+
+```html
+<expandable-panel (panelClosed)="savePanelState()" />
+```
+
+3. The `output` function returns an `OutputEmitterRef`. You can emit an event by calling the `emit` method on the `OutputEmitterRef`:
+
+```ts
+this.panelClosed.emit();
+```
+
+4. Angular refers to properties initialized with the `output` function as **outputs**. You can use outputs to raise custom events, similar to native browser events like `click`.
+
+5. **Angular custom events do not bubble up the DOM**.
+
+6. **Output names are case-sensitive.**
+
+7. When extending a component class, **outputs are inherited by the child class.**
+
+8. The `output` function has special meaning to the Angular compiler. **You can exclusively call `output` in component and directive property initializers.**
+
+## Emitting event data
+
+1. You can pass event data when calling `emit`:
+
+```ts
+// You can emit primitive values.
+this.valueChanged.emit(7);
+
+// You can emit custom event objects
+this.thumbDropped.emit({
+  pointerX: 123,
+  pointerY: 456,
+});
+```
+
+2. When defining an event listener in a template, you can access the event data from the `$event` variable:
+
+```html
+<custom-slider (valueChanged)="logValue($event)" />
+```
+
+3. Receive the event data in the parent component:
+
+```ts
+@Component({
+ /*...*/
+})
+export class App {
+  logValue(value: number) {
+    ...
+  }
+}
+
+```
+
+## Customizing output names
+
+1. The `output` function accepts a parameter that lets you specify a different name for the event in a template:
+
+```ts
+@Component({
+  /*...*/
+})
+export class CustomSlider {
+  changed = output({alias: 'valueChanged'});
+}
+```
+
+```html
+<custom-slider (valueChanged)="saveVolume()" />
+```
+
+2. This alias does not affect usage of the property in TypeScript code.
+
+3. While you should generally not alias outputs for components, this feature can be useful for renaming properties while preserving an alias for the original name or for avoiding collisions with the name of native DOM events.
+
+## Subscribing to outputs programmatically
+
+1. When creating a component dynamically, you can programmatically subscribe to output events from the component instance. The `OutputRef` type includes a `subscribe` method:
+
+```ts
+const someComponentRef: ComponentRef<SomeComponent> = viewContainerRef.createComponent(/*...*/);
+
+someComponentRef.instance.someEventProperty.subscribe((eventData) => {
+  console.log(eventData);
+});
+```
+
+2. Angular automatically cleans up event subscriptions when it destroys components with subscribers. Alternatively, you can manually unsubscribe from an event. The `subscribe` function returns an `OutputRefSubscription` with an `unsubscribe` method:
+
+```ts
+const eventSubscription = someComponent.someEventProperty.subscribe((eventData) => {
+  console.log(eventData);
+});
+
+// ...
+
+eventSubscription.unsubscribe();
+```
+
+## Choosing event names
+
+1. Do not choose output names that collide with events on DOM elements like HTMLElement. Name collisions introduce confusion about whether the bound property belongs to the component or the DOM element.
+
+2. Do not add prefixes for component outputs like you would with component selectors. Since a given element can only host one component, any custom properties can be assumed to belong to the component.
+
+3. Always use [camelCase](https://en.wikipedia.org/wiki/Camel_case) output names. Do not prefix output names with "on".
+
+## Using outputs with RxJS
+
+1. See [RxJS interop with component and directive outputs](ecosystem/rxjs-interop/output-interop) for details on interoperability between outputs and RxJS.
+
+## Declaring outputs with the `@Output` decorator
+
+1. TIP: While the Angular team recommends using the `output` function for new projects, the
+original decorator-based `@Output` API remains fully supported.
+
+2. You can alternatively define custom events by assigning a property to a new `EventEmitter` and adding the `@Output` decorator:
+
+```ts
+@Component({
+  /*...*/
+})
+export class ExpandablePanel {
+  @Output() panelClosed = new EventEmitter<void>();
+}
+```
+
+3. You can emit an event by calling the `emit` method on the `EventEmitter`.
+
+### Aliases with the `@Output` decorator
+
+1. The `@Output` decorator accepts a parameter that lets you specify a different name for the event in a template:
+
+```ts
+@Component({
+  /*...*/
+})
+export class CustomSlider {
+  @Output('valueChanged') changed = new EventEmitter<number>();
+}
+```
+
+```html
+<custom-slider (valueChanged)="saveVolume()" />
+```
+
+2. This alias does not affect usage of the property in TypeScript code.
+
+## Specify outputs in the `@Component` decorator
+
+1. In addition to the `@Output` decorator, you can also specify a component's outputs with the `outputs` property in the `@Component` decorator. This can be useful when a component inherits a property from a base class:
+
+```ts
+// `CustomSlider` inherits the `valueChanged` property from `BaseSlider`.
+@Component({
+  /*...*/
+  outputs: ['valueChanged'],
+})
+export class CustomSlider extends BaseSlider {}
+```
+
+2. You can additionally specify an output alias in the `outputs` list by putting the alias after a colon in the string:
+
+```ts
+// `CustomSlider` inherits the `valueChanged` property from `BaseSlider`.
+@Component({
+  /*...*/
+  outputs: ['valueChanged: volumeChanged'],
+})
+export class CustomSlider extends BaseSlider {}
+```
+# Content projection with ng-content
+
+1. TIP: This guide assumes you've already read the [Essentials Guide](essentials). Read that first if you're new to Angular.
+
+2. You often need to create components that act as containers for different types of content. For example, you may want to create a custom card component:
+
+```typescript
+@Component({
+  selector: 'custom-card',
+  template: '<div class="card-shadow"> <!-- card content goes here --> </div>',
+})
+export class CustomCard {
+  /* ... */
+}
+```
+
+3. **You can use the `<ng-content>` element as a placeholder to mark where content should go**:
+
+```typescript
+@Component({
+  selector: 'custom-card',
+  template: '<div class="card-shadow"> <ng-content/> </div>',
+})
+export class CustomCard {
+  /* ... */
+}
+```
+
+4. TIP: `<ng-content>` works similarly
+to [the native `<slot>` element](https://developer.mozilla.org/docs/Web/HTML/Element/slot), but with some Angular-specific functionality.
+
+5. When you use a component with `<ng-content>`, any children of the component host element are rendered, or **projected**, at the location of that `<ng-content>`:
+
+```typescript
+// Component source
+@Component({
+  selector: 'custom-card',
+  template: `
+    <div class="card-shadow">
+      <ng-content />
+    </div>
+  `,
+})
+export class CustomCard {
+  /* ... */
+}
+```
+
+```html
+<!-- Using the component -->
+<custom-card>
+  <p>This is the projected content</p>
+</custom-card>
+```
+
+```html
+<!-- The rendered DOM -->
+<custom-card>
+  <div class="card-shadow">
+    <p>This is the projected content</p>
+  </div>
+</custom-card>
+```
+
+6. Angular refers to any children of a component passed this way as that component's **content**. This is distinct from the component's **view**, which refers to the elements defined in the component's template.
+
+7. **The `<ng-content>` element is neither a component nor DOM element**. Instead, it is a special placeholder that tells Angular where to render content. Angular's compiler processes all `<ng-content>` elements at build-time. You cannot insert, remove, or modify `<ng-content>` at run time. You cannot add directives, styles, or arbitrary attributes to `<ng-content>`.
+
+8. IMPORTANT: Do not conditionally include `<ng-content>` with `@if`, `@for`, or `@switch`. Angular always instantiates and creates DOM nodes for content rendered to a `<ng-content>` placeholder, even if that `<ng-content>` placeholder is hidden. For conditional rendering of component content, see [Template fragments](api/core/ng-template).
+
+## Multiple content placeholders
+
+1. Angular supports projecting multiple different elements into different `<ng-content>` placeholders
+based on CSS selector. Expanding the card example from above, you could create two placeholders for
+a card title and a card body by using the `select` attribute:
+
+```typescript
+@Component({
+  selector: 'card-title',
+  template: `<ng-content>card-title</ng-content>`,
+})
+export class CardTitle {}
+
+@Component({
+  selector: 'card-body',
+  template: `<ng-content>card-body</ng-content>`,
+})
+export class CardBody {}
+```
+
+```typescript
+<!-- Component template -->
+@Component({
+  selector: 'custom-card',
+  template: `
+  <div class="card-shadow">
+    <ng-content select="card-title"></ng-content>
+    <div class="card-divider"></div>
+    <ng-content select="card-body"></ng-content>
+  </div>
+  `,
+})
+export class CustomCard {}
+```
+
+```typescript
+<!-- Using the component -->
+@Component({
+  selector: 'app-root',
+  imports: [CustomCard, CardTitle, CardBody],
+  template: `
+    <custom-card>
+      <card-title>Hello</card-title>
+      <card-body>Welcome to the example</card-body>
+    </custom-card>
+`,
+})
+export class App {}
+```
+
+```html
+<!-- Rendered DOM -->
+<custom-card>
+  <div class="card-shadow">
+    <card-title>Hello</card-title>
+    <div class="card-divider"></div>
+    <card-body>Welcome to the example</card-body>
+  </div>
+</custom-card>
+```
+
+2. The `<ng-content>` placeholder supports the same CSS selectors
+as [component selectors](guide/components/selectors).
+
+3. If you include one or more `<ng-content>` placeholders with a `select` attribute and
+one `<ng-content>` placeholder without a `select` attribute, the latter captures all elements that
+did not match a `select` attribute:
+
+```html
+<!-- Component template -->
+<div class="card-shadow">
+  <ng-content select="card-title"></ng-content>
+  <div class="card-divider"></div>
+  <!-- capture anything except "card-title" -->
+  <ng-content></ng-content>
+</div>
+```
+
+```html
+<!-- Using the component -->
+<custom-card>
+  <card-title>Hello</card-title>
+  <img src="..." />
+  <p>Welcome to the example</p>
+</custom-card>
+```
+
+```html
+<!-- Rendered DOM -->
+<custom-card>
+  <div class="card-shadow">
+    <card-title>Hello</card-title>
+    <div class="card-divider"></div>
+    <img src="..." />
+    <p>Welcome to the example</p>
+  </div>
+</custom-card>
+```
+
+4. If a component does not include an `<ng-content>` placeholder without a `select` attribute, any elements that don't match one of the component's placeholders do not render into the DOM.
+
+## Fallback content
+
+1. Angular can show _fallback content_ for a component's `<ng-content>` placeholder if that component doesn't have any matching child content. You can specify fallback content by adding child content to the `<ng-content>` element itself.
+
+```html
+<!-- Component template -->
+<div class="card-shadow">
+  <ng-content select="card-title">Default Title</ng-content>
+  <div class="card-divider"></div>
+  <ng-content select="card-body">Default Body</ng-content>
+</div>
+```
+
+```html
+<!-- Using the component -->
+<custom-card>
+  <card-title>Hello</card-title>
+  <!-- No card-body provided -->
+</custom-card>
+```
+
+```html
+<!-- Rendered DOM -->
+<custom-card>
+  <div class="card-shadow">
+    <card-title>Hello</card-title>
+    <div class="card-divider"></div>
+    Default Body
+  </div>
+</custom-card>
+```
+
+## Aliasing content for projection
+
+1. Angular supports a special attribute, `ngProjectAs`, that allows you to specify a CSS selector on
+any element. Whenever an element with `ngProjectAs` is checked against an `<ng-content>`
+placeholder, Angular compares against the `ngProjectAs` value instead of the element's identity:
+
+```html
+<!-- Component template -->
+<div class="card-shadow">
+  <ng-content select="card-title"></ng-content>
+  <div class="card-divider"></div>
+  <ng-content />
+</div>
+```
+
+```html
+<!-- Using the component -->
+<custom-card>
+  <h3 ngProjectAs="card-title">Hello</h3>
+
+  <p>Welcome to the example</p>
+</custom-card>
+```
+
+```html
+<!-- Rendered DOM -->
+<custom-card>
+  <div class="card-shadow">
+    <h3>Hello</h3>
+    <div class="card-divider"></div>
+    <p>Welcome to the example</p>
+  </div>
+</custom-card>
+```
+
+2. `ngProjectAs` supports only static values and cannot be bound to dynamic expressions.
+# Component Lifecycle
+
+1. TIP: This guide assumes you've already read the [Essentials Guide](essentials). Read that first if you're new to Angular.
+
+2. A component's **lifecycle** is the sequence of steps that happen between the component's creation and its destruction. Each step represents a different part of Angular's process for rendering components and checking them for updates over time.
+
+3. In your components, you can implement **lifecycle hooks** to run code during these steps.
+Lifecycle hooks that relate to a specific component instance are implemented as methods on your component class. Lifecycle hooks that relate the Angular application as a whole are implemented as functions that accept a callback.
+
+4. A component's lifecycle is tightly connected to how Angular checks your components for changes over time. For the purposes of understanding this lifecycle, you only need to know that Angular walks your application tree from top to bottom, checking template bindings for changes. The lifecycle hooks described below run while Angular is doing this traversal. This traversal visits each component exactly once, so you should always not make further state changes in the middle of the process.
\ No newline at end of file
diff --git a/LLM_DEV_PROMPTS/ANGULAR PROJECTS/CODE_STYLEGUIDE_ANGULAR.md b/LLM_DEV_PROMPTS/ANGULAR PROJECTS/CODE_STYLEGUIDE_ANGULAR.md
new file mode 100644
index 0000000..38afc46
--- /dev/null
+++ b/LLM_DEV_PROMPTS/ANGULAR PROJECTS/CODE_STYLEGUIDE_ANGULAR.md	
@@ -0,0 +1,47 @@
+You are an expert in TypeScript, Angular, and scalable web application development. You write functional, maintainable, performant, and accessible code following Angular and TypeScript best practices.
+
+## TypeScript Best Practices
+1. Use strict type checking
+2. Prefer type inference when the type is obvious
+3. Avoid the `any` type; use `unknown` when type is uncertain
+
+## Angular Best Practices
+1. Always use standalone components over NgModules
+2. Must NOT set `standalone: true` inside Angular decorators. It's the default in Angular v20+.
+3. Use signals for state management
+4. Implement lazy loading for feature routes
+5. Do NOT use the `@HostBinding` and `@HostListener` decorators. Put host bindings inside the `host` object of the `@Component` or `@Directive` decorator instead
+6. Use `NgOptimizedImage` for all static images.
+7. Note: `NgOptimizedImage` does not work for inline base64 images.
+
+## Accessibility Requirements
+1. It MUST pass all AXE checks.
+2. It MUST follow all WCAG AA minimums, including focus management, color contrast, and ARIA attributes.
+
+### Components
+1. Keep components small and focused on a single responsibility
+2. Use `input()` and `output()` functions instead of decorators
+3. Use `computed()` for derived state
+4. Set `changeDetection: ChangeDetectionStrategy.OnPush` in `@Component` decorator
+5. Prefer inline templates for small components
+6. Prefer Reactive forms instead of Template-driven ones
+7. Do NOT use `ngClass`, use `class` bindings instead
+8. Do NOT use `ngStyle`, use `style` bindings instead
+9. When using external templates/styles, use paths relative to the component TS file.
+
+## State Management
+1. Use signals for local component state
+2. Use `computed()` for derived state
+3. Keep state transformations pure and predictable
+4. Do NOT use `mutate` on signals, use `update` or `set` instead
+
+## Templates
+1. Keep templates simple and avoid complex logic
+2. Use native control flow (`@if`, `@for`, `@switch`) instead of `*ngIf`, `*ngFor`, `*ngSwitch`
+3. Use the async pipe to handle observables
+4. Do not assume globals like (`new Date()`) are available.
+
+## Services
+1. Design services around a single responsibility
+2. Use the `providedIn: 'root'` option for singleton services
+3. Use the `inject()` function instead of constructor injection
\ No newline at end of file
diff --git a/LLM_DEV_PROMPTS/A_EXISTING_REPO_CHECKLIST.md b/LLM_DEV_PROMPTS/A_EXISTING_REPO_CHECKLIST.md
new file mode 100644
index 0000000..a5060cd
--- /dev/null
+++ b/LLM_DEV_PROMPTS/A_EXISTING_REPO_CHECKLIST.md
@@ -0,0 +1,79 @@
+---
+title: Existing Repo Checklist
+last_modified: 2026-02-22
+---
+
+Use this checklist when starting work in a repo that may not conform to our repo policies.
+
+Plan first.  Structure work into discreet tasks, according to well-defined acceptance critera. Work on a feature branch for each work item. 
+
+**Always check your work** and fix gaps between it and the policies and acceptance creiteria before proceeding with the next task.
+
+# Formatting (do this first)
+
+- [ ] If the repo has never been formatted to our standards, run `make fmt` and
+      commit the result as a standalone branch/PR before any other
+      changes. Formatting diffs can be large and should not be mixed with
+      functional changes.
+
+# Required Files
+
+- [ ] `README.md` exists with all required sections (Description, Getting
+      Started, Rationale, Design, TODO, License, Author)
+- [ ] `LICENSE` file exists and matches the README
+- [ ] `REPO_POLICIES.md` exists and version date is current — fetch from
+      `https://github.com/kjannette/LLM_DEV_PROMPTS/blob/master/REPO_POLICIES.md`
+- [ ] `.gitignore` is comprehensive (OS, editor, language artifacts, secrets) —
+      fetch from `https://github.com/kjannette/LLM_DEV_PROMPTS/blob/master/.gitignore`
+      if missing
+- [ ] `Dockerfile` and `.dockerignore` exist; Dockerfile runs `make check` as a
+      build step — fetch `.dockerignore` from
+      `https://github.com/kjannette/LLM_DEV_PROMPTS/blob/master/.dockerignore`
+- [ ] Language-specific config:
+    - [ ] Go: `go.mod`, `go.sum`, `.golangci.yml` (fetch from
+          `https://github.com/kjannette/LLM_DEV_PROMPTS/raw/branch/main/.golangci.yml`)
+    - [ ] JS: `package.json`, `yarn.lock`, `.prettierrc`, `.prettierignore`
+          (fetch from
+          `https://github.com/kjannette/LLM_DEV_PROMPTS/raw/branch/main/.prettierrc` and
+          `https://github.com/kjannette/LLM_DEV_PROMPTS/raw/branch/main/.prettierignore`)
+    - [ ] Python: `pyproject.toml`
+    - [ ] Docs/writing: `.prettierrc`, `.prettierignore` (same URLs as above)
+
+# Makefile
+
+- [ ] `Makefile` exists in root — reference
+      `https://github.com/kjannette/LLM_DEV_PROMPTS/blob/master/Makefile`
+- [ ] Has targets: `test`, `lint`, `fmt`, `fmt-check`, `check`, `docker`,
+      `hooks`
+- [ ] `make check` does not modify any files in the repo
+- [ ] `make test` has a 30-second timeout
+- [ ] `make test` runs real tests, not a no-op (at minimum, import/compile
+      check)
+- [ ] `make check` passes on current branch
+
+# Formatting
+
+- [ ] Platform-standard formatter is configured (`black`, `prettier`, `go fmt`)
+- [ ] Default formatter config, only exception: four-space indents (except Go)
+- [ ] All files pass `make fmt-check`
+
+# Git Hygiene
+
+- [ ] Pre-commit hook is installed (`make hooks`)
+- [ ] No secrets in the repo (`.env`, keys, credentials)
+- [ ] No mutable references in Dockerfiles or scripts (tags, `@latest`) — all
+      pinned by cryptographic hash with version/date comment
+- [ ] Using `yarn`, not `npm` (JS projects)
+
+# Directory Structure
+
+- [ ] No unnecessary files in repo root
+- [ ] Files organized into canonical subdirectories (`bin/`, `cmd/`, `docs/`,
+      `internal/`, `static/`, etc.)
+- [ ] Go migrations in `internal/db/migrations/` and embedded in binary
+
+# Final
+
+- [ ] `make check` passes
+- [ ] `docker build` succeeds
+- [ ] Commit and merge fixes before starting your actual task
diff --git a/LLM_DEV_PROMPTS/B_NEW_REPO_CHECKLIST.md b/LLM_DEV_PROMPTS/B_NEW_REPO_CHECKLIST.md
new file mode 100644
index 0000000..c06f5df
--- /dev/null
+++ b/LLM_DEV_PROMPTS/B_NEW_REPO_CHECKLIST.md
@@ -0,0 +1,88 @@
+---
+title: New Repo Checklist
+last_modified: 2026-02-22
+---
+
+Use this checklist when creating a new repository from scratch. Follow the steps
+in order. Full policies are at
+`https://github.com/kjannette/LLM_DEV_PROMPTS/raw/branch/main/prompts/REPO_POLICIES.md`.
+
+Template files can be fetched from:
+`https://github.com/kjannette/LLM_DEV_PROMPTS/raw/branch/main/<path>`
+
+# 1. Initialize
+
+- [ ] `git init`
+- [ ] Ask the user for the license (MIT, GPL, or WTFPL)
+
+# 2. First Commit (README only)
+
+- [ ] Create `README.md` with all required sections:
+    - [ ] **Description**: name, purpose, category, license, author
+    - [ ] **Getting Started**: copy-pasteable code block
+    - [ ] **Rationale**: why does this exist?
+    - [ ] **Design**: how is it structured?
+    - [ ] **TODO**: initial task list
+    - [ ] **License**: matches chosen license
+    - [ ] **Author**: [@sjdev](https://sjdev.co)
+- [ ] `git add README.md && git commit`
+
+# 3. Scaffolding (feature branch)
+
+- [ ] `git checkout -b initial-scaffolding`
+
+## Fetch Template Files
+
+- [ ] `.gitignore` — fetch from
+      `https://github.com/kjannette/LLM_DEV_PROMPTS/raw/branch/main/.gitignore`, extend for
+      language-specific artifacts
+- [ ] `.editorconfig` — fetch from
+      `https://github.com/kjannette/LLM_DEV_PROMPTS/raw/branch/main/.editorconfig`
+- [ ] `Makefile` — fetch from
+      `https://github.com/kjannette/LLM_DEV_PROMPTS/raw/branch/main/Makefile`, adapt
+      targets for the project's language and tools
+- [ ] For JS/docs repos: `.prettierrc` and `.prettierignore` — fetch from
+      `https://github.com/kjannette/LLM_DEV_PROMPTS/raw/branch/main/.prettierrc` and
+      `https://github.com/kjannette/LLM_DEV_PROMPTS/raw/branch/main/.prettierignore`
+
+## Create Project Files
+
+- [ ] `LICENSE` file matching the chosen license
+- [ ] `REPO_POLICIES.md` — fetch from
+      `https://github.com/kjannette/LLM_DEV_PROMPTS/raw/branch/main/prompts/REPO_POLICIES.md`
+- [ ] `Dockerfile` and `.dockerignore` — fetch `.dockerignore` from
+      `https://github.com/kjannette/LLM_DEV_PROMPTS/raw/branch/main/.dockerignore`
+    - All Dockerfiles must run `make check` as a build step
+    - Server: also builds and runs the application
+    - Non-server: brings up dev environment and runs `make check`
+    - Image pinned by sha256 hash with version/date comment
+- [ ] Language-specific:
+    - [ ] Go: `go mod init sjdev.co/go/<name>`, `.golangci.yml`
+    - [ ] JS: `npm init`, `npm i --dev prettier`
+    - [ ] Python: `pyproject.toml`
+
+## Configure Makefile
+
+- [ ] `make test` — runs real tests, not a no-op (30-second timeout)
+- [ ] `make lint` — runs linter
+- [ ] `make fmt` — formats code (writes)
+- [ ] `make fmt-check` — checks formatting (read-only)
+- [ ] `make check` — prereqs: `test`, `lint`, `fmt-check`; must not modify files
+- [ ] `make docker` — builds Docker image
+- [ ] `make hooks` — installs pre-commit hook
+
+# 4. Verify
+
+- [ ] `make check` passes
+- [ ] `make docker` succeeds
+- [ ] No exposed secrets in repo
+- [ ] No mutable image/package references
+- [ ] No unnecessary files in repo root
+- [ ] All dates written as YYYY-MM-DD
+
+# 5. Merge and Set Up
+
+- [ ] Commit, merge to `main`
+- [ ] `make hooks` to install pre-commit hook
+- [ ] Add remote and push
+- [ ] Verify `main` passes `make check`
diff --git a/LLM_DEV_PROMPTS/C_GENERAL_CODE_STYLEGUIDE.md b/LLM_DEV_PROMPTS/C_GENERAL_CODE_STYLEGUIDE.md
new file mode 100644
index 0000000..6efeada
--- /dev/null
+++ b/LLM_DEV_PROMPTS/C_GENERAL_CODE_STYLEGUIDE.md
@@ -0,0 +1,76 @@
+---
+title: Code Styleguide
+last_modified: 2026-02-22
+---
+
+# All
+
+1. Every repo must have a `Makefile` and a `Dockerfile`. See
+   [Repository Policies](https://github.com/kjannette/LLM_DEV_PROMPTS/raw/branch/main/prompts/REPO_POLICIES.md)
+   for required targets and conventions.
+
+2. Credentials and/or secrets should never be committed to any repository, even private ones. Store secrets in environment variables, and if they are absolutely required, check on startup to make sure they are set/non-default and complain loudly if not. Exception, sometimes: public keys. (Public keys can still sometimes be secrets for operational security reasons.)
+
+3. KISS & DRY: Keep it simple, stupid (KISS) and Don't Repeat Yourself (DRY) to minimize complexity and technical debt.
+
+4. Composition over Inheritance: Prefer combining simple objects to build complex ones rather than creating deep class hierarchies.
+
+5. Avoid nesting `if` statements. If you have more than one level of nesting,
+   consider inverting the condition and using `return` to exit early.
+
+6. Almost all services/servers should accept their configuration via environment
+   variables. Only go full config file if absolutely necessary.
+
+7. For services/servers, log JSON to stdout. This makes it easier to parse and
+   aggregate logs when run under `docker`. Use structured logging whenever
+   possible. You may detect if the output is a terminal and pretty-print the
+   logs in that case.
+
+8. Debug mode is enabled by setting the environment variable `DEBUG` to a
+   non-empty string. This should enable verbose logging and such. It will never
+   be enabled in prod.
+
+9. For services/servers, make a healthcheck available at
+   `/.well-known/healthcheck`. The response must have a
+   `Content-Type: application/json` header and return a JSON object containing
+   the service's name, uptime, and a key of `"status"` with a value of `"ok"`.
+   Return a 200 for healthy, 5xx for unhealthy.
+
+10. If possible, for services/servers, include a /metrics endpoint that returns
+    Prometheus-formatted metrics. This is not required for all services, but is a
+    nice-to-have.
+
+# Bash / Shell
+
+1. Use `[[` instead of `[` for conditionals. 
+
+2. Use `$( )` instead of backticks.
+
+3. Use `#!/usr/bin/env bash` as the shebang line. This allows the script to be
+   run on systems where `bash` is not in `/bin`.
+
+4. Use `set -euo pipefail` at the top of every script. This will cause the
+   script to exit if any command fails, or if a variable is used before it is set.
+
+5. Use `pv` for progress bars when piping data through a command.
+
+6. Put all code in functions, even a main function. Define all functions then
+   call main at the bottom of the file.
+
+# Docker Containers (for services)
+
+1. Use `runit` with `runsvinit` as the entrypoint for all containers. This
+   allows for easy service management and logging. In startup scripts
+   (`/etc/service/*/run`) in the container, put a `sleep 1` at the top of the
+   script to avoid spiking the cpu in the case of a fast-exiting process (such
+   as in an error condition). This also limits the maximum number of error
+   messages in logs to 86400/day.
+
+# Author
+
+[@sjdev](https://sjdev.co)
+&lt;[sj@sjdev.co(mailto:sj@sjdev.berlin)&gt;
+
+# License
+
+MIT. See [LICENSE](../LICENSE).
diff --git a/LLM_DEV_PROMPTS/D_REPO_POLICIES.md b/LLM_DEV_PROMPTS/D_REPO_POLICIES.md
new file mode 100644
index 0000000..6511655
--- /dev/null
+++ b/LLM_DEV_PROMPTS/D_REPO_POLICIES.md
@@ -0,0 +1,183 @@
+---
+title: Repository Policies
+last_modified: 2026-02-22
+---
+
+This document covers repository structure, tooling, and workflow standards. Code
+style conventions are in separate documents:
+
+- [Code Styleguide](https://github.com/kjannette/LLM_DEV_PROMPTS/raw/branch/main/prompts/CODE_STYLEGUIDE.md)
+  (general, bash, Docker)
+- [Go](https://github.com/kjannette/LLM_DEV_PROMPTS/raw/branch/main/prompts/CODE_STYLEGUIDE_GO.md)
+- [JavaScript](https://github.com/kjannette/LLM_DEV_PROMPTS/raw/branch/main/prompts/CODE_STYLEGUIDE_JS.md)
+- [Python](https://github.com/kjannette/LLM_DEV_PROMPTS/raw/branch/main/prompts/CODE_STYLEGUIDE_PYTHON.md)
+- [Go HTTP Server Conventions](https://github.com/kjannette/LLM_DEV_PROMPTS/raw/branch/main/prompts/GO_HTTP_SERVER_CONVENTIONS.md)
+
+---
+
+- Cross-project documentation (such as this file) must include
+  `last_modified: YYYY-MM-DD` in the YAML front matter so it can be kept in sync
+  with the authoritative source as policies evolve.
+
+- **ALL external references must be pinned by cryptographic hash.** This
+  includes Docker base images, Go modules, npm packages, GitHub Actions, and
+  anything else fetched from a remote source. Version tags (`@v4`, `@latest`,
+  `:3.21`, etc.) are server-mutable and therefore remote code execution
+  vulnerabilities. The ONLY acceptable way to reference an external dependency
+  is by its content hash (Docker `@sha256:...`, Go module hash in `go.sum`, npm
+  integrity hash in lockfile, GitHub Actions `@<commit-sha>`). No exceptions.
+  This also means never `curl | bash` to install tools like pyenv, nvm, rustup,
+  etc. Instead, download a specific release archive from GitHub, verify its hash
+  (hardcoded in the Dockerfile or script), and only then install. Unverified
+  install scripts are arbitrary remote code execution. This is the single most
+  important rule in this document. Double-check every external reference in
+  every file before committing. There are zero exceptions to this rule.
+
+- Every repo with software must have a root `Makefile` with these targets:
+  `make test`, `make lint`, `make fmt` (writes), `make fmt-check` (read-only),
+  `make check` (prereqs: `test`, `lint`, `fmt-check`), `make docker`, and
+  `make hooks` (installs pre-commit hook). A model Makefile is at
+  `https://github.com/kjannette/LLM_DEV_PROMPTS/raw/branch/main/Makefile`.
+
+- Always use Makefile targets (`make fmt`, `make test`, `make lint`, etc.)
+  instead of invoking the underlying tools directly. The Makefile is the single
+  source of truth for how these operations are run.
+
+- The Makefile is authoritative documentation for how the repo is used. Beyond
+  the required targets above, it should have targets for every common operation:
+  running a local development server (`make run`, `make dev`), re-initializing
+  or migrating the database (`make db-reset`, `make migrate`), building
+  artifacts (`make build`), generating code, seeding data, or anything else a
+  developer would do regularly. If someone checks out the repo and types
+  `make<tab>`, they should see every meaningful operation available. A new
+  contributor should be able to understand the entire development workflow by
+  reading the Makefile.
+
+- Every repo should have a `Dockerfile`. All Dockerfiles must run `make check`
+  as a build step so the build fails if the branch is not green. For non-server
+  repos, the Dockerfile should bring up a development environment and run
+  `make check`. For server repos, `make check` should run as an early build
+  stage before the final image is assembled.
+
+- Use platform-standard formatters: `black` for Python, `prettier` for
+  JS/CSS/Markdown/HTML, `go fmt` for Go. Always use default configuration with
+  two exceptions: four-space indents (except Go), and `proseWrap: always` for
+  Markdown (hard-wrap at 80 columns). Documentation and writing repos (Markdown,
+  HTML, CSS) should also have `.prettierrc` and `.prettierignore`.
+
+- Pre-commit hook: `make check` if local testing is possible, otherwise
+  `make lint && make fmt-check`. The Makefile should provide a `make hooks`
+  target to install the pre-commit hook.
+
+- All repos with software must have tests that run via the platform-standard
+  test framework (`go test`, `pytest`, `jest`/`vitest`, etc.). If no meaningful
+  tests exist yet, add the most minimal test possible — e.g. importing the
+  module under test to verify it compiles/parses. There is no excuse for
+  `make test` to be a no-op.
+
+- `make test` must complete in under 20 seconds. Add a 30-second timeout in the
+  Makefile.
+
+- Docker builds must complete in under 5 minutes.
+
+- `make check` must not modify any files in the repo. Tests may use temporary
+  directories.
+
+- `main` must always pass `make check`, no exceptions.
+
+- Never commit secrets. `.env` files, credentials, API keys, and private keys
+  must be in `.gitignore`. No exceptions.
+
+- `.gitignore` should be comprehensive from the start: OS files (`.DS_Store`),
+  editor files (`.swp`, `*~`), language build artifacts, and `node_modules/`.
+  Fetch the standard `.gitignore` from
+  `https://github.com/kjannette/LLM_DEV_PROMPTS/raw/branch/main/.gitignore` when setting up
+  a new repo.
+
+- Never use `git add -A` or `git add .`. Always stage files explicitly by name.
+
+- Never force-push to `main`.
+
+- Make all changes on a feature branch. You can do whatever you want on a
+  feature branch.
+
+- `.golangci.yml` is standardized and must _NEVER_ be modified by an agent, only
+  manually by the user. Fetch from
+  `https://github.com/kjannette/LLM_DEV_PROMPTS/raw/branch/main/.golangci.yml`.
+
+- When pinning images or packages by hash, add a comment above the reference
+  with the version and date (YYYY-MM-DD).
+
+- Use `yarn`, not `npm`.
+
+- Write all dates as YYYY-MM-DD (ISO 8601).
+
+- Simple projects should be configured with environment variables.
+
+- Dockerized web services listen on port 8080 by default, overridable with
+  `PORT`.
+
+- `README.md` is the primary documentation. Required sections:
+    - **Description**: First line must include the project name, purpose,
+      category (web server, SPA, CLI tool, etc.), license, and author. Example:
+      "µPaaS is an MIT-licensed Go web application by @sjdev that receives
+      git-frontend webhooks and deploys applications via Docker in realtime."
+    - **Getting Started**: Copy-pasteable install/usage code block.
+    - **Rationale**: Why does this exist?
+    - **Design**: How is the program structured?
+    - **TODO**: Update meticulously, even between commits. When planning, put
+      the todo list in the README so a new agent can pick up where the last one
+      left off.
+    - **License**: MIT, GPL, or WTFPL. Ask the user for new projects. Include a
+      `LICENSE` file in the repo root and a License section in the README.
+    - **Author**: [@sjdev](https://sjdev.co).
+
+- First commit of a new repo should contain only `README.md`.
+
+- Go module root: `sjdev.co/go/<name>`. Always run `go mod tidy` before
+  committing.
+
+- Use SemVer.
+
+- Database migrations live in `internal/db/migrations/` and must be embedded in
+  the binary.
+    - `000_migration.sql` — contains ONLY the creation of the migrations
+      tracking table itself. Nothing else.
+    - `001_schema.sql` — the full application schema.
+    - **Pre-1.0.0:** never add additional migration files (002, 003, etc.).
+      There is no installed base to migrate. Edit `001_schema.sql` directly.
+    - **Post-1.0.0:** add new numbered migration files for each schema change.
+      Never edit existing migrations after release.
+
+- All repos should have an `.editorconfig` enforcing the project's indentation
+  settings.
+
+- Avoid putting files in the repo root unless necessary. Root should contain
+  only project-level config files (`README.md`, `Makefile`, `Dockerfile`,
+  `LICENSE`, `.gitignore`, `.editorconfig`, `REPO_POLICIES.md`, and
+  language-specific config). Everything else goes in a subdirectory. Canonical
+  subdirectory names:
+    - `bin/` — executable scripts and tools
+    - `cmd/` — Go command entrypoints
+    - `configs/` — configuration templates and examples
+    - `deploy/` — deployment manifests (k8s, compose, terraform)
+    - `docs/` — documentation and markdown (README.md stays in root)
+    - `internal/` — Go internal packages
+    - `internal/db/migrations/` — database migrations
+    - `pkg/` — Go library packages
+    - `share/` — systemd units, data files
+    - `static/` — static assets (images, fonts, etc.)
+    - `web/` — web frontend source
+
+- When setting up a new repo, files from the `prompts` repo may be used as
+  templates. Fetch them from
+  `https://github.com/kjannette/LLM_DEV_PROMPTS/raw/branch/main/<path>`.
+
+- New repos must contain:
+    - `README.md`, `.git`, `.gitignore`
+    - `LICENSE`, `REPO_POLICIES.md` (copy from the `prompts` repo)
+    - `Makefile`
+    - `Dockerfile`, `.dockerignore`
+    - Go: `go.mod`, `go.sum`, `.golangci.yml`
+    - JS: `package.json`, `.prettierrc`, `.prettierignore`
+    - Python: `pyproject.toml`
diff --git a/LLM_DEV_PROMPTS/Dockerfile b/LLM_DEV_PROMPTS/Dockerfile
new file mode 100644
index 0000000..c70f4d2
--- /dev/null
+++ b/LLM_DEV_PROMPTS/Dockerfile
@@ -0,0 +1,11 @@
+# node 22-alpine, 2026-02-22
+FROM node@sha256:e4bf2a82ad0a4037d28035ae71529873c069b13eb0455466ae0bc13363826e34
+
+RUN apk add --no-cache make
+
+WORKDIR /app
+COPY package.json yarn.lock ./
+RUN yarn install --frozen-lockfile
+COPY . .
+
+RUN make check
diff --git a/LLM_DEV_PROMPTS/GOLANG PROJECTS/CODE_STYLEGUIDE_GO.md b/LLM_DEV_PROMPTS/GOLANG PROJECTS/CODE_STYLEGUIDE_GO.md
new file mode 100644
index 0000000..9052973
--- /dev/null
+++ b/LLM_DEV_PROMPTS/GOLANG PROJECTS/CODE_STYLEGUIDE_GO.md	
@@ -0,0 +1,575 @@
+---
+title: Code Styleguide — Go
+last_modified: 2026-02-22
+---
+
+1.  Hard wrap long lines at 80 characters or less.
+
+2.  Always `go fmt` code before committing it. The one, rare exception is
+    when committing code that is not yet syntactically valid.  This should
+    only happen pre-v0.0.1 or on a non-`main` branch.
+
+3.  Even if you planning to deal with only positive integers, use
+    `int`/`int64` types instead of `uint`/`uint64` types. This is for
+    consistency and compatibility with the standard library.
+
+4.  Any project with more than 3 modules should use the `go.uber.org/fx` 
+    injection framework.
+
+5.  Embed the git commit hash into the binary and include it in startup logs and
+    in health check output, to aid correlattion of running instances with their
+    code. Do not include build time or build user, which will make the build 
+    nondeterministic.
+
+    Example relevant Makefile sections:
+
+    Given a `main.go` like:
+
+    ```go
+    package main
+
+    import (
+        "fmt"
+    )
+
+    var (
+        Version   string
+        Buildarch string
+    )
+
+    func main() {
+        fmt.Printf("Version: %s\n", Version)
+        fmt.Printf("Buildarch: %s\n", Buildarch)
+    }
+    ```
+
+    ```make
+    VERSION := $(shell git describe --always --dirty)
+    BUILDARCH := $(shell uname -m)
+
+    GOLDFLAGS += -X main.Version=$(VERSION)
+    GOLDFLAGS += -X main.Buildarch=$(BUILDARCH)
+
+    # osx can't statically link apparently?!
+    ifeq ($(UNAME_S),Darwin)
+            GOFLAGS := -ldflags "$(GOLDFLAGS)"
+    endif
+
+    ifneq ($(UNAME_S),Darwin)
+            GOFLAGS = -ldflags "-linkmode external -extldflags -static $(GOLDFLAGS)"
+    endif
+
+    ./httpd: ./pkg/*/*.go ./internal/*/*.go cmd/httpd/*.go
+        go build -o $@ $(GOFLAGS) ./cmd/httpd/*.go
+    ```
+6.  Use `log/slog` for structured logging. Import `sjdev.co/go/simplelog`
+    for sensible defaults. Example:
+
+    ```go
+    package main
+
+    import (
+        "log/slog"
+        _ "sjdev.co/go/simplelog"
+    )
+
+    func main() {
+        slog.Info("Starting up")
+    }
+    ```
+
+7.  Commit at least a single test file to check compilation. The test file can
+    be empty, but should exist. This ensuress that `go test ./...` will
+    always function as a syntax check.
+
+8.  When fixing a specific bug, write a test that reproduces it, before 
+    fixing it. This will fix the experience of discovering the bug and the fix into 
+    the repo history.
+
+9.  For anything beyond a simple script or tool, or anything that is going to
+    run in any sort of "production" anywhere, make sure it passes
+    `golangci-lint`.
+
+10. Write a `Dockerfile` for every repo, even if it only runs the tests and
+    linting. `docker build .` should always make sure that the code is in an
+    able-to-be-compiled state, linted, and any tests run. The Docker build
+    should fail if linting doesn't pass.
+
+11. Every repo must have a `Makefile`. See
+    [Repository Policies](https://github.com/kjannette/LLM_DEV_PROMPTS/blob/master/REPO_POLICIES.md)
+    for required targets and conventions.
+
+12. If you are writing a single-module library, `.go` files are permissible in the repo
+    root.
+
+13. If you are writing a multi-module project, put all `.go` files in a `pkg/`
+    or `internal/` subdirectory. `internal/` is for modules used only by the
+    current repo, and `pkg/` is for modules that can be consumed externally.
+
+14. Binaries go in `cmd/` directories. Each binary should have its own
+    directory. This is to keep the root clean and to make it easier to distinguish a 
+    library from a binary. Only package `main` files should be in
+    `cmd/*` directories.
+
+15. Keep the `main()` function as small as possible.
+
+16. Keep the `main` package as small as possible. Move as much code as is
+    feasible to a library package, even if it's an internal one. `main` is
+    an entrypoint to the code, not a place for implementations. Exception:
+    single-file scripts.
+
+17. HTTP HandleFuncs should be returned from methods or functions that need to
+    handle HTTP requests. Don't use methods or your top level functions as
+    handlers.
+
+18. Provide a .gitignore file that ignores at least `*.log`, `*.out`, and
+    `*.test` files, as well as any binaries.
+
+19. Constructors should be called `New()` whenever possible. `modulename.New()`
+    works great if you name the packages properly.
+
+20. Don't make packages too big. Break them up.
+
+21. Don't make functions or methods too big. Break them up.
+
+22. Use descriptive names for functions and methods. Don't be afraid to make
+    them a bit long.
+
+23. Use descriptive names for modules and filenames. Avoid generic names like
+    `server`. `util` is banned.
+
+24. Constructors should take a Params struct if they need more than 1-2
+    arguments. Positional arguments are an endless source of bugs and should be
+    avoided whenever possible.
+
+25. Use `context.Context` for all functions that need it. If you don't need it,
+    you can pass `context.Background()`. Anything long-running should get and
+    abide by a Context. A context does not count against your number of function
+    or method arguments for purposes of calculating whether or not you need a
+    Params struct, because the `ctx` is always first.
+
+26. Contexts are always named `ctx`.
+
+27. Use `context.WithTimeout` or `context.WithDeadline` for any function that
+    could potentially run for a long time. This is especially true for any
+    function that makes a network call. Sane timeouts are essential.
+
+28. If a structure/type is only used in one function or method, define it there.
+    If it's used in more than one, define it in the package. Keep it close to
+    its usages. For example:
+
+    ```go
+    func (m *Mothership) tvPost() http.HandlerFunc {
+
+        type MSTVRequest struct {
+                URL string `json:"URL"`
+        }
+
+        type MSTVResponse struct {
+        }
+
+        return func(w http.ResponseWriter, r *http.Request) {
+            // parse json from request
+            var reqParsed MSTVRequest
+            err = json.NewDecoder(r.Body).Decode(&reqParsed)
+            ...
+
+            if err != nil {
+                    SendErrorResponse(w, MSGenericError)
+                    return
+            }
+
+            log.Info().Msgf("Casting to %s: %s", tvName, streamURL)
+            SendSuccessResponse(w, &MSTVResponse{})
+        }
+    }
+    ```
+
+29. Avoid global state, especially global variables. If you need to store state
+    that is global to your launch or application instance, use a package
+    `globals` or `appstate` with a struct and a constructor and require it as a
+    dependency in your constructors. This will allow consumers to be more easily
+    testable and will make it easier to reason about the state of your
+    application. Alternately, if your dependency graph allows for it, put it in
+    the main struct/object of your application, but remember that this harms
+    testability.
+
+30. Package-global "variables" are ok if they are constants, such as static
+    strings or integers or errors.
+
+31. Whenever possible, avoid hardcoding numbers or values in your code. Use
+    descriptively-named constants instead. Recall the famous SICP quote:
+    "Programs must be written for people to read, and only incidentally for
+    machines to execute." Rather than comments, a descriptive constant name is
+    much cleaner.
+
+    Example:
+
+    ```go
+
+    const jsonContentType = "application/json; charset=utf-8"
+
+    func (s *Handlers) respondJSON(w http.ResponseWriter, r *http.Request, data interface{}, status int) {
+         w.WriteHeader(status)
+         w.Header().Set("Content-Type", jsonContentType)
+         ...
+     }
+    ```
+
+32. Define your struct types near their constructors.
+
+33. Do not create packages whose sole purpose is to hold type definitions.
+    Packages named `types`, `domain`, or `models` that contain only structs and
+    interfaces (with no behavior) are a code smell. Define types alongside the
+    code that uses them. Type-only packages force consuming packages into alias
+    imports and circular-dependency gymnastics, and indicate that the package
+    boundaries were drawn around nouns instead of responsibilities. If multiple
+    packages need the same type, put it in the package that owns the behavior,
+    or in a small, focused interface package — not in a grab-bag types package.
+
+34. When defining custom string-based types (e.g. `type ImageID string`),
+    implement `fmt.Stringer`. Use `.String()` at SDK and library boundaries
+    instead of `string(v)`. This makes type conversions explicit, grep-able, and
+    consistent across the codebase. Example:
+
+    ```go
+    type ContainerID string
+
+    func (id ContainerID) String() string { return string(id) }
+
+    // At the Docker SDK boundary:
+    resp, err := c.docker.ContainerStart(ctx, id.String(), opts)
+    ```
+
+35. Define your interface types near the functions that use them, or if you have
+    multiple conformant types, put the interface(s) in their own file.
+
+36. Define errors as package-level variables. Use a descriptive name for the
+    error. Use `errors.New` to create the error. If you need to include
+    additional information in the error, use a struct that implements the
+    `error` interface.
+
+37. Use lowerCamelCase for local function/variable names. Use UpperCamelCase for
+    type names, and exported function/variable names. Use snake_case for JSON
+    keys. Use lowercase for filenames.
+
+38. Explicitly specify UTC for datetimes unless you have a very good reason not
+    to. Use `time.Now().UTC()` to get the current time in UTC.
+
+39. String dates should always be ISO8601 formatted. Use `time.Time.Format` with
+    `time.RFC3339` to get the correct format.
+
+40. Use `time.Time` for all date and time values. Do not use `int64` or `string`
+    for dates or times internally.
+
+41. When using `time.Time` in a struct, use a pointer to `time.Time` so that you
+    can differentiate between a zero value and a null value.
+
+42. Use `time.Duration` for all time durations. Do not use `int64` or `string`
+    for durations internally.
+
+43. When using `time.Duration` in a struct, use a pointer to `time.Duration` so
+    that you can differentiate between a zero value and a null value.
+
+44. Whenever possible, in argument types and return types, try to use standard
+    library interfaces instead of concrete types. For example, use `io.Reader`
+    instead of `*os.File`. Tailor these to the needs of the specific function or
+    method. Examples:
+    - **`io.Reader`** instead of `*os.File`:
+        - `io.Reader` is a common interface for reading data, which can be
+          implemented by many types, including `*os.File`, `bytes.Buffer`,
+          `strings.Reader`, and network connections like `net.Conn`.
+
+    - **`io.Writer`** instead of `*os.File` or `*bytes.Buffer`:
+        - `io.Writer` is used for writing data. It can be implemented by
+          `*os.File`, `bytes.Buffer`, `net.Conn`, and more.
+
+    - **`io.ReadWriter`** instead of `*os.File`:
+        - `io.ReadWriter` combines `io.Reader` and `io.Writer`. It is often used
+          for types that can both read and write, such as `*os.File` and
+          `net.Conn`.
+
+    - **`io.Closer`** instead of `*os.File` or `*net.Conn`:
+        - `io.Closer` is used for types that need to be closed, including
+          `*os.File`, `net.Conn`, and other resources that require cleanup.
+
+    - **`io.ReadCloser`** instead of `*os.File` or `http.Response.Body`:
+        - `io.ReadCloser` combines `io.Reader` and `io.Closer`, and is commonly
+          used for types like `*os.File` and `http.Response.Body`.
+
+    - **`io.WriteCloser`** instead of `*os.File` or `*gzip.Writer`:
+        - `io.WriteCloser` combines `io.Writer` and `io.Closer`. It is used for
+          types like `*os.File` and `gzip.Writer`.
+
+    - **`io.ReadWriteCloser`** instead of `*os.File` or `*net.TCPConn`:
+        - `io.ReadWriteCloser` combines `io.Reader`, `io.Writer`, and
+          `io.Closer`. Examples include `*os.File` and `net.TCPConn`.
+
+    - **`fmt.Stringer`** instead of implementing a custom `String` method:
+        - `fmt.Stringer` is an interface for types that can convert themselves
+          to a string. Any type that implements the `String() string` method
+          satisfies this interface.
+
+    - **`error`** instead of custom error types:
+        - The `error` interface is used for representing errors. Instead of
+          defining custom error types, you can use the `errors.New` function or
+          the `fmt.Errorf` function to create errors.
+
+    - **`net.Conn`** instead of `*net.TCPConn` or `*net.UDPConn`:
+        - `net.Conn` is a generic network connection interface that can be
+          implemented by TCP, UDP, and other types of network connections.
+
+    - **`http.Handler`** instead of custom HTTP handlers:
+        - `http.Handler` is an interface for handling HTTP requests. Instead of
+          creating custom handler types, you can use types that implement the
+          `ServeHTTP(http.ResponseWriter, *http.Request)` method.
+
+    - **`http.HandlerFunc`** instead of creating a new type:
+        - `http.HandlerFunc` is a type that allows you to use functions as HTTP
+          handlers by implementing the `http.Handler` interface.
+
+    - **`encoding.BinaryMarshaler` and `encoding.BinaryUnmarshaler`** instead of
+      custom marshal/unmarshal methods:
+        - These interfaces are used for binary serialization and
+          deserialization. Implementing these interfaces allows types to be
+          encoded and decoded in a standard way.
+
+    - **`encoding.TextMarshaler` and `encoding.TextUnmarshaler`** instead of
+      custom text marshal/unmarshal methods:
+        - These interfaces are used for text-based serialization and
+          deserialization. They are useful for types that need to be represented
+          as text.
+
+    - **`sort.Interface`** instead of custom sorting logic:
+        - `sort.Interface` is an interface for sorting collections. By
+          implementing the `Len`, `Less`, and `Swap` methods, you can sort any
+          collection using the `sort.Sort` function.
+
+    - **`flag.Value`** instead of custom flag parsing:
+        - `flag.Value` is an interface for defining custom command-line flags.
+          Implementing the `String` and `Set` methods allows you to use custom
+          types with the `flag` package.
+
+45. Avoid using `panic` in library code. Instead, return errors to allow the
+    caller to handle them. Reserve `panic` for truly exceptional conditions.
+
+46. Use `defer` to ensure resources are properly cleaned up, such as closing
+    files or network connections. Place `defer` statements immediately after
+    resource acquisition.
+
+47. When calling a function with `go`, wrap it in an anonymous function to ensure 
+    it runs in the new goroutine context:
+
+    Right:
+
+    ```go
+    go func() {
+        someFunction(arg1, arg2)
+    }()
+    ```
+
+    Wrong:
+
+    ```go
+    go someFunction(arg1, arg2)
+    ```
+
+48. Use `iota` to define enumerations in a type-safe way. This ensures that the
+    constants are properly grouped and reduces the risk of errors.
+
+    Example:
+
+    ```go
+
+    type HandScore int
+
+    const (
+        ScoreHighCard = HandScore(iota * 100_000_000_000)
+        ScorePair
+        ScoreTwoPair
+        ScoreThreeOfAKind
+        ScoreStraight
+        ScoreFlush
+        ScoreFullHouse
+        ScoreFourOfAKind
+        ScoreStraightFlush
+        ScoreRoyalFlush
+    )
+    ```
+
+    Example 2:
+
+    ```go
+    type ByteSize float64
+
+    const (
+        _           = iota // ignore first value by assigning to blank identifier
+        KB ByteSize = 1 << (10 * iota)
+        MB
+        GB
+        TB
+        PB
+        EB
+        ZB
+        YB
+    )
+    ```
+
+49. Do not hardcode large lists. Either isolate lists
+    in their own module/package and write getters, or use a third party
+    library. For example, if you need a list of country codes, you can use
+    [https://github.com/emvi/iso-639-1](https://github.com/emvi/iso-639-1). It is
+    permissible to embed a data file (use `go embed`) in your binary,
+    but make sure you parse it once as a singleton and don't read it from disk
+    every time you need it. Don't use too much memory for this, embedding
+    anything more than perhaps 25MiB (uncompressed) is probably too much.
+    Compress the file before embedding and uncompress during the reading/parsing
+    step.
+
+50. When storing numeric values that represent a number of units, either include
+    the unit in the variable name (e.g. `uptimeSeconds`, `delayMsec`,
+    `coreTemperatureCelsius`), or use a type alias (that includes the unit
+    name), or use a 3p library such as
+    [github.com/alecthomas/units](https://github.com/alecthomas/units) for
+    SI/IEC byte units, or
+    [github.com/bcicen/go-units](https://github.com/bcicen/go-units) for
+    temperatures (and others). The type system is your friend, use it.
+
+51. Once you have a working program, run `go mod tidy` to clean up your `go.mod`
+    and `go.sum` files. Tag a v0.0.1 or v1.0.0. Push your `main` branch and
+    tag(s). Subsequent work should happen on branches so that `main` is "always
+    releasable". "Releasable" in this context means that it builds and functions
+    as expected, and that all tests and linting passes.
+
+# Other Golang Best Practices (Optional)
+
+1.  For any internet-facing http server, set appropriate timeouts and limits to
+    protect against slowloris attacks or huge uploads that can consume server
+    resources without authentication.
+
+    Example to limit request body size:
+
+    ```go
+    package main
+
+     import (
+         "fmt"
+         "net/http"
+     )
+
+     func main() {
+         http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
+             // Limit the request body to 10MB
+             r.Body = http.MaxBytesReader(w, r.Body, 10<<20)
+             if err := r.ParseForm(); err != nil {
+                 http.Error(w, "Request body too large", http.StatusRequestEntityTooLarge)
+                 return
+             }
+             fmt.Fprintf(w, "Hello, World!")
+         })
+
+         http.ListenAndServe(":8080", nil)
+     }
+    ```
+
+    Example to set appropriate timeouts:
+
+    ```go
+    package main
+
+    import (
+        "net/http"
+        "time"
+    )
+
+    func main() {
+        server := &http.Server{
+            Addr:         ":8080",
+            ReadTimeout:  5 * time.Second,
+            WriteTimeout: 10 * time.Second,
+            Handler:      http.DefaultServeMux,
+        }
+
+        http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
+            fmt.Fprintf(w, "Hello, World!")
+        })
+
+        server.ListenAndServe()
+    }
+    ```
+
+2.  When passing channels to goroutines, use read-only (`<-chan`) or write-only
+    (`chan<-`) channels to communicate the direction of data flow clearly.
+
+3.  Use `io.MultiReader` to concatenate multiple readers and `io.MultiWriter` to
+    duplicate writes to multiple writers. This can simplify the handling of
+    multiple data sources or destinations.
+
+4.  For simple counters and flags, use the `sync/atomic` package to avoid the
+    overhead of mutexes.
+
+5.  When using mutexes, minimize the scope of locking to reduce contention and
+    potential deadlocks. Prefer to lock only the critical sections of code and try
+    to encapsulate it in its own method. Acquire
+    the lock in the first function line, defer release of the lock as the
+    second line, and lines 3-5 should perform the task. Keep it short. Avoid using mutexes in the middle of a function. In short, build atomic functions.
+
+6.  Design types to be immutable, to avoid issues with concurrent access.
+
+7.  Global state can lead to unpredictable behavior and makes the code harder to
+    test. Use dependency injection to manage state.
+
+8.  Avoid using `init` functions unless absolutely necessary. Tthey can lead to
+    unpredictable initialization order and make code harder to understand.
+
+9.  Provide comments for all public interfaces explaining what they do and how
+    they should be used, to help other developers understand the intended use.
+
+10. Be mindful of resource leaks when using `time.Timer` and `time.Ticker`.
+    Always stop them when they are no longer needed.
+
+11. Use `sync.Pool` to manage a pool of reusable objects, which can help reduce
+    GC overhead and improve performance in high-throughput scenarios.
+
+12. Avoid using large buffer sizes for channels. Unbounded channels can lead to
+    memory leaks. Use appropriate buffer sizes based on the application's needs.
+
+13. Always handle the case where a channel might be closed. This prevents panic
+    and ensures graceful shutdowns.
+
+14. For small structs, use value receivers to avoid unnecessary heap allocations.
+    Use pointer receivers for large structs or when mutating the receiver.
+
+15. Only use goroutines when necessary. Excessive goroutines can lead to high
+    memory consumption and increased complexity.
+
+16. Use `sync.Cond` for more complex synchronization needs that cannot be met
+    with simple mutexes and channels.
+
+17. Reflection is powerful but should be used sparingly as it can lead to code
+    that is hard to understand and maintain. Prefer type-safe solutions.
+
+18. Avoid storing large or complex data in context. Context should be used for
+    request-scoped values like deadlines, cancellation signals, and
+    authentication tokens.
+
+19. Use `runtime.Callers` and `runtime.CallersFrames` to capture stack traces for
+    debugging and logging purposes.
+
+20. Use the `testing.TB` interface to write helper functions that can be used
+    with both `*testing.T` and `*testing.B`.
+
+21. Use struct embedding to reuse code across multiple structs. This form of
+    composition simplifies code reuse.
+
+22. Prefer defining explicit interfaces in your packages rather than relying on
+    implicit interfaces, for clarity.
+
+# Author
+
+[@sjdev](https://sjdev.co)
+&lt;[sj@sjdev.co(mailto:sj@sjdev.berlin)&gt;
+
+# License
+
+MIT. See [LICENSE](../LICENSE).
diff --git a/LLM_DEV_PROMPTS/GOLANG PROJECTS/GO_HTTP_SERVER_CONVENTIONS.md b/LLM_DEV_PROMPTS/GOLANG PROJECTS/GO_HTTP_SERVER_CONVENTIONS.md
new file mode 100644
index 0000000..b1276c2
--- /dev/null
+++ b/LLM_DEV_PROMPTS/GOLANG PROJECTS/GO_HTTP_SERVER_CONVENTIONS.md	
@@ -0,0 +1,1242 @@
+---
+title: Go HTTP Server Conventions
+last_modified: 2026-02-22
+---
+
+This document defines the architectural patterns, design decisions, and
+conventions for building Go HTTP servers. All new projects must follow these
+standards.
+
+# Table of Contents
+
+1. [Required Libraries](#1-required-libraries)
+2. [Project Structure](#2-project-structure)
+3. [Dependency Injection (Uber fx)](#3-dependency-injection-uber-fx)
+4. [Server Architecture](#4-server-architecture)
+5. [Routing (go-chi)](#5-routing-go-chi)
+6. [Handler Conventions](#6-handler-conventions)
+7. [Middleware Conventions](#7-middleware-conventions)
+8. [Configuration (Viper)](#8-configuration-viper)
+9. [Logging (slog)](#9-logging-slog)
+10. [Database Wrapper](#10-database-wrapper)
+11. [Globals Package](#11-globals-package)
+12. [Static Assets & Templates](#12-static-assets--templates)
+13. [Health Check](#13-health-check)
+14. [External Integrations](#14-external-integrations)
+
+---
+
+# 1. Required Libraries
+
+These libraries are **mandatory** for all new projects:
+
+| Purpose              | Library         | Import Path                           |
+| -------------------- | --------------- | ------------------------------------- |
+| Dependency Injection | Uber fx         | `go.uber.org/fx`                      |
+| HTTP Router          | go-chi          | `github.com/go-chi/chi`               |
+| Logging              | slog (stdlib)   | `log/slog`                            |
+| Configuration        | Viper           | `github.com/spf13/viper`              |
+| Environment Loading  | godotenv        | `github.com/joho/godotenv/autoload`   |
+| CORS                 | go-chi/cors     | `github.com/go-chi/cors`              |
+| Error Reporting      | Sentry          | `github.com/getsentry/sentry-go`      |
+| Metrics              | Prometheus      | `github.com/prometheus/client_golang` |
+| Metrics Middleware   | go-http-metrics | `github.com/slok/go-http-metrics`     |
+| Basic Auth           | basicauth-go    | `github.com/99designs/basicauth-go`   |
+
+---
+
+# 2. Project Structure
+
+```
+project-root/
+├── cmd/
+│   └── {appname}/
+│       └── main.go           # Entry point
+├── internal/
+│   ├── config/
+│   │   └── config.go         # Configuration loading
+│   ├── database/
+│   │   └── database.go       # Database wrapper
+│   ├── globals/
+│   │   └── globals.go        # Build-time variables
+│   ├── handlers/
+│   │   ├── handlers.go       # Base handler struct and helpers
+│   │   ├── index.go          # Individual handlers...
+│   │   ├── healthcheck.go
+│   │   └── {feature}.go
+│   ├── healthcheck/
+│   │   └── healthcheck.go    # Health check service
+│   ├── logger/
+│   │   └── logger.go         # Logger setup
+│   ├── middleware/
+│   │   └── middleware.go     # All middleware definitions
+│   └── server/
+│       ├── server.go         # Server struct and lifecycle
+│       ├── http.go           # HTTP server setup
+│       └── routes.go         # Route definitions
+├── static/
+│   ├── static.go             # Embed directive
+│   ├── css/
+│   └── js/
+├── templates/
+│   ├── templates.go          # Embed and parse
+│   └── *.html
+├── go.mod
+├── go.sum
+├── Makefile
+└── Dockerfile
+```
+
+## Key Principles
+
+- **`cmd/{appname}/`**: Only the entry point. Minimal logic, just bootstrapping.
+- **`internal/`**: All application packages. Not importable by external
+  projects.
+- **One package per concern**: config, database, handlers, middleware, etc.
+- **Flat handler files**: One file per handler or logical group of handlers.
+
+---
+
+# 3. Dependency Injection (Uber fx)
+
+## Entry Point Pattern
+
+```go
+// cmd/httpd/main.go
+package main
+
+import (
+    "yourproject/internal/config"
+    "yourproject/internal/database"
+    "yourproject/internal/globals"
+    "yourproject/internal/handlers"
+    "yourproject/internal/healthcheck"
+    "yourproject/internal/logger"
+    "yourproject/internal/middleware"
+    "yourproject/internal/server"
+    "go.uber.org/fx"
+)
+
+var (
+    Appname   string = "CHANGEME"
+    Version   string
+    Buildarch string
+)
+
+func main() {
+    globals.Appname = Appname
+    globals.Version = Version
+    globals.Buildarch = Buildarch
+
+    fx.New(
+        fx.Provide(
+            config.New,
+            database.New,
+            globals.New,
+            handlers.New,
+            logger.New,
+            server.New,
+            middleware.New,
+            healthcheck.New,
+        ),
+        fx.Invoke(func(*server.Server) {}),
+    ).Run()
+}
+```
+
+## Params Struct Pattern
+
+Every component that receives dependencies uses a params struct with `fx.In`:
+
+```go
+type HandlersParams struct {
+    fx.In
+    Logger      *logger.Logger
+    Globals     *globals.Globals
+    Database    *database.Database
+    Healthcheck *healthcheck.Healthcheck
+}
+
+type Handlers struct {
+    params *HandlersParams
+    log    *slog.Logger
+    hc     *healthcheck.Healthcheck
+}
+```
+
+## Factory Function Pattern
+
+All components expose a `New` function with this signature:
+
+```go
+func New(lc fx.Lifecycle, params SomeParams) (*Something, error) {
+    s := new(Something)
+    s.params = &params
+    s.log = params.Logger.Get()
+
+    lc.Append(fx.Hook{
+        OnStart: func(ctx context.Context) error {
+            // Initialize resources
+            return nil
+        },
+        OnStop: func(ctx context.Context) error {
+            // Cleanup resources
+            return nil
+        },
+    })
+    return s, nil
+}
+```
+
+## Dependency Order
+
+Providers are resolved automatically by fx, but conceptually follow this order:
+
+1. `globals.New` - Build-time variables (no dependencies)
+2. `logger.New` - Logger (depends on Globals)
+3. `config.New` - Configuration (depends on Globals, Logger)
+4. `database.New` - Database (depends on Logger, Config)
+5. `healthcheck.New` - Health check (depends on Globals, Config, Logger,
+   Database)
+6. `middleware.New` - Middleware (depends on Logger, Globals, Config)
+7. `handlers.New` - Handlers (depends on Logger, Globals, Database, Healthcheck)
+8. `server.New` - Server (depends on all above)
+
+---
+
+# 4. Server Architecture
+
+## Server Struct
+
+The Server struct is the central orchestrator:
+
+```go
+// internal/server/server.go
+type ServerParams struct {
+    fx.In
+    Logger     *logger.Logger
+    Globals    *globals.Globals
+    Config     *config.Config
+    Middleware *middleware.Middleware
+    Handlers   *handlers.Handlers
+}
+
+type Server struct {
+    startupTime   time.Time
+    port          int
+    exitCode      int
+    sentryEnabled bool
+    log           *slog.Logger
+    ctx           context.Context
+    cancelFunc    context.CancelFunc
+    httpServer    *http.Server
+    router        *chi.Mux
+    params        ServerParams
+    mw            *middleware.Middleware
+    h             *handlers.Handlers
+}
+```
+
+## Server Factory
+
+```go
+func New(lc fx.Lifecycle, params ServerParams) (*Server, error) {
+    s := new(Server)
+    s.params = params
+    s.mw = params.Middleware
+    s.h = params.Handlers
+    s.log = params.Logger.Get()
+
+    lc.Append(fx.Hook{
+        OnStart: func(ctx context.Context) error {
+            s.startupTime = time.Now()
+            go s.Run()
+            return nil
+        },
+        OnStop: func(ctx context.Context) error {
+            // Server shutdown logic
+            return nil
+        },
+    })
+    return s, nil
+}
+```
+
+## HTTP Server Setup
+
+```go
+// internal/server/http.go
+func (s *Server) serveUntilShutdown() {
+    listenAddr := fmt.Sprintf(":%d", s.params.Config.Port)
+    s.httpServer = &http.Server{
+        Addr:           listenAddr,
+        ReadTimeout:    10 * time.Second,
+        WriteTimeout:   10 * time.Second,
+        MaxHeaderBytes: 1 << 20,
+        Handler:        s,
+    }
+
+    s.SetupRoutes()
+
+    s.log.Info("http begin listen", "listenaddr", listenAddr)
+    if err := s.httpServer.ListenAndServe(); err != nil && err != http.ErrServerClosed {
+        s.log.Error("listen error", "error", err)
+        if s.cancelFunc != nil {
+            s.cancelFunc()
+        }
+    }
+}
+
+func (s *Server) ServeHTTP(w http.ResponseWriter, r *http.Request) {
+    s.router.ServeHTTP(w, r)
+}
+```
+
+## Signal Handling and Graceful Shutdown
+
+```go
+func (s *Server) serve() int {
+    s.ctx, s.cancelFunc = context.WithCancel(context.Background())
+
+    // Signal watcher
+    go func() {
+        c := make(chan os.Signal, 1)
+        signal.Ignore(syscall.SIGPIPE)
+        signal.Notify(c, os.Interrupt, syscall.SIGTERM)
+        sig := <-c
+        s.log.Info("signal received", "signal", sig)
+        if s.cancelFunc != nil {
+            s.cancelFunc()
+        }
+    }()
+
+    go s.serveUntilShutdown()
+
+    for range s.ctx.Done() {
+    }
+    s.cleanShutdown()
+    return s.exitCode
+}
+
+func (s *Server) cleanShutdown() {
+    s.exitCode = 0
+    ctxShutdown, shutdownCancel := context.WithTimeout(context.Background(), 5*time.Second)
+    if err := s.httpServer.Shutdown(ctxShutdown); err != nil {
+        s.log.Error("server clean shutdown failed", "error", err)
+    }
+    if shutdownCancel != nil {
+        shutdownCancel()
+    }
+    s.cleanupForExit()
+    if s.sentryEnabled {
+        sentry.Flush(2 * time.Second)
+    }
+}
+```
+
+---
+
+# 5. Routing (go-chi)
+
+## Route Setup Pattern
+
+```go
+// internal/server/routes.go
+func (s *Server) SetupRoutes() {
+    s.router = chi.NewRouter()
+
+    // Global middleware (applied to all routes)
+    s.router.Use(middleware.Recoverer)
+    s.router.Use(middleware.RequestID)
+    s.router.Use(s.mw.Logging())
+
+    // Conditional middleware
+    if viper.GetString("METRICS_USERNAME") != "" {
+        s.router.Use(s.mw.Metrics())
+    }
+
+    s.router.Use(s.mw.CORS())
+    s.router.Use(middleware.Timeout(60 * time.Second))
+
+    if s.sentryEnabled {
+        sentryHandler := sentryhttp.New(sentryhttp.Options{
+            Repanic: true,
+        })
+        s.router.Use(sentryHandler.Handle)
+    }
+
+    // Routes
+    s.router.Get("/", s.h.HandleIndex())
+
+    // Static files
+    s.router.Mount("/s", http.StripPrefix("/s", http.FileServer(http.FS(static.Static))))
+
+    // API versioning
+    s.router.Route("/api/v1", func(r chi.Router) {
+        r.Get("/now", s.h.HandleNow())
+    })
+
+    // Routes with specific middleware
+    auth := s.mw.Auth()
+    s.router.Get("/login", auth(s.h.HandleLoginGET()).ServeHTTP)
+
+    // Health check (standard path)
+    s.router.Get("/.well-known/healthcheck", s.h.HandleHealthCheck())
+
+    // Protected route groups
+    if viper.GetString("METRICS_USERNAME") != "" {
+        s.router.Group(func(r chi.Router) {
+            r.Use(s.mw.MetricsAuth())
+            r.Get("/metrics", http.HandlerFunc(promhttp.Handler().ServeHTTP))
+        })
+    }
+}
+```
+
+## Middleware Ordering (Critical)
+
+1. `middleware.Recoverer` - Panic recovery (must be first)
+2. `middleware.RequestID` - Generate request IDs
+3. `s.mw.Logging()` - Request logging
+4. `s.mw.Metrics()` - Prometheus metrics (if enabled)
+5. `s.mw.CORS()` - CORS headers
+6. `middleware.Timeout(60s)` - Request timeout
+7. `sentryhttp.Handler` - Sentry error reporting (if enabled)
+
+## API Versioning
+
+Use route groups for API versioning:
+
+```go
+s.router.Route("/api/v1", func(r chi.Router) {
+    r.Get("/resource", s.h.HandleResource())
+})
+```
+
+## Static File Serving
+
+Static files are served at `/s/` prefix:
+
+```go
+s.router.Mount("/s", http.StripPrefix("/s", http.FileServer(http.FS(static.Static))))
+```
+
+---
+
+# 6. Handler Conventions
+
+## Handler Base Struct
+
+```go
+// internal/handlers/handlers.go
+type HandlersParams struct {
+    fx.In
+    Logger      *logger.Logger
+    Globals     *globals.Globals
+    Database    *database.Database
+    Healthcheck *healthcheck.Healthcheck
+}
+
+type Handlers struct {
+    params *HandlersParams
+    log    *slog.Logger
+    hc     *healthcheck.Healthcheck
+}
+
+func New(lc fx.Lifecycle, params HandlersParams) (*Handlers, error) {
+    s := new(Handlers)
+    s.params = &params
+    s.log = params.Logger.Get()
+    s.hc = params.Healthcheck
+    lc.Append(fx.Hook{
+        OnStart: func(ctx context.Context) error {
+            // Compile templates or other initialization
+            return nil
+        },
+    })
+    return s, nil
+}
+```
+
+## Closure-Based Handler Pattern
+
+All handlers return `http.HandlerFunc` using the closure pattern. This allows
+initialization logic to run once when the handler is created:
+
+```go
+// internal/handlers/index.go
+func (s *Handlers) HandleIndex() http.HandlerFunc {
+    // Initialization runs once
+    t := templates.GetParsed()
+
+    // Handler runs per-request
+    return func(w http.ResponseWriter, r *http.Request) {
+        err := t.ExecuteTemplate(w, "index.html", nil)
+        if err != nil {
+            s.log.Error("template execution failed", "error", err)
+            http.Error(w, http.StatusText(500), 500)
+        }
+    }
+}
+```
+
+## JSON Handler Pattern
+
+```go
+// internal/handlers/now.go
+func (s *Handlers) HandleNow() http.HandlerFunc {
+    // Response struct defined in closure scope
+    type response struct {
+        Now time.Time `json:"now"`
+    }
+    return func(w http.ResponseWriter, r *http.Request) {
+        s.respondJSON(w, r, &response{Now: time.Now()}, 200)
+    }
+}
+```
+
+## Response Helpers
+
+```go
+// internal/handlers/handlers.go
+func (s *Handlers) respondJSON(w http.ResponseWriter, r *http.Request, data interface{}, status int) {
+    w.WriteHeader(status)
+    w.Header().Set("Content-Type", "application/json")
+    if data != nil {
+        err := json.NewEncoder(w).Encode(data)
+        if err != nil {
+            s.log.Error("json encode error", "error", err)
+        }
+    }
+}
+
+func (s *Handlers) decodeJSON(w http.ResponseWriter, r *http.Request, v interface{}) error {
+    return json.NewDecoder(r.Body).Decode(v)
+}
+```
+
+## Handler Naming Convention
+
+- `HandleIndex()` - Main page
+- `HandleLoginGET()` / `HandleLoginPOST()` - Form handlers with HTTP method
+  suffix
+- `HandleNow()` - API endpoints
+- `HandleHealthCheck()` - System endpoints
+
+---
+
+# 7. Middleware Conventions
+
+## Middleware Struct
+
+```go
+// internal/middleware/middleware.go
+type MiddlewareParams struct {
+    fx.In
+    Logger  *logger.Logger
+    Globals *globals.Globals
+    Config  *config.Config
+}
+
+type Middleware struct {
+    log    *slog.Logger
+    params *MiddlewareParams
+}
+
+func New(lc fx.Lifecycle, params MiddlewareParams) (*Middleware, error) {
+    s := new(Middleware)
+    s.params = &params
+    s.log = params.Logger.Get()
+    return s, nil
+}
+```
+
+## Middleware Signature
+
+All custom middleware methods return `func(http.Handler) http.Handler`:
+
+```go
+func (s *Middleware) Auth() func(http.Handler) http.Handler {
+    return func(next http.Handler) http.Handler {
+        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+            // Before request
+            s.log.Info("AUTH: before request")
+
+            next.ServeHTTP(w, r)
+
+            // After request (optional)
+        })
+    }
+}
+```
+
+## Logging Middleware with Status Capture
+
+```go
+type loggingResponseWriter struct {
+    http.ResponseWriter
+    statusCode int
+}
+
+func NewLoggingResponseWriter(w http.ResponseWriter) *loggingResponseWriter {
+    return &loggingResponseWriter{w, http.StatusOK}
+}
+
+func (lrw *loggingResponseWriter) WriteHeader(code int) {
+    lrw.statusCode = code
+    lrw.ResponseWriter.WriteHeader(code)
+}
+
+func (s *Middleware) Logging() func(http.Handler) http.Handler {
+    return func(next http.Handler) http.Handler {
+        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+            start := time.Now()
+            lrw := NewLoggingResponseWriter(w)
+            ctx := r.Context()
+            defer func() {
+                latency := time.Since(start)
+                s.log.InfoContext(ctx, "request",
+                    "request_start", start,
+                    "method", r.Method,
+                    "url", r.URL.String(),
+                    "useragent", r.UserAgent(),
+                    "request_id", ctx.Value(middleware.RequestIDKey).(string),
+                    "referer", r.Referer(),
+                    "proto", r.Proto,
+                    "remoteIP", ipFromHostPort(r.RemoteAddr),
+                    "status", lrw.statusCode,
+                    "latency_ms", latency.Milliseconds(),
+                )
+            }()
+            next.ServeHTTP(lrw, r)
+        })
+    }
+}
+```
+
+## CORS Middleware
+
+```go
+func (s *Middleware) CORS() func(http.Handler) http.Handler {
+    return cors.Handler(cors.Options{
+        AllowedOrigins:   []string{"*"},
+        AllowedMethods:   []string{"GET", "POST", "PUT", "DELETE", "OPTIONS"},
+        AllowedHeaders:   []string{"Accept", "Authorization", "Content-Type", "X-CSRF-Token"},
+        ExposedHeaders:   []string{"Link"},
+        AllowCredentials: false,
+        MaxAge:           300,
+    })
+}
+```
+
+## Metrics Middleware
+
+```go
+func (s *Middleware) Metrics() func(http.Handler) http.Handler {
+    mdlw := ghmm.New(ghmm.Config{
+        Recorder: metrics.NewRecorder(metrics.Config{}),
+    })
+    return func(next http.Handler) http.Handler {
+        return std.Handler("", mdlw, next)
+    }
+}
+
+func (s *Middleware) MetricsAuth() func(http.Handler) http.Handler {
+    return basicauth.New(
+        "metrics",
+        map[string][]string{
+            viper.GetString("METRICS_USERNAME"): {
+                viper.GetString("METRICS_PASSWORD"),
+            },
+        },
+    )
+}
+```
+
+---
+
+# 8. Configuration (Viper)
+
+## Config Struct
+
+```go
+// internal/config/config.go
+type ConfigParams struct {
+    fx.In
+    Globals *globals.Globals
+    Logger  *logger.Logger
+}
+
+type Config struct {
+    DBURL           string
+    Debug           bool
+    MaintenanceMode bool
+    MetricsPassword string
+    MetricsUsername string
+    Port            int
+    SentryDSN       string
+    params          *ConfigParams
+    log             *slog.Logger
+}
+```
+
+## Configuration Loading
+
+```go
+func New(lc fx.Lifecycle, params ConfigParams) (*Config, error) {
+    log := params.Logger.Get()
+    name := params.Globals.Appname
+
+    // Config file settings
+    viper.SetConfigName(name)
+    viper.SetConfigType("yaml")
+    viper.AddConfigPath(fmt.Sprintf("/etc/%s", name))
+    viper.AddConfigPath(fmt.Sprintf("$HOME/.config/%s", name))
+
+    // Environment variables override everything
+    viper.AutomaticEnv()
+
+    // Defaults
+    viper.SetDefault("DEBUG", "false")
+    viper.SetDefault("MAINTENANCE_MODE", "false")
+    viper.SetDefault("PORT", "8080")
+    viper.SetDefault("DBURL", "")
+    viper.SetDefault("SENTRY_DSN", "")
+    viper.SetDefault("METRICS_USERNAME", "")
+    viper.SetDefault("METRICS_PASSWORD", "")
+
+    // Read config file (optional)
+    if err := viper.ReadInConfig(); err != nil {
+        if _, ok := err.(viper.ConfigFileNotFoundError); ok {
+            // Config file not found is OK
+        } else {
+            log.Error("config file malformed", "error", err)
+            panic(err)
+        }
+    }
+
+    // Build config struct
+    s := &Config{
+        DBURL:           viper.GetString("DBURL"),
+        Debug:           viper.GetBool("debug"),
+        Port:            viper.GetInt("PORT"),
+        SentryDSN:       viper.GetString("SENTRY_DSN"),
+        MaintenanceMode: viper.GetBool("MAINTENANCE_MODE"),
+        MetricsUsername: viper.GetString("METRICS_USERNAME"),
+        MetricsPassword: viper.GetString("METRICS_PASSWORD"),
+        log:             log,
+        params:          &params,
+    }
+
+    // Enable debug logging if configured
+    if s.Debug {
+        params.Logger.EnableDebugLogging()
+        s.log = params.Logger.Get()
+    }
+
+    return s, nil
+}
+```
+
+## Configuration Precedence
+
+1. **Environment variables** (highest priority via `AutomaticEnv()`)
+2. **`.env` file** (loaded via `godotenv/autoload` import)
+3. **Config files**: `/etc/{appname}/{appname}.yaml`,
+   `~/.config/{appname}/{appname}.yaml`
+4. **Defaults** (lowest priority)
+
+## Environment Loading
+
+Import godotenv with autoload to automatically load `.env` files:
+
+```go
+import (
+    _ "github.com/joho/godotenv/autoload"
+)
+```
+
+---
+
+# 9. Logging (slog)
+
+## Logger Struct
+
+```go
+// internal/logger/logger.go
+type LoggerParams struct {
+    fx.In
+    Globals *globals.Globals
+}
+
+type Logger struct {
+    log    *slog.Logger
+    level  *slog.LevelVar
+    params LoggerParams
+}
+```
+
+## Logger Setup with TTY Detection
+
+```go
+func New(lc fx.Lifecycle, params LoggerParams) (*Logger, error) {
+    l := new(Logger)
+    l.level = new(slog.LevelVar)
+    l.level.Set(slog.LevelInfo)
+
+    // TTY detection for dev vs prod output
+    tty := false
+    if fileInfo, _ := os.Stdout.Stat(); (fileInfo.Mode() & os.ModeCharDevice) != 0 {
+        tty = true
+    }
+
+    var handler slog.Handler
+    if tty {
+        // Text output for development
+        handler = slog.NewTextHandler(os.Stdout, &slog.HandlerOptions{
+            Level:     l.level,
+            AddSource: true,
+        })
+    } else {
+        // JSON output for production
+        handler = slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{
+            Level:     l.level,
+            AddSource: true,
+        })
+    }
+
+    l.log = slog.New(handler)
+    return l, nil
+}
+```
+
+## Logger Methods
+
+```go
+func (l *Logger) EnableDebugLogging() {
+    l.level.Set(slog.LevelDebug)
+    l.log.Debug("debug logging enabled", "debug", true)
+}
+
+func (l *Logger) Get() *slog.Logger {
+    return l.log
+}
+
+func (l *Logger) Identify() {
+    l.log.Info("starting",
+        "appname", l.params.Globals.Appname,
+        "version", l.params.Globals.Version,
+        "buildarch", l.params.Globals.Buildarch,
+    )
+}
+```
+
+## Logging Patterns
+
+```go
+// Info with fields
+s.log.Info("message", "key", "value")
+
+// Error with error object
+s.log.Error("operation failed", "error", err)
+
+// With context
+s.log.InfoContext(ctx, "processing request", "request_id", reqID)
+
+// Structured request logging
+s.log.Info("request completed",
+    "request_start", start,
+    "method", r.Method,
+    "url", r.URL.String(),
+    "status", statusCode,
+    "latency_ms", latency.Milliseconds(),
+)
+
+// Using slog.Group for nested attributes
+s.log.Info("request",
+    slog.Group("http",
+        "method", r.Method,
+        "url", r.URL.String(),
+    ),
+    slog.Group("timing",
+        "start", start,
+        "latency_ms", latency.Milliseconds(),
+    ),
+)
+```
+
+---
+
+# 10. Database Wrapper
+
+## Database Struct
+
+```go
+// internal/database/database.go
+type DatabaseParams struct {
+    fx.In
+    Logger *logger.Logger
+    Config *config.Config
+}
+
+type Database struct {
+    URL    string
+    log    *slog.Logger
+    params *DatabaseParams
+}
+```
+
+## Database Factory with Lifecycle
+
+```go
+func New(lc fx.Lifecycle, params DatabaseParams) (*Database, error) {
+    s := new(Database)
+    s.params = &params
+    s.log = params.Logger.Get()
+
+    s.log.Info("Database instantiated")
+
+    lc.Append(fx.Hook{
+        OnStart: func(ctx context.Context) error {
+            s.log.Info("Database OnStart Hook")
+            // Connect to database here
+            // Example: s.db, err = sql.Open("postgres", s.params.Config.DBURL)
+            return nil
+        },
+        OnStop: func(ctx context.Context) error {
+            // Disconnect from database here
+            // Example: s.db.Close()
+            return nil
+        },
+    })
+    return s, nil
+}
+```
+
+## Usage Pattern
+
+The Database struct is injected into handlers and other services:
+
+```go
+type HandlersParams struct {
+    fx.In
+    Database *database.Database
+    // ...
+}
+
+// Access in handler
+func (s *Handlers) HandleSomething() http.HandlerFunc {
+    return func(w http.ResponseWriter, r *http.Request) {
+        // Use s.params.Database
+    }
+}
+```
+
+---
+
+# 11. Globals Package
+
+## Package Variables and Struct
+
+```go
+// internal/globals/globals.go
+package globals
+
+import "go.uber.org/fx"
+
+// Package-level variables (set from main)
+var (
+    Appname   string
+    Version   string
+    Buildarch string
+)
+
+// Struct for DI
+type Globals struct {
+    Appname   string
+    Version   string
+    Buildarch string
+}
+
+func New(lc fx.Lifecycle) (*Globals, error) {
+    n := &Globals{
+        Appname:   Appname,
+        Buildarch: Buildarch,
+        Version:   Version,
+    }
+    return n, nil
+}
+```
+
+## Setting Globals in Main
+
+```go
+// cmd/httpd/main.go
+var (
+    Appname   string = "CHANGEME"  // Default, overridden by build
+    Version   string               // Set at build time
+    Buildarch string               // Set at build time
+)
+
+func main() {
+    globals.Appname = Appname
+    globals.Version = Version
+    globals.Buildarch = Buildarch
+    // ...
+}
+```
+
+## Build-Time Variable Injection
+
+Use ldflags to inject version information at build time:
+
+```makefile
+VERSION := $(shell git describe --tags --always)
+BUILDARCH := $(shell go env GOARCH)
+
+build:
+    go build -ldflags "-X main.Version=$(VERSION) -X main.Buildarch=$(BUILDARCH)" ./cmd/httpd
+```
+
+---
+
+# 12. Static Assets & Templates
+
+## Static File Embedding
+
+```go
+// static/static.go
+package static
+
+import "embed"
+
+//go:embed css js
+var Static embed.FS
+```
+
+Directory structure:
+
+```
+static/
+├── static.go
+├── css/
+│   ├── bootstrap-4.5.3.min.css
+│   └── style.css
+└── js/
+    ├── bootstrap-4.5.3.bundle.min.js
+    └── jquery-3.5.1.slim.min.js
+```
+
+## Template Embedding and Lazy Parsing
+
+```go
+// templates/templates.go
+package templates
+
+import (
+    "embed"
+    "text/template"
+)
+
+//go:embed *.html
+var TemplatesRaw embed.FS
+var TemplatesParsed *template.Template
+
+func GetParsed() *template.Template {
+    if TemplatesParsed == nil {
+        TemplatesParsed = template.Must(template.ParseFS(TemplatesRaw, "*"))
+    }
+    return TemplatesParsed
+}
+```
+
+## Template Composition
+
+Templates use Go's template composition:
+
+```html
+<!-- index.html -->
+{{ template "htmlheader.html" . }} {{ template "navbar.html" . }}
+
+<main>
+    <!-- Page content -->
+</main>
+
+{{ template "pagefooter.html" . }} {{ template "htmlfooter.html" . }}
+```
+
+## Static Asset References
+
+Reference static files with `/s/` prefix:
+
+```html
+<link rel="stylesheet" href="/s/css/bootstrap-4.5.3.min.css" />
+<link rel="stylesheet" href="/s/css/style.css" />
+<script src="/s/js/jquery-3.5.1.slim.min.js"></script>
+```
+
+---
+
+# 13. Health Check
+
+## Health Check Service
+
+```go
+// internal/healthcheck/healthcheck.go
+type HealthcheckParams struct {
+    fx.In
+    Globals  *globals.Globals
+    Config   *config.Config
+    Logger   *logger.Logger
+    Database *database.Database
+}
+
+type Healthcheck struct {
+    StartupTime time.Time
+    log         *slog.Logger
+    params      *HealthcheckParams
+}
+
+func New(lc fx.Lifecycle, params HealthcheckParams) (*Healthcheck, error) {
+    s := new(Healthcheck)
+    s.params = &params
+    s.log = params.Logger.Get()
+
+    lc.Append(fx.Hook{
+        OnStart: func(ctx context.Context) error {
+            s.StartupTime = time.Now()
+            return nil
+        },
+        OnStop: func(ctx context.Context) error {
+            return nil
+        },
+    })
+    return s, nil
+}
+```
+
+## Health Check Response
+
+```go
+type HealthcheckResponse struct {
+    Status        string `json:"status"`
+    Now           string `json:"now"`
+    UptimeSeconds int64  `json:"uptime_seconds"`
+    UptimeHuman   string `json:"uptime_human"`
+    Version       string `json:"version"`
+    Appname       string `json:"appname"`
+    Maintenance   bool   `json:"maintenance_mode"`
+}
+
+func (s *Healthcheck) uptime() time.Duration {
+    return time.Since(s.StartupTime)
+}
+
+func (s *Healthcheck) Healthcheck() *HealthcheckResponse {
+    resp := &HealthcheckResponse{
+        Status:        "ok",
+        Now:           time.Now().UTC().Format(time.RFC3339Nano),
+        UptimeSeconds: int64(s.uptime().Seconds()),
+        UptimeHuman:   s.uptime().String(),
+        Appname:       s.params.Globals.Appname,
+        Version:       s.params.Globals.Version,
+    }
+    return resp
+}
+```
+
+## Standard Endpoint
+
+Health check is served at the standard `.well-known` path:
+
+```go
+s.router.Get("/.well-known/healthcheck", s.h.HandleHealthCheck())
+```
+
+---
+
+# 14. External Integrations
+
+## Sentry Error Reporting
+
+Sentry is conditionally enabled based on `SENTRY_DSN` environment variable:
+
+```go
+func (s *Server) enableSentry() {
+    s.sentryEnabled = false
+
+    if s.params.Config.SentryDSN == "" {
+        return
+    }
+
+    err := sentry.Init(sentry.ClientOptions{
+        Dsn:     s.params.Config.SentryDSN,
+        Release: fmt.Sprintf("%s-%s", s.params.Globals.Appname, s.params.Globals.Version),
+    })
+    if err != nil {
+        s.log.Error("sentry init failure", "error", err)
+        os.Exit(1)
+        return
+    }
+    s.log.Info("sentry error reporting activated")
+    s.sentryEnabled = true
+}
+```
+
+Sentry middleware with repanic (bubbles panics to chi's Recoverer):
+
+```go
+if s.sentryEnabled {
+    sentryHandler := sentryhttp.New(sentryhttp.Options{
+        Repanic: true,
+    })
+    s.router.Use(sentryHandler.Handle)
+}
+```
+
+Flush Sentry on shutdown:
+
+```go
+if s.sentryEnabled {
+    sentry.Flush(2 * time.Second)
+}
+```
+
+## Prometheus Metrics
+
+Metrics are conditionally enabled and protected by basic auth:
+
+```go
+// Only enable if credentials are configured
+if viper.GetString("METRICS_USERNAME") != "" {
+    s.router.Use(s.mw.Metrics())
+}
+
+// Protected /metrics endpoint
+if viper.GetString("METRICS_USERNAME") != "" {
+    s.router.Group(func(r chi.Router) {
+        r.Use(s.mw.MetricsAuth())
+        r.Get("/metrics", http.HandlerFunc(promhttp.Handler().ServeHTTP))
+    })
+}
+```
+
+## Environment Variables Summary
+
+| Variable           | Description                      | Default |
+| ------------------ | -------------------------------- | ------- |
+| `PORT`             | HTTP listen port                 | 8080    |
+| `DEBUG`            | Enable debug logging             | false   |
+| `DBURL`            | Database connection URL          | ""      |
+| `SENTRY_DSN`       | Sentry DSN for error reporting   | ""      |
+| `MAINTENANCE_MODE` | Enable maintenance mode          | false   |
+| `METRICS_USERNAME` | Basic auth username for /metrics | ""      |
+| `METRICS_PASSWORD` | Basic auth password for /metrics | ""      |
+
+# Author
+
+[@sjdev](https://sjdev.co) <[sj@sjdev.co(mailto:sj@sjdev.berlin)>
+
+# License
+
+MIT. See [LICENSE](../LICENSE).
diff --git a/LLM_DEV_PROMPTS/LICENSE b/LLM_DEV_PROMPTS/LICENSE
new file mode 100644
index 0000000..4b72aca
--- /dev/null
+++ b/LLM_DEV_PROMPTS/LICENSE
@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 sjdev
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
diff --git a/LLM_DEV_PROMPTS/Makefile b/LLM_DEV_PROMPTS/Makefile
new file mode 100644
index 0000000..62ec399
--- /dev/null
+++ b/LLM_DEV_PROMPTS/Makefile
@@ -0,0 +1,31 @@
+.PHONY: test lint fmt fmt-check check docker hooks
+
+# flags are repeated here (also in .prettierrc) so this Makefile works
+# standalone when copied as a template
+PRETTIER := yarn run prettier
+
+test:
+	@echo "No tests defined."
+
+lint:
+	@echo "Linting markdown files..."
+	@$(PRETTIER) --check '**/*.md' --tab-width 4 --prose-wrap always
+
+fmt:
+	@$(PRETTIER) --write '**/*.md' --tab-width 4 --prose-wrap always
+
+fmt-check:
+	@$(PRETTIER) --check '**/*.md' --tab-width 4 --prose-wrap always
+
+check: test lint fmt-check
+
+docker:
+	docker build -t prompts .
+
+hooks:
+	@printf '#!/bin/sh\nset -e\n' > .git/hooks/pre-commit
+	@if [ -f go.mod ]; then \
+		printf 'go mod tidy\ngo fmt ./...\ngit diff --exit-code -- go.mod go.sum || { echo "go mod tidy changed files; please stage and retry"; exit 1; }\n' >> .git/hooks/pre-commit; \
+	fi
+	@printf 'make check\n' >> .git/hooks/pre-commit
+	@chmod +x .git/hooks/pre-commit
diff --git a/LLM_DEV_PROMPTS/NODEJS PROJECTS/CODE_STYLEGUIDE_JS.md b/LLM_DEV_PROMPTS/NODEJS PROJECTS/CODE_STYLEGUIDE_JS.md
new file mode 100644
index 0000000..6607408
--- /dev/null
+++ b/LLM_DEV_PROMPTS/NODEJS PROJECTS/CODE_STYLEGUIDE_JS.md	
@@ -0,0 +1,81 @@
+---
+title: Code Styleguide — JavaScript
+last_modified: 2026-02-22
+---
+
+1. Use `const` for all declarations, unless you need to reassign, then use `let`. Never use
+   `var`.
+
+2. Indentation: Use 2 spaces.  Do not use tabs.
+
+3. Semicolons shoudl be used at the end of statements.
+
+4. Quotes: Prefer single quotes for strings, unless working with JSON or needing to separate object strings.
+
+5. Limit lines to approximately 80 characters for better readability.
+
+6. Brace Placement: Place the opening brace on the same line as the statement (e.g., if (true) {).
+
+7. Naming Conventions:
+   
+   Variables, properties, and functions use lowerCamelCase.
+   Class names use UpperCamelCase (PascalCase).
+   Constants use UPPERCASE_WITH_UNDERSCORES. 
+
+8. Equality: Always use the strict equality operator (===) over the abstract equality operator (==).
+
+9. Use npm for package management, avoid using yarn.
+
+10. Use nvm and install/select the most current LTS Node version.
+
+11. Use `prettier` for code formatting, with four spaces for indentation.
+
+12. At a minimum, both `npm run test`/`npm run build` should work (complete the appropriate scripts in `package.json`). However, prefer `make test` and `make build` instead —
+
+13. The Makefile is authoritative on how to interact with the repo. See
+   [Repository Policies](https://github.com/kjannette/LLM_DEV_PROMPTS/blob/master/REPO_POLICIES.md) for details.
+
+14. Use UNIX-style newlines (\n), and a newline character as the last character of a file. Windows-style newlines (\r\n) are forbidden inside any Node/JS repository.
+
+15. Declare one variable per statement:
+
+**Correct:**
+
+```
+   const keys   = ['foo', 'bar'];
+   const values = [23, 42];
+   const object = {};
+```
+**Incorrect:**
+
+```
+const keys = ['foo', 'bar'],
+      values = [23, 42],
+      object = {},
+```
+
+16.  Name closures in order to produce better stack traces, heap and cpu profiles.
+
+**Correct:**
+
+```
+req.on('end', function onEnd() {
+  console.log('winning');
+});
+```
+**Incorrect:**
+
+```
+req.on('end', function() {
+  console.log('losing');
+});
+```
+
+# Author
+
+[@sjDev](https://sjdev.co)
+&lt;[sj@sjdev.co](mailto:sj@sjdev.co)&gt;
+
+# License
+
+MIT. See [LICENSE](../LICENSE).
diff --git a/LLM_DEV_PROMPTS/NODEJS PROJECTS/NODE_BACKEND_ARCH_BASICS.md b/LLM_DEV_PROMPTS/NODEJS PROJECTS/NODE_BACKEND_ARCH_BASICS.md
new file mode 100644
index 0000000..6f2f39c
--- /dev/null
+++ b/LLM_DEV_PROMPTS/NODEJS PROJECTS/NODE_BACKEND_ARCH_BASICS.md	
@@ -0,0 +1,30 @@
+---
+title: Node Backend Architectural Basic Principals
+last_modified: 2026-03-02
+---
+
+1. Separate concerns  into distinct layers. 
+
+2. Adhering to the above pricinciple makes c ode more extensible, testable and maintainable. Group around functionality, adhering to the following structure on the backend:
+
+ a. **Routes/Controllers:** Handle API endpoints and process the request/response cycle. Controllers should be kept lean, delegating business logic to the service layer.
+
+ b. **Services/Business Logic:** Contain the core application logic and domain rules. This layer orchestrates interactions between other components.
+
+ c.  **Models/Data Access:** Interact with the database (using ORMs like Mongoose or Sequelize). Abstract database logic into repositories for reusability.
+
+ d. **Middleware:** Used for cross-cutting concerns such as cors, authentication, logging, and error handling.
+
+3. Modularity: Break code into the smallest reusable modules that make logical sense.  Each discreet class or method should have a single responsibility.
+
+4. Objects should depend on abstractions, not concretions. High-level modules contain the core business logic or application-specific behavior.
+Lower-level modules deal with implementation details, such as interacting with a database, file system, or external APIs.
+
+# Author
+
+[@sjDev](https://sjdev.co)
+&lt;[sj@sjdev.co](mailto:sj@sjdev.co)&gt;
+
+# License
+
+MIT. See [LICENSE](../LICENSE).
diff --git a/LLM_DEV_PROMPTS/PYTHON PROJECTS/CODE_STYLEGUIDE_PYTHON.md b/LLM_DEV_PROMPTS/PYTHON PROJECTS/CODE_STYLEGUIDE_PYTHON.md
new file mode 100644
index 0000000..86d842c
--- /dev/null
+++ b/LLM_DEV_PROMPTS/PYTHON PROJECTS/CODE_STYLEGUIDE_PYTHON.md	
@@ -0,0 +1,54 @@
+---
+title: Code Styleguide — Python
+last_modified: 2026-02-22
+---
+
+1. Standard Project Layout.  Use the src/ layout to prevent accidental imports from the root and ensure your project behaves like an installed package:
+
+my_project/
+├── pyproject.toml      # Modern tool & dependency configuration
+├── README.md           # Instructions for humans
+├── LICENSE             # Usage rights
+├── .gitignore          # Exclude venv/, __pycache__/, .env
+├── src/
+│   └── my_project/     # Main package
+│       ├── __init__.py
+│       ├── main.py     # Minimal entry point logic
+│       └── core.py     # Business logic
+├── tests/              # Mirror src structure for testing
+└── docs/               # Technical documentation
+
+2. Virtual Environments: Always isolate project dependencies using venv or pyenv to avoid conflicts with system-wide packages.
+
+3. Adhere to PEP 8: Use 4 spaces for indentation (no tabs), limit lines to 79 characters, and use two blank lines between top-level functions.
+
+4. Put code in functions. If you are writing a script, put the script in a
+function called `main` and call `main()` at the end of the script using the
+standard invocation:
+
+    ```python
+    if __name__ == "__main__":
+        main()
+    ```
+5. Keep main.py Boring: The entry point should only orchestrate (load config, start app). Heavy business logic should live in specialized modules.
+
+6. Config Isolation: Never hardcode secrets or database URLs. Use a .env file with libraries like python-dotenv or Pydantic Settings.
+
+7. Logging over Printing: Use Python’s built-in logging module to track errors and application state in production.
+
+8. Test-First: Treat your tests/ directory as first-class code. Use pytest for its powerful features and simple syntax.
+
+9. Naming Conventions: Use snake_case for functions and variables, PascalCase for classes, and UPPER_CASE for constants.
+
+10. pyproject.toml: Use this as the single source of truth for project metadata and tool configurations (replaces setup.py).
+
+11. Modular Design: Group code by domain (e.g., /users, /payments) rather than function (e.g., utils.py) to maintain separation of concerns.
+
+# Author
+
+[@sjdev](https://sjdev.co)
+&lt;[sj@sjdev.co](mailto:sj@sjdev.berlin)&gt;
+
+# License
+
+MIT. See [LICENSE](../LICENSE).
diff --git a/LLM_DEV_PROMPTS/README.md b/LLM_DEV_PROMPTS/README.md
new file mode 100644
index 0000000..0f209ef
--- /dev/null
+++ b/LLM_DEV_PROMPTS/README.md
@@ -0,0 +1,139 @@
+# LLM Development Prompts
+
+An MIT-licensed collection of LLM prompts by [@sjdev](https://sjdev.co), intended for use in bootstrapping new projects or building out new features in existing codebases.
+
+The prompts set forth best practices and procedural directives that must be followed in architecture and development. Think of this repo as akin to the Chicago Manual of Style, AP Stylebook (for journalism), or The ALWD Guide to Legal Citation.
+
+The prompts include 1) general repository development standards and 2) language and framework-specific development directives, intended to be reviewed by the code-building model at the outset work and followed throughout the work’s progress.  For example, the Javascript code styleguide sets forth the simple directive: “[u]se const for all declarations, unless you need to reassign, then use let. Never use var.”  
+
+These prompts are a work in progress.  I add to them as I work on new projects in new languages and frameworks, and I am also still in the process of memorializing prompts relating to languages and frameworks I have used for many years.
+
+# Usage - generally
+
+Imagine the scenario: you, as a developer, are tasked with adding a new feature to an existing codebase, with maximum automation via LLM code generation.  At the outset, before adressing the substantive implementation, you would run the following prompt (discussed in greater detail below):
+
+Read $TD/prompts/REPO_POLICIES.md and $TD/prompts/EXISTING_REPO_CHECKLIST.md, then bring this repo up to those
+standards. Your scope is repo scaffolding and policy compliance: Makefile, Dockerfile, .dockerignore, .gitignore, .editorconfig, CI
+workflow, README sections, LICENSE, REPO_POLICIES.md, and any language-specific config files (.golangci.yml, .prettierrc, etc.).
+
+## Quick Start - optional scripts for cli agent
+
+### Existing Repo
+
+Run from within the repo you want to bring up to standard. Clone the prompts repo once, then run both commands in order.
+
+```bash
+export TD="$(mktemp -d)"
+git clone --depth 1 https://github.com/kjannette/LLM_DEV_PROMPTS.git "$TD"
+```
+
+**Repository structure and policies:**
+
+```bash
+claude "Read $TD/prompts/REPO_POLICIES.md and
+$TD/prompts/EXISTING_REPO_CHECKLIST.md, then bring this repo up to those
+standards. Your scope is repo scaffolding and policy compliance:
+Makefile, Dockerfile, .dockerignore, .gitignore, .editorconfig, CI
+workflow, README sections, LICENSE, REPO_POLICIES.md, and any
+language-specific config files (.golangci.yml, .prettierrc, etc.).
+You must also run the formatter (make fmt) and fix any linter errors
+(make lint) so that make check passes — this will touch source code,
+but do not restructure, refactor, or rewrite any application logic.
+Follow the policies yourself: work on a feature branch, never git add -A,
+and make each logical change a separate commit (e.g. one commit for
+formatting, one for linter fixes, one for README updates, one for each
+new repo file added, etc.)."
+```
+
+**Code style and conventions:**
+
+```bash
+claude "Read $TD/prompts/CODE_STYLEGUIDE.md and whichever
+language-specific styleguides in $TD/prompts/ apply to this repo
+(CODE_STYLEGUIDE_GO.md, CODE_STYLEGUIDE_JS.md, CODE_STYLEGUIDE_PYTHON.md,
+GO_HTTP_SERVER_CONVENTIONS.md). Then review the application code in this
+repo and bring it into compliance with those coding standards. Your scope
+is application code structure and style: naming, patterns, error
+handling, project layout, and conventions described in the styleguides.
+Do not modify repo scaffolding (Makefile, Dockerfile, CI workflow,
+.gitignore, .editorconfig, etc.) — only application code. Work on a
+feature branch, never git add -A, and make each logical change a
+separate commit."
+```
+
+### New Repo
+
+Run from inside the directory where you want to create a new repo. Clone the
+prompts repo once, then run both commands in order.
+
+```bash
+export TD="$(mktemp -d)"
+git clone --depth 1 https://github.com/kjannette/LLM_DEV_PROMPTS.git "$TD"
+```
+
+**Repository scaffolding:**
+
+```bash
+claude "Read $TD/prompts/REPO_POLICIES.md and
+$TD/prompts/NEW_REPO_CHECKLIST.md, then set up this new repo according
+to those standards. Your scope is repo structure and required files:
+README.md, LICENSE, REPO_POLICIES.md, Makefile, Dockerfile, .dockerignore,
+.gitignore, .editorconfig, CI workflow, and language-specific config.
+Run the formatter (make fmt) and fix any linter errors (make lint) so
+that make check passes — this will touch source code, but do not
+restructure, refactor, or rewrite any application logic. Follow the
+policies yourself: work on a feature branch, never git add -A, and make
+each logical change a separate commit (e.g. one commit for formatting,
+one for linter fixes, one for README, one for each new repo file, etc.)."
+```
+
+**Code style and conventions:**
+
+```bash
+claude "Read $TD/prompts/CODE_STYLEGUIDE.md and whichever
+language-specific styleguides in $TD/prompts/ apply to this repo
+(CODE_STYLEGUIDE_GO.md, CODE_STYLEGUIDE_JS.md, CODE_STYLEGUIDE_PYTHON.md,
+GO_HTTP_SERVER_CONVENTIONS.md). Then review the application code in this
+repo and bring it into compliance with those coding standards. Your scope
+is application code structure and style: naming, patterns, error
+handling, project layout, and conventions described in the styleguides.
+Do not modify repo scaffolding (Makefile, Dockerfile, CI workflow,
+.gitignore, .editorconfig, etc.) — only application code. Work on a
+feature branch, never git add -A, and make each logical change a
+separate commit."
+```
+
+## Getting Started
+
+```bash
+git clone https://github.com/kjannette/LLM_DEV_PROMPTS.git
+cd prompts
+```
+
+Prompts are stored as Markdown files in `prompts/`. Copy or reference them as
+needed in your projects.
+
+## Rationale
+
+LLM prompts, especially development policies, benefit from version control and a
+single authoritative source. This repo provides a central place to maintain,
+share, and evolve prompts across projects.
+
+## Design
+
+The repository is a collection of Markdown files organized in the `prompts/`
+subdirectory. Each file contains one or more related prompts or policy
+documents. There is no build step or runtime component; the prompts are consumed
+by copying them into other projects or referencing them directly.
+
+## TODO
+
+- Add more prompt templates for common development tasks
+
+## License
+
+MIT. See [LICENSE](LICENSE).
+
+## Author
+
+[@sjdev](https://sjdev.co)
diff --git a/LLM_DEV_PROMPTS/TYPESCRIPT PROJECTS/CODE_STYLEGUIDE_TYPESCRIPT.md b/LLM_DEV_PROMPTS/TYPESCRIPT PROJECTS/CODE_STYLEGUIDE_TYPESCRIPT.md
new file mode 100644
index 0000000..b7fe69d
--- /dev/null
+++ b/LLM_DEV_PROMPTS/TYPESCRIPT PROJECTS/CODE_STYLEGUIDE_TYPESCRIPT.md	
@@ -0,0 +1,214 @@
+1. General Types
+
+Don't ever use the types Number, String, Boolean, Symbol, or Object These types refer to non-primitive boxed objects that are almost never used appropriately in JavaScript code.
+
+/* WRONG */
+function reverse(s: String): String;
+
+Do use the types number, string, boolean, and symbol.
+
+/* OK */
+function reverse(s: string): string;
+
+Instead of Object, use the non-primitive object type.
+
+2. Use const and let
+
+JavaScript first searches to see if a variable exists locally, then searches progressively in higher levels of scope until global variables. var is function scope, but, let and const are block scope. 
+
+Using let and const where appropriate makes the intention of the declarations clearer. 
+
+It will also help in identifying issues when a value is reassigned to a constant accidentally by throwing a compile time error. 
+
+Use a linter that automates checking and fixing this so that changing let to const doesn't become a delay in code review.
+
+3. Use === instead of ==
+
+JavaScript utilizes two different kinds of equality operators: === | !== and == | !=. 
+
+It is considered best practice to always use the former set when comparing. 
+
+If two operands are of the same type and value, then === produces true and !== produces false. 
+
+However, when working with == and !=, we'll run into issues when working with different types. In these cases, they'll try to coerce the values, unsuccessfully.
+
+4. Use the fastest way to loop arrays
+
+There are many ways to loop through array. The first way is a for loop.  Other ways include the for...of loop, the forEach method for arrays, map, filter, and others. There is also the while loop. 
+
+The for loop is the fastest way. Caching the length makes the loop perform better. Some browser engines have optimized the for loop without manually caching the length property. The forEach is slower than the for loop, so it's probably better to avoid it, especially for large arrays. However, unless we are desperate for performance at the code level (which is rare), make it readable. For example, we can use the for loop in server-side applications and the array methods in client-side applications, because, in general, we don't have expensive operations on the client-side.
+
+5. Prefer array methods
+
+It is recommended to use a functional approach without intermediate variables. The base JavaScript for loop can be more performant in some browsers but the benefit can be measured only by iterating over millions of items. It is the job of compiler and runtime to remove the penalty of using new array methods. 
+
+6. Do not trust any data - Validate
+
+Make sure that all the data that goes into our system is clean and exactly what we need. This is most important on the back end when writing out parameters retrieved from the URL. 
+
+The same applies to forms that validate only on the client side. Another very insecure practice is to read information from the DOM and use it without validation.
+
+7. Generics
+
+Don't ever have a generic type which doesn't use its type parameter.
+
+8. Any
+
+Don't use any as a type unless you are in the process of migrating a JavaScript project to TypeScript. The compiler effectively treats any as "please turn off type checking for this thing". It is similar to putting an @ts-ignore comment around every usage of the variable. This can be very helpful when you are first migrating a JavaScript project to TypeScript as you can set the type for stuff you haven't migrated yet as any, but in a full TypeScript project you are disabling type checking for any parts of your program that use it.
+In cases where you don't know what type you want to accept, or when you want to accept anything because you will be blindly passing it through without interacting with it, you can use unknown.
+
+9. Strict configuration
+
+The stricter configuration is mandatory. Otherwise, types will be too permissive, and it is what we are trying to avoid as much as possible with Typescript.
+
+{
+  "forceConsistentCasingInFileNames": true,
+  "noImplicitReturns": true,
+  "strict": true,
+  "noUnusedLocals": true,
+}
+
+The most important one here is the strict flag which actually covers four other flags: noImplicitAny, noImplicitThis, alwaysStrict and strictNullChecks.
+
+10. Callback Types - Return Types of Callbacks
+
+Don't use the return type any for callbacks whose value will be ignored:
+/* WRONG */
+function fn(x: () => any) {
+ x();
+}
+
+Do use the return type void for callbacks whose value will be ignored:
+/* OK */
+function fn(x: () => void) {
+ x();
+}
+
+Why: Using void is safer because it prevents you from accidentally using the return value of x in an unchecked way:
+function fn(x: () => void) {
+ var k = x(); // oops! meant to do something else
+ k.doSomething(); // error, but would be OK if the return type had been 'any'
+}
+
+11. Optional Parameters in Callbacks
+
+Don't use optional parameters in callbacks unless you really mean it:
+
+/* WRONG */
+interface Fetcher {
+ getObject(done: (data: unknown, elapsedTime?: number) => void): void;
+}
+
+This has a very specific meaning: the done callback might be invoked with 1 argument or might be invoked with 2 arguments. The author probably intended to say that the callback might not care about the elapsedTime parameter, but there's no need to make the parameter optional to accomplish this — it's always legal to provide a callback that accepts fewer arguments.
+
+Do write callback parameters as non-optional:
+/* OK */
+interface Fetcher {
+ getObject(done: (data: unknown, elapsedTime: number) => void): void;
+}
+
+12. Overloads and Callbacks
+
+Don't write separate overloads that differ only on callback arity:
+
+/* WRONG */
+declare function beforeAll(action: () => void, timeout?: number): void;
+declare function beforeAll(
+ action: (done: DoneFn) => void,
+ timeout?: number
+): void;
+
+Do write a single overload using the maximum arity:
+
+/* OK */
+declare function beforeAll(
+ action: (done: DoneFn) => void,
+ timeout?: number
+): void;
+
+Why: It's always legal for a callback to disregard a parameter, so there's no need for the shorter overload. Providing a shorter callback first allows incorrectly-typed functions to be passed in because they match the first overload.
+
+13. Function Overloads
+
+13.1 Ordering
+
+Don't put more general overloads before more specific overloads:
+/* WRONG */
+declare function fn(x: unknown): unknown;
+declare function fn(x: HTMLElement): number;
+declare function fn(x: HTMLDivElement): string;
+var myElem: HTMLDivElement;
+var x = fn(myElem); // x: unknown, wat?
+
+Do sort overloads by putting the more general signatures after more specific signatures:
+
+/* OK */
+declare function fn(x: HTMLDivElement): string;
+declare function fn(x: HTMLElement): number;
+declare function fn(x: unknown): unknown;
+var myElem: HTMLDivElement;
+var x = fn(myElem); // x: string, :)
+
+Why: TypeScript chooses the first matching overload when resolving function calls. When an earlier overload is "more general" than a later one, the later one is effectively hidden and cannot be called.
+
+13.2 Use Optional Parameters
+
+Don't write several overloads that differ only in trailing parameters:
+
+/* WRONG */
+interface Example {
+ diff(one: string): number;
+ diff(one: string, two: string): number;
+ diff(one: string, two: string, three: boolean): number;
+}
+
+Do use optional parameters whenever possible:
+
+/* OK */
+interface Example {
+ diff(one: string, two?: string, three?: boolean): number;
+}
+
+Note that this collapsing should only occur when all overloads have the same return type.
+
+Why: This is important for two reasons.
+TypeScript resolves signature compatibility by seeing if any signature of the target can be invoked with the arguments of the source, and extraneous arguments are allowed. This code, for example, exposes a bug only when the signature is correctly written using optional parameters:
+function fn(x: (a: string, b: number, c: number) => void) {}
+var x: Example;
+// When written with overloads, OK -- used first overload
+// When written with optionals, correctly an error
+fn(x.diff);
+
+The second reason is when a consumer uses the "strict null checking" feature of TypeScript. 
+
+Because unspecified parameters appear as undefined in JavaScript, it's usually fine to pass an explicit undefined to a function with optional arguments. This code, for example, should be OK under strict nulls:
+var x: Example;
+// When written with overloads, incorrectly an error because of passing 'undefined' to 'string'
+// When written with optionals, correctly OK
+x.diff("something", true ? undefined : "hour");
+
+13. Use Union Types
+
+Don't write overloads that differ by type in only one argument position:
+/* WRONG */
+interface Moment {
+ utcOffset(): number;
+ utcOffset(b: number): Moment;
+ utcOffset(b: string): Moment;
+}
+
+Do use union types whenever possible:
+/* OK */
+interface Moment {
+ utcOffset(): number;
+ utcOffset(b: number | string): Moment;
+}
+Note that we didn't make b optional here because the return types of the signatures differ.
+❔ Why: This is important for people who are "passing through" a value to your function:
+function fn(x: string): Moment;
+function fn(x: number): Moment;
+function fn(x: number | string) {
+ // When written with separate overloads, incorrectly an error
+ // When written with union types, correctly OK
+ return moment().utcOffset(x);
+}
diff --git a/LLM_DEV_PROMPTS/package.json b/LLM_DEV_PROMPTS/package.json
new file mode 100644
index 0000000..dc05cde
--- /dev/null
+++ b/LLM_DEV_PROMPTS/package.json
@@ -0,0 +1,5 @@
+{
+  "devDependencies": {
+    "prettier": "3.8.1"
+  }
+}
diff --git a/frontend/src/pages/subscribe/Subscribe.jsx b/frontend/src/pages/subscribe/Subscribe.jsx
index c7d7dbd..e776894 100644
--- a/frontend/src/pages/subscribe/Subscribe.jsx
+++ b/frontend/src/pages/subscribe/Subscribe.jsx
@@ -11,11 +11,25 @@ import TierPicker from "../../components/TierPicker";
 import "./Subscribe.css";
 
 const STEPS = ["Create Account", "Choose Plan"];
+
 export default function Subscribe() {
   const navigate = useNavigate();
   const [searchParams] = useSearchParams();
   const { currentUser, signup, refreshAccount } = useAuth();
 
+  const queryParameters = new URLSearchParams(window.location.search)
+  const success = queryParameters?.get("payment")
+  const session_id = queryParameters?.get("session_id")
+
+  console.log('success, session_id_________________________------------>', success, session_id)
+
+  function forward(success, session_id) {
+    success && session_id ?
+      navigate('/addresses') : console.log('ewps')
+  }
+
+  setTimeout(forward, 2000, success, session_id);
+
   const [step, setStep] = useState(currentUser ? 2 : 1);
   const [data, setData] = useState({
     email: currentUser?.email || "",