conductor-install 0.0.2 → 0.1.0

package/dist/conductor/conductor/templates/code_styleguides/cpp.md

@@ -1,113 +0,0 @@
-# Google C++ Style Guide Summary
-
-## 1. Naming
-- **General:** Optimize for readability. Be descriptive but concise. Use inclusive language.
-- **Files:** `.h` (headers), `.cc` (source). Lowercase with underscores (`_`) or dashes (`-`). Be consistent.
-- **Types:** PascalCase (`MyClass`, `MyEnum`). Use `int` by default; use `<cstdint>` (`int32_t`) if size matters.
-- **Concepts:** PascalCase (`MyConcept`).
-- **Variables:** snake_case (`my_var`). Class members end with underscore (`my_member_`), struct members do not.
-- **Constants/Enumerators:** `k` + PascalCase (`kDays`, `kOk`).
-- **Template Parameters:** PascalCase for types (`T`, `MyType`), snake_case/kPascalCase for non-types (`N`, `kLimit`).
-- **Functions:** PascalCase (`GetValue()`).
-- **Accessors/Mutators:** snake_case. `count()` (not `GetCount`), `set_count(v)`.
-- **Namespaces:** lowercase (`web_search`).
-- **Macros:** ALL_CAPS (`MY_MACRO`).
-
-## 2. Header Files
-- **General:** Every `.cc` usually has a `.h`. Headers must be self-contained.
-- **Guards:** Use `#define <PROJECT>_<PATH>_<FILE>_H_`.
-- **IWYU:** Direct includes only. Do not rely on transitive includes.
-- **Forward Decls:** Avoid. Include headers instead. **Never** forward declare `std::` symbols.
-- **Inline Definitions:** Only short functions (<10 lines) in headers. Must be ODR-safe (`inline` or templates).
-- **Include Order:**
-  1. Related header (`foo.h`)
-  2. C system (`<unistd.h>`)
-  3. C++ standard (`<vector>`)
-  4. Other libraries (`<Python.h>`)
-  5. Project headers (`"base/logging.h"`)
-  *Separate groups with blank lines. Alphabetical within groups.*
-
-## 3. Formatting
-- **Indentation:** 2 spaces. **Line Length:** 80 chars.
-- **Non-ASCII:** Rare, use UTF-8. Avoid `u8` prefix if possible.
-- **Braces:** `if (cond) { ... }`. **Exception:** Function definition open brace goes on the **next line**.
-- **Switch:** Always include `default`. Use `[[fallthrough]]` for explicit fallthrough.
-- **Literals:** Floating-point must have radix point (`1.0f`).
-- **Calls:** Wrap arguments at paren or 4-space indent.
-- **Init Lists:** Colon on new line, indent 4 spaces.
-- **Namespaces:** No indentation.
-- **Vertical Whitespace:** Use sparingly. Separate related chunks, not code blocks.
-- **Loops/Branching:** Use braces (optional if single line). No space after `(`, space before `{`.
-- **Return:** No parens `return result;`.
-- **Preprocessor:** `#` always at line start.
-- **Pointers:** `char* c` (attached to type).
-- **Templates:** No spaces inside `< >` (`vector<int>`).
-- **Operators:** Space around assignment/binary, no space for unary.
-- **Class Order:** `public`, `protected`, `private`.
-- **Parameter Wrapping:** Wrap parameter lists that don't fit. Use 4-space indent for wrapped parameters.
-
-## 4. Classes
-- **Constructors:** `explicit` for single-arg and conversion operators. **Exception:** `std::initializer_list`. No virtual calls in ctors. Use factories for fallible init.
-- **Structs:** Only for passive data. Prefer `struct` over `std::pair` or `std::tuple`.
-- **Copy/Move:** Explicitly `= default` or `= delete`. **Rule of 5:** If defining one, declare all.
-- **Inheritance:** `public` only. Composition > Inheritance. Use `override` (omit `virtual`). No multiple implementation inheritance.
-- **Operator Overloading:** Judicious use only. Binary ops as non-members. Never overload `&&`, `||`, `,`, or unary `&`. No User-Defined Literals.
-- **Access:** Data members `private` (except structs/constants).
-- **Declaration Order:** `public` before `protected` before `private`. Within sections: Types, Constants, Factory, Constructors, Destructor, Methods, Data Members.
-
-## 5. Functions
-- **Params:** Inputs (`const T&`, `std::string_view`, `std::span` or value) first, then outputs. **Ordering:** Inputs before outputs.
-- **Outputs:** Prefer return values/`std::optional`. For non-optional outputs, use references. For optional outputs, use pointers.
-- **Optional Inputs:** Use `std::optional` for by-value, `const T*` for reference.
-- **Nonmember vs Static:** Prefer nonmember functions in namespaces over static member functions.
-- **Length:** Prefer small (<40 lines).
-- **Overloading:** Use only when behavior is obvious. Document overload sets with a single umbrella comment.
-- **Default Args:** Allowed on non-virtual functions only (value must be fixed/constant).
-- **Trailing Return:** Only when necessary (lambdas).
-
-## 6. Scoping
-- **Namespaces:** No `using namespace`. Use `using std::string`. Never add to `namespace std`.
-- **Internal:** Use anonymous namespaces or `static` in `.cc` files. Avoid in headers.
-- **Locals:** Narrowest scope. Initialize at declaration. **Exception:** Declare complex objects outside loops.
-- **Static/Global:** Must be **trivially destructible** (e.g., `constexpr`, raw pointers, arrays). No global `std::string`, `std::map`, smart pointers. Dynamic initialization allowed only for function-static variables.
-- **Thread Local:** `thread_local` must be `constinit` if global. Prefer `thread_local` over other mechanisms.
-
-## 7. Modern C++ Features
-- **Version:** Target **C++20**. Do not use C++23. Consider portability for C++17/20 features. No non-standard extensions.
-- **Modules:** Do not use C++20 Modules.
-- **Coroutines:** Use approved libraries only. Do not roll your own promise or awaitable types.
-- **Concepts:** Prefer C++20 Concepts (`requires`) over `std::enable_if`. Use `requires(Concept<T>)`, not `template<Concept T>`.
-- **R-Value References:** Use only for move ctors/assignment, perfect forwarding, or consuming `*this`.
-- **Smart Pointers:** `std::unique_ptr` (exclusive), `std::shared_ptr` (shared). No `std::auto_ptr`.
-- **Auto:** Use when type is obvious (`make_unique`, iterators). Avoid for public APIs.
-- **CTAD:** Use only if explicitly supported (deduction guides exist).
-- **Structured Bindings:** Use for pairs/tuples. Comment aliased field names.
-- **Nullptr:** Use `nullptr`, never `NULL` or `0`.
-- **Constexpr:** Use `constexpr`/`consteval` for constants/functions whenever possible. Use `constinit` for static initialization.
-- **Noexcept:** Specify when useful/correct. Prefer unconditional `noexcept` if exceptions are disabled.
-- **Lambdas:** Prefer explicit captures (`[&x]`) if escaping scope. Avoid `std::bind`.
-- **Initialization:** Prefer brace init. **Designated Initializers:** Allowed (C++20 ordered form only).
-- **Casts:** Use C++ casts (`static_cast`). Use `std::bit_cast` for type punning.
-- **Loops:** Prefer range-based `for`.
-
-## 8. Best Practices
-- **Const:** Mark methods/variables `const` whenever possible. `const` methods must be thread-safe.
-- **Exceptions:** **Forbidden**.
-- **RTTI:** Avoid `dynamic_cast`/`typeid`. Allowed in unit tests. Do not hand-implement workarounds.
-- **Macros:** Avoid. Use `constexpr`/`inline`. If needed, define close to use and `#undef` immediately. Do not define in headers.
-- **0 and nullptr:** Use `nullptr` for pointers, `\0` for chars, not `0`.
-- **Streams:** Use streams primarily for logging. Prefer printf-style formatting or absl::StrCat.
-- **Types:** Avoid `unsigned` for non-negativity. No `long double`.
-- **Pre-increment:** Prefer `++i` over `i++`.
-- **Sizeof:** Prefer `sizeof(varname)` over `sizeof(type)`.
-- **Friends:** Allowed, usually defined in the same file.
-- **Boost:** Use only approved libraries (e.g., Call Traits, Compressed Pair, BGL, Property Map, Iterator, etc.).
-- **Aliases:** Use `using` instead of `typedef`. Public aliases must be documented.
-- **Ownership:** Single fixed owner. Transfer via smart pointers.
-- **Aliases:** Document intent. Don't use in public API for convenience. `using` > `typedef`.
-- **Switch:** Always include `default`. Use `[[fallthrough]]` for explicit fallthrough.
-- **Comments:** Document File, Class, Function (params/return). Use `//` or `/* */`. Implementation comments for tricky code. `TODO(user):` format.
-
-**BE CONSISTENT.** Follow existing code style.
-
-*Source: [Google C++ Style Guide](https://google.github.io/styleguide/cppguide.html)*

package/dist/conductor/conductor/templates/code_styleguides/csharp.md

@@ -1,115 +0,0 @@
-# Google C# Style Guide Summary
-
-This document summarizes key rules and best practices from the Google C# Style Guide.
-
-## 1. Naming Conventions
-- **PascalCase:** For class names, method names, constants, properties, namespaces, and public fields.
-  - Example: `MyClass`, `GetValue()`, `MaxValue`
-- **_camelCase:** For private, internal, and protected fields (with leading underscore).
-  - Example: `_myField`, `_internalState`
-- **camelCase:** For local variables and parameters.
-  - Example: `localVariable`, `methodParameter`
-- **Interfaces:** Prefix with `I` (e.g., `IMyInterface`).
-- **Type Parameters:** Use descriptive names prefixed with `T` (e.g., `TValue`, `TKey`), or just `T` for simple cases.
-
-## 2. Formatting Rules
-- **Indentation:** Use 2 spaces (never tabs).
-- **Braces:** K&R style—no line break before the opening brace; keep `} else` on one line; braces required even when optional.
-  ```csharp
-  if (condition) {
-    DoSomething();
-  } else {
-    DoSomethingElse();
-  }
-  ```
-- **Line Length:** Column limit 100.
-- **One Statement Per Line:** Each statement on its own line.
-
-## 3. Declaration Order
-Class member ordering:
-- Group members in this order:
-  1. Nested classes, enums, delegates, and events
-  2. Static, const, and readonly fields
-  3. Fields and properties
-  4. Constructors and finalizers
-  5. Methods
-- Within each group, order by accessibility:
-  1. Public
-  2. Internal
-  3. Protected internal
-  4. Protected
-  5. Private
-- Where possible, group interface implementations together.
-
-## 4. Language Features
-- **var:** Use of `var` is encouraged if it aids readability by avoiding type names that are noisy, obvious, or unimportant. Prefer explicit types when it improves clarity.
-  ```csharp
-  var apple = new Apple();  // Good - type is obvious
-  bool success = true;  // Preferred over var for basic types
-  ```
-- **Expression-bodied Members:** Use sparingly for simple properties and lambdas; don't use on method definitions.
-  ```csharp
-  public int Age => _age;
-  // Methods: prefer block bodies.
-  ```
-- **String Interpolation:** In general, use whatever is easiest to read, particularly for logging and assert messages.
-  - Be aware that chained `operator+` concatenations can be slower and cause memory churn.
-  - If performance is a concern, `StringBuilder` can be faster for multiple concatenations.
-  ```csharp
-  var message = $"Hello, {name}!";
-  ```
-- **Collection Initializers:** Use collection and object initializers when appropriate.
-  ```csharp
-  var list = new List<int> { 1, 2, 3 };
-  ```
-- **Null-conditional Operators:** Use `?.` and `??` to simplify null checks.
-  ```csharp
-  var length = text?.Length ?? 0;
-  ```
-- **Pattern Matching:** Use pattern matching for type checks and casts.
-  ```csharp
-  if (obj is string str) { /* use str */ }
-  ```
-
-## 5. Best Practices
-- **Structs vs Classes**:
-  - Almost always use a class.
-  - Consider structs only for small, value-like types that are short-lived or frequently embedded.
-  - Performance considerations may justify deviations from this guidance.
-- **Access Modifiers:** Always explicitly declare access modifiers (don't rely on defaults).
-- **Ordering Modifiers:** Use standard order: `public protected internal private new abstract virtual override sealed static readonly extern unsafe volatile async`.
-- **Namespace Imports:** Place `using` directives at the top of the file (outside namespaces); `System` first, then alphabetical.
-- **Constants:** Always make variables `const` when possible; if not, use `readonly`. Prefer named constants over magic numbers.
-- **IEnumerable vs IList vs IReadOnlyList:** When method inputs are intended to be immutable, prefer the most restrictive collection type possible (e.g., IEnumerable, IReadOnlyList); for return values, prefer IList when transferring ownership of a mutable collection, and otherwise prefer the most restrictive option.
-- **Array vs List:** Prefer `List<>` for public variables, properties, and return types. Use arrays when size is fixed and known at construction time, or for multidimensional arrays.
-- **Extension Methods:** Only use when the source is unavailable or changing it is infeasible. Only for core, general features. Be aware they obfuscate code.
-- **LINQ:** Use LINQ for readability, but be mindful of performance in hot paths.
-
-## 6. File Organization
-- **One Class Per File:** Typically one class, interface, enum, or struct per file.
-- **File Name:** Prefer the file name to match the name of the primary type it contains.
-- **Folders and File Locations:**
-  - Be consistent within the project.
-  - Prefer a flat folder structure where possible.
-  - Don’t force file/folder layout to match namespaces.
-- **Namespaces:**
-  - In general, namespaces should be no more than 2 levels deep.
-  - For shared library/module code, use namespaces.
-  - For leaf application code, namespaces are not necessary.
-  - New top-level namespace names must be globally unique and recognizable.
-
-## 7. Parameters and Returns
-- **out Parameters:** Permitted for output-only values; place `out` parameters after all other parameters. Prefer tuples or return types when they improve clarity.
-- **Argument Clarity:** When argument meaning is nonobvious, use named constants, replace `bool` with `enum`, use named arguments, or create a configuration class/struct.
-  ```csharp
-  // Bad
-  DecimalNumber product = CalculateProduct(values, 7, false, null);
-  
-  // Good
-  var options = new ProductOptions { PrecisionDecimals = 7, UseCache = CacheUsage.DontUseCache };
-  DecimalNumber product = CalculateProduct(values, options, completionDelegate: null);
-  ```
-
-**BE CONSISTENT.** When editing code, follow the existing style in the codebase.
-
-*Source: [Google C# Style Guide](https://google.github.io/styleguide/csharp-style.html)*

package/dist/conductor/conductor/templates/code_styleguides/dart.md

@@ -1,238 +0,0 @@
-# Dart Code Style Guide
-
-This guide summarizes key recommendations from the official Effective Dart documentation, covering style, documentation, language usage, and API design principles. Adhering to these guidelines promotes consistent, readable, and maintainable Dart code.
-
-## 1. Style
-
-### 1.1. Identifiers
-
-- **DO** name types, extensions, and enum types using `UpperCamelCase`.
-- **DO** name packages, directories, and source files using `lowercase_with_underscores`.
-- **DO** name import prefixes using `lowercase_with_underscores`.
-- **DO** name other identifiers (class members, top-level definitions, variables, parameters) using `lowerCamelCase`.
-- **PREFER** using `lowerCamelCase` for constant names.
-- **DO** capitalize acronyms and abbreviations longer than two letters like words (e.g., `Http`, `Nasa`, `Uri`). Two-letter acronyms (e.g., `ID`, `TV`, `UI`) should remain capitalized.
-- **PREFER** using wildcards (`_`) for unused callback parameters in anonymous and local functions.
-- **DON'T** use a leading underscore for identifiers that aren't private.
-- **DON'T** use prefix letters (e.g., `kDefaultTimeout`).
-- **DON'T** explicitly name libraries using the `library` directive.
-
-### 1.2. Ordering
-
-- **DO** place `dart:` imports before other imports.
-- **DO** place `package:` imports before relative imports.
-- **DO** specify exports in a separate section after all imports.
-- **DO** sort sections alphabetically.
-
-### 1.3. Formatting
-
-- **DO** format your code using `dart format`.
-- **CONSIDER** changing your code to make it more formatter-friendly (e.g., shortening long identifiers, simplifying nested expressions).
-- **PREFER** lines 80 characters or fewer.
-- **DO** use curly braces for all flow control statements (`if`, `for`, `while`, `do`, `try`, `catch`, `finally`).
-
-## 2. Documentation
-
-### 2.1. Comments
-
-- **DO** format comments like sentences (capitalize the first word, end with a period).
-- **DON'T** use block comments (`/* ... */`) for documentation; use `//` for regular comments.
-
-### 2.2. Doc Comments
-
-- **DO** use `///` doc comments to document members and types.
-- **PREFER** writing doc comments for public APIs.
-- **CONSIDER** writing a library-level doc comment.
-- **CONSIDER** writing doc comments for private APIs.
-- **DO** start doc comments with a single-sentence summary.
-- **DO** separate the first sentence of a doc comment into its own paragraph.
-- **AVOID** redundancy with the surrounding context (e.g., don't repeat the class name in its doc comment).
-- **PREFER** starting comments of a function or method with third-person verbs if its main purpose is a side effect (e.g., "Connects to...").
-- **PREFER** starting a non-boolean variable or property comment with a noun phrase (e.g., "The current day...").
-- **PREFER** starting a boolean variable or property comment with "Whether" followed by a noun or gerund phrase (e.g., "Whether the modal is...").
-- **PREFER** a noun phrase or non-imperative verb phrase for a function or method if returning a value is its primary purpose.
-- **DON'T** write documentation for both the getter and setter of a property.
-- **PREFER** starting library or type comments with noun phrases.
-- **CONSIDER** including code samples in doc comments using triple backticks.
-- **DO** use square brackets (`[]`) in doc comments to refer to in-scope identifiers (e.g., `[StateError]`, `[anotherMethod()]`, `[Duration.inDays]`, `[Point.new]`).
-- **DO** use prose to explain parameters, return values, and exceptions.
-- **DO** put doc comments before metadata annotations.
-
-### 2.3. Markdown
-
-- **AVOID** using markdown excessively.
-- **AVOID** using HTML for formatting.
-- **PREFER** backtick fences (```) for code blocks.
-
-### 2.4. Writing
-
-- **PREFER** brevity.
-- **AVOID** abbreviations and acronyms unless they are obvious.
-- **PREFER** using "this" instead of "the" to refer to a member's instance.
-
-## 3. Usage
-
-### 3.1. Libraries
-
-- **DO** use strings in `part of` directives.
-- **DON'T** import libraries that are inside the `src` directory of another package.
-- **DON'T** allow an import path to reach into or out of `lib`.
-- **PREFER** relative import paths when not crossing the `lib` boundary.
-
-### 3.2. Null Safety
-
-- **DON'T** explicitly initialize variables to `null`.
-- **DON'T** use an explicit default value of `null`.
-- **DON'T** use `true` or `false` in equality operations (e.g., `if (nonNullableBool == true)`).
-- **AVOID** `late` variables if you need to check whether they are initialized; prefer nullable types.
-- **CONSIDER** type promotion or null-check patterns for using nullable types.
-
-### 3.3. Strings
-
-- **DO** use adjacent strings to concatenate string literals.
-- **PREFER** using interpolation (`$variable`, `${expression}`) to compose strings and values.
-- **AVOID** using curly braces in interpolation when not needed (e.g., `'$name'` instead of `'${name}'`).
-
-### 3.4. Collections
-
-- **DO** use collection literals (`[]`, `{}`, `<type>{}`) when possible.
-- **DON'T** use `.length` to check if a collection is empty; use `.isEmpty` or `.isNotEmpty`.
-- **AVOID** using `Iterable.forEach()` with a function literal; prefer `for-in` loops.
-- **DON'T** use `List.from()` unless you intend to change the type of the result; prefer `.toList()`.
-- **DO** use `whereType()` to filter a collection by type.
-- **AVOID** using `cast()` when a nearby operation (like `List<T>.from()` or `map<T>()`) will do.
-
-### 3.5. Functions
-
-- **DO** use a function declaration to bind a function to a name.
-- **DON'T** create a lambda when a tear-off will do (e.g., `list.forEach(print)` instead of `list.forEach((e) => print(e))`).
-
-### 3.6. Variables
-
-- **DO** follow a consistent rule for `var` and `final` on local variables (either `final` for non-reassigned and `var` for reassigned, or `var` for all locals).
-- **AVOID** storing what you can calculate (e.g., don't store `area` if you have `radius`).
-
-### 3.7. Members
-
-- **DON'T** wrap a field in a getter and setter unnecessarily.
-- **PREFER** using a `final` field to make a read-only property.
-- **CONSIDER** using `=>` for simple members (getters, setters, single-expression methods).
-- **DON'T** use `this.` except to redirect to a named constructor or to avoid shadowing.
-- **DO** initialize fields at their declaration when possible.
-
-### 3.8. Constructors
-
-- **DO** use initializing formals (`this.field`) when possible.
-- **DON'T** use `late` when a constructor initializer list will do.
-- **DO** use `;` instead of `{}` for empty constructor bodies.
-- **DON'T** use `new`.
-- **DON'T** use `const` redundantly in constant contexts.
-
-### 3.9. Error Handling
-
-- **AVOID** `catch` clauses without `on` clauses.
-- **DON'T** discard errors from `catch` clauses without `on` clauses.
-- **DO** throw objects that implement `Error` only for programmatic errors.
-- **DON'T** explicitly catch `Error` or types that implement it.
-- **DO** use `rethrow` to rethrow a caught exception to preserve the original stack trace.
-
-### 3.10. Asynchrony
-
-- **PREFER** `async`/`await` over using raw `Future`s.
-- **DON'T** use `async` when it has no useful effect.
-- **CONSIDER** using higher-order methods to transform a stream.
-- **AVOID** using `Completer` directly.
-
-## 4. API Design
-
-### 4.1. Names
-
-- **DO** use terms consistently.
-- **AVOID** abbreviations unless more common than the unabbreviated term.
-- **PREFER** putting the most descriptive noun last (e.g., `pageCount`).
-- **CONSIDER** making the code read like a sentence when using the API.
-- **PREFER** a noun phrase for a non-boolean property or variable.
-- **PREFER** a non-imperative verb phrase for a boolean property or variable (e.g., `isEnabled`, `canClose`).
-- **CONSIDER** omitting the verb for a named boolean parameter (e.g., `growable: true`).
-- **PREFER** the "positive" name for a boolean property or variable (e.g., `isConnected` over `isDisconnected`).
-- **PREFER** an imperative verb phrase for a function or method whose main purpose is a side effect (e.g., `list.add()`, `window.refresh()`).
-- **PREFER** a noun phrase or non-imperative verb phrase for a function or method if returning a value is its primary purpose (e.g., `list.elementAt(3)`).
-- **CONSIDER** an imperative verb phrase for a function or method if you want to draw attention to the work it performs (e.g., `database.downloadData()`).
-- **AVOID** starting a method name with `get`.
-- **PREFER** naming a method `to___()` if it copies the object's state to a new object (e.g., `toList()`).
-- **PREFER** naming a method `as___()` if it returns a different representation backed by the original object (e.g., `asMap()`).
-- **AVOID** describing the parameters in the function's or method's name.
-- **DO** follow existing mnemonic conventions when naming type parameters (e.g., `E` for elements, `K`, `V` for map keys/values, `T`, `S`, `U` for general types).
-
-### 4.2. Libraries
-
-- **PREFER** making declarations private (`_`).
-- **CONSIDER** declaring multiple classes in the same library if they logically belong together.
-
-### 4.3. Classes and Mixins
-
-- **AVOID** defining a one-member abstract class when a simple function (`typedef`) will do.
-- **AVOID** defining a class that contains only static members; prefer top-level functions/variables or a library.
-- **AVOID** extending a class that isn't intended to be subclassed.
-- **DO** use class modifiers (e.g., `final`, `interface`, `sealed`) to control if your class can be extended.
-- **AVOID** implementing a class that isn't intended to be an interface.
-- **DO** use class modifiers to control if your class can be an interface.
-- **PREFER** defining a pure mixin or pure class to a `mixin class`.
-
-### 4.4. Constructors
-
-- **CONSIDER** making your constructor `const` if the class supports it (all fields are `final` and initialized in the constructor).
-
-### 4.5. Members
-
-- **PREFER** making fields and top-level variables `final`.
-- **DO** use getters for operations that conceptually access properties (no arguments, returns a result, no user-visible side effects, idempotent).
-- **DO** use setters for operations that conceptually change properties (single argument, no result, changes state, idempotent).
-- **DON'T** define a setter without a corresponding getter.
-- **AVOID** using runtime type tests to fake overloading.
-- **AVOID** public `late final` fields without initializers.
-- **AVOID** returning nullable `Future`, `Stream`, and collection types; prefer empty containers or non-nullable futures of nullable types.
-- **AVOID** returning `this` from methods just to enable a fluent interface; prefer method cascades.
-
-### 4.6. Types
-
-- **DO** type annotate variables without initializers.
-- **DO** type annotate fields and top-level variables if the type isn't obvious.
-- **DON'T** redundantly type annotate initialized local variables.
-- **DO** annotate return types on function declarations.
-- **DO** annotate parameter types on function declarations.
-- **DON'T** annotate inferred parameter types on function expressions.
-- **DON'T** type annotate initializing formals.
-- **DO** write type arguments on generic invocations that aren't inferred.
-- **DON'T** write type arguments on generic invocations that are inferred.
-- **AVOID** writing incomplete generic types.
-- **DO** annotate with `dynamic` instead of letting inference fail silently.
-- **PREFER** signatures in function type annotations.
-- **DON'T** specify a return type for a setter.
-- **DON'T** use the legacy `typedef` syntax.
-- **PREFER** inline function types over `typedef`s.
-- **PREFER** using function type syntax for parameters.
-- **AVOID** using `dynamic` unless you want to disable static checking.
-- **DO** use `Future<void>` as the return type of asynchronous members that do not produce values.
-- **AVOID** using `FutureOr<T>` as a return type.
-
-### 4.7. Parameters
-
-- **AVOID** positional boolean parameters.
-- **AVOID** optional positional parameters if the user may want to omit earlier parameters.
-- **AVOID** mandatory parameters that accept a special "no argument" value.
-- **DO** use inclusive start and exclusive end parameters to accept a range.
-
-### 4.8. Equality
-
-- **DO** override `hashCode` if you override `==`.
-- **DO** make your `==` operator obey the mathematical rules of equality (reflexive, symmetric, transitive, consistent).
-- **AVOID** defining custom equality for mutable classes.
-- **DON'T** make the parameter to `==` nullable.
-
-_Sources:_
-
-- [Effective Dart: Style](https://dart.dev/effective-dart/style)
-- [Effective Dart: Documentation](https://dart.dev/effective-dart/documentation)
-- [Effective Dart: Usage](https://dart.dev/effective-dart/usage)
-- [Effective Dart: Design](https://dart.dev/effective-dart/design)

package/dist/conductor/conductor/templates/code_styleguides/general.md

@@ -1,23 +0,0 @@
-# General Code Style Principles
-
-This document outlines general coding principles that apply across all languages and frameworks used in this project.
-
-## Readability
-- Code should be easy to read and understand by humans.
-- Avoid overly clever or obscure constructs.
-
-## Consistency
-- Follow existing patterns in the codebase.
-- Maintain consistent formatting, naming, and structure.
-
-## Simplicity
-- Prefer simple solutions over complex ones.
-- Break down complex problems into smaller, manageable parts.
-
-## Maintainability
-- Write code that is easy to modify and extend.
-- Minimize dependencies and coupling.
-
-## Documentation
-- Document *why* something is done, not just *what*.
-- Keep documentation up-to-date with code changes.

package/dist/conductor/conductor/templates/code_styleguides/go.md

@@ -1,48 +0,0 @@
-# Effective Go Style Guide Summary
-
-This document summarizes key rules and best practices from the official "Effective Go" guide for writing idiomatic Go code.
-
-## 1. Formatting
-- **`gofmt`:** All Go code **must** be formatted with `gofmt` (or `go fmt`). This is a non-negotiable, automated standard.
-- **Indentation:** Use tabs for indentation (`gofmt` handles this).
-- **Line Length:** Go has no strict line length limit. Let `gofmt` handle line wrapping.
-
-## 2. Naming
-- **`MixedCaps`:** Use `MixedCaps` or `mixedCaps` for multi-word names. Do not use underscores.
-- **Exported vs. Unexported:** Names starting with an uppercase letter are exported (public). Names starting with a lowercase letter are not exported (private).
-- **Package Names:** Short, concise, single-word, lowercase names.
-- **Getters:** Do not name getters with a `Get` prefix. A getter for a field named `owner` should be named `Owner()`.
-- **Interface Names:** One-method interfaces are named by the method name plus an `-er` suffix (e.g., `Reader`, `Writer`).
-
-## 3. Control Structures
-- **`if`:** No parentheses around the condition. Braces are mandatory. Can include an initialization statement (e.g., `if err := file.Chmod(0664); err != nil`).
-- **`for`:** Go's only looping construct. Unifies `for` and `while`. Use `for...range` to iterate over slices, maps, strings, and channels.
-- **`switch`:** More general than in C. Cases do not fall through by default (use `fallthrough` explicitly). Can be used without an expression to function as a cleaner `if-else-if` chain.
-
-## 4. Functions
-- **Multiple Returns:** Functions can return multiple values. This is the standard way to return a result and an error (e.g., `value, err`).
-- **Named Result Parameters:** Return parameters can be named. This can make code clearer and more concise.
-- **`defer`:** Schedules a function call to be run immediately before the function executing `defer` returns. Use it for cleanup tasks like closing files.
-
-## 5. Data
-- **`new` vs. `make`:**
-  - `new(T)`: Allocates memory for a new item of type `T`, zeroes it, and returns a pointer (`*T`).
-  - `make(T, ...)`: Creates and initializes slices, maps, and channels only. Returns an initialized value of type `T` (not a pointer).
-- **Slices:** The preferred way to work with sequences. They are more flexible than arrays.
-- **Maps:** Use the "comma ok" idiom to check for the existence of a key: `value, ok := myMap[key]`.
-
-## 6. Interfaces
-- **Implicit Implementation:** A type implements an interface by implementing its methods. No `implements` keyword is needed.
-- **Small Interfaces:** Prefer many small interfaces over one large one. The standard library is full of single-method interfaces (e.g., `io.Reader`).
-
-## 7. Concurrency
-- **Share Memory By Communicating:** This is the core philosophy. Do not communicate by sharing memory; instead, share memory by communicating.
-- **Goroutines:** Lightweight, concurrently executing functions. Start one with the `go` keyword.
-- **Channels:** Typed conduits for communication between goroutines. Use `make` to create them.
-
-## 8. Errors
-- **`error` type:** The built-in `error` interface is the standard way to handle errors.
-- **Explicit Error Handling:** Do not discard errors with the blank identifier (`_`). Check for errors explicitly.
-- **`panic`:** Reserved for truly exceptional, unrecoverable situations. Generally, libraries should not panic.
-
-*Source: [Effective Go](https://go.dev/doc/effective_go)*

package/dist/conductor/conductor/templates/code_styleguides/html-css.md

@@ -1,49 +0,0 @@
-# Google HTML/CSS Style Guide Summary
-
-This document summarizes key rules and best practices from the Google HTML/CSS Style Guide.
-
-## 1. General Rules
-- **Protocol:** Use HTTPS for all embedded resources.
-- **Indentation:** Indent by 2 spaces. Do not use tabs.
-- **Capitalization:** Use only lowercase for all code (element names, attributes, selectors, properties).
-- **Trailing Whitespace:** Remove all trailing whitespace.
-- **Encoding:** Use UTF-8 (without a BOM). Specify `<meta charset="utf-8">` in HTML.
-
-## 2. HTML Style Rules
-- **Document Type:** Use `<!doctype html>`.
-- **HTML Validity:** Use valid HTML.
-- **Semantics:** Use HTML elements according to their intended purpose (e.g., use `<p>` for paragraphs, not for spacing).
-- **Multimedia Fallback:** Provide `alt` text for images and transcripts/captions for audio/video.
-- **Separation of Concerns:** Strictly separate structure (HTML), presentation (CSS), and behavior (JavaScript). Link to CSS and JS from external files.
-- **`type` Attributes:** Omit `type` attributes for stylesheets (`<link>`) and scripts (`<script>`).
-
-## 3. HTML Formatting Rules
-- **General:** Use a new line for every block, list, or table element, and indent its children.
-- **Quotation Marks:** Use double quotation marks (`""`) for attribute values.
-
-## 4. CSS Style Rules
-- **CSS Validity:** Use valid CSS.
-- **Class Naming:** Use meaningful, generic names. Separate words with a hyphen (`-`).
-  - **Good:** `.video-player`, `.site-navigation`
-  - **Bad:** `.vid`, `.red-text`
-- **ID Selectors:** Avoid using ID selectors for styling. Prefer class selectors.
-- **Shorthand Properties:** Use shorthand properties where possible (e.g., `padding`, `font`).
-- **`0` and Units:** Omit units for `0` values (e.g., `margin: 0;`).
-- **Leading `0`s:** Always include leading `0`s for decimal values (e.g., `font-size: 0.8em;`).
-- **Hexadecimal Notation:** Use 3-character hex notation where possible (e.g., `#fff`).
-- **`!important`:** Avoid using `!important`.
-
-## 5. CSS Formatting Rules
-- **Declaration Order:** Alphabetize declarations within a rule.
-- **Indentation:** Indent all block content.
-- **Semicolons:** Use a semicolon after every declaration.
-- **Spacing:**
-  - Use a space after a property name's colon (`font-weight: bold;`).
-  - Use a space between the last selector and the opening brace (`.foo {`).
-  - Start a new line for each selector and declaration.
-- **Rule Separation:** Separate rules with a new line.
-- **Quotation Marks:** Use single quotes (`''`) for attribute selectors and property values (e.g., `[type='text']`).
-
-**BE CONSISTENT.** When editing code, match the existing style.
-
-*Source: [Google HTML/CSS Style Guide](https://google.github.io/styleguide/htmlcssguide.html)*

package/dist/conductor/conductor/templates/code_styleguides/javascript.md

@@ -1,51 +0,0 @@
-# Google JavaScript Style Guide Summary
-
-This document summarizes key rules and best practices from the Google JavaScript Style Guide.
-
-## 1. Source File Basics
-- **File Naming:** All lowercase, with underscores (`_`) or dashes (`-`). Extension must be `.js`.
-- **File Encoding:** UTF-8.
-- **Whitespace:** Use only ASCII horizontal spaces (0x20). Tabs are forbidden for indentation.
-
-## 2. Source File Structure
-- New files should be ES modules (`import`/`export`).
-- **Exports:** Use named exports (`export {MyClass};`). **Do not use default exports.**
-- **Imports:** Do not use line-wrapped imports. The `.js` extension in import paths is mandatory.
-
-## 3. Formatting
-- **Braces:** Required for all control structures (`if`, `for`, `while`, etc.), even single-line blocks. Use K&R style ("Egyptian brackets").
-- **Indentation:** +2 spaces for each new block.
-- **Semicolons:** Every statement must be terminated with a semicolon.
-- **Column Limit:** 80 characters.
-- **Line-wrapping:** Indent continuation lines at least +4 spaces.
-- **Whitespace:** Use single blank lines between methods. No trailing whitespace.
-
-## 4. Language Features
-- **Variable Declarations:** Use `const` by default, `let` if reassignment is needed. **`var` is forbidden.**
-- **Array Literals:** Use trailing commas. Do not use the `Array` constructor.
-- **Object Literals:** Use trailing commas and shorthand properties. Do not use the `Object` constructor.
-- **Classes:** Do not use JavaScript getter/setter properties (`get name()`). Provide ordinary methods instead.
-- **Functions:** Prefer arrow functions for nested functions to preserve `this` context.
-- **String Literals:** Use single quotes (`'`). Use template literals (`` ` ``) for multi-line strings or complex interpolation.
-- **Control Structures:** Prefer `for-of` loops. `for-in` loops should only be used on dict-style objects.
-- **`this`:** Only use `this` in class constructors, methods, or in arrow functions defined within them.
-- **Equality Checks:** Always use identity operators (`===` / `!==`).
-
-## 5. Disallowed Features
-- `with` keyword.
-- `eval()` or `Function(...string)`.
-- Automatic Semicolon Insertion.
-- Modifying builtin objects (`Array.prototype.foo = ...`).
-
-## 6. Naming
-- **Classes:** `UpperCamelCase`.
-- **Methods & Functions:** `lowerCamelCase`.
-- **Constants:** `CONSTANT_CASE` (all uppercase with underscores).
-- **Non-constant Fields & Variables:** `lowerCamelCase`.
-
-## 7. JSDoc
-- JSDoc is used on all classes, fields, and methods.
-- Use `@param`, `@return`, `@override`, `@deprecated`.
-- Type annotations are enclosed in braces (e.g., `/** @param {string} userName */`).
-
-*Source: [Google JavaScript Style Guide](https://google.github.io/styleguide/jsguide.html)*