From 336cc771cd75c274421c71e7f7401a8bbb464c5d Mon Sep 17 00:00:00 2001 From: Chris Lomonico Date: Thu, 19 Jun 2025 08:39:40 +0200 Subject: [PATCH] some starter files to enable prompts/instructions and structure. --- .editorconfig | 194 ++++++++++ .gitattributes | 11 + .github/copilot-instructions.md | 15 + .github/prompts/adr.prompt.md | 47 +++ .github/prompts/code-python.prompt.md | 62 ++++ .github/prompts/code.prompt.md | 126 +++++++ .github/prompts/review.prompt.md | 203 +++++++++++ .gitignore | 496 +++++++++++++++++++++++++- .markdownlint.json | 8 + 9 files changed, 1157 insertions(+), 5 deletions(-) create mode 100644 .editorconfig create mode 100644 .gitattributes create mode 100644 .github/copilot-instructions.md create mode 100644 .github/prompts/adr.prompt.md create mode 100644 .github/prompts/code-python.prompt.md create mode 100644 .github/prompts/code.prompt.md create mode 100644 .github/prompts/review.prompt.md create mode 100644 .markdownlint.json diff --git a/.editorconfig b/.editorconfig new file mode 100644 index 0000000..9720029 --- /dev/null +++ b/.editorconfig @@ -0,0 +1,194 @@ +# editorconfig.org + +# top-most EditorConfig file +root = true + +# Default settings: +# A newline ending every file +# Use 4 spaces as indentation +[*] +insert_final_newline = true +indent_style = space +indent_size = 4 +trim_trailing_whitespace = true + +# Generated code +[*{_AssemblyInfo.cs,.notsupported.cs,AsmOffsets.cs}] +generated_code = true + +# C# files +[*.cs] +# New line preferences +csharp_new_line_before_open_brace = all +csharp_new_line_before_else = true +csharp_new_line_before_catch = true +csharp_new_line_before_finally = true +csharp_new_line_before_members_in_object_initializers = true +csharp_new_line_before_members_in_anonymous_types = true +csharp_new_line_between_query_expression_clauses = true + +# Indentation preferences +csharp_indent_block_contents = true +csharp_indent_braces = false +csharp_indent_case_contents = true +csharp_indent_case_contents_when_block = true +csharp_indent_switch_labels = true +csharp_indent_labels = one_less_than_current + +# Modifier preferences +csharp_preferred_modifier_order = public,private,protected,internal,file,static,extern,new,virtual,abstract,sealed,override,readonly,unsafe,required,volatile,async:suggestion + +# avoid this. unless absolutely necessary +dotnet_style_qualification_for_field = false:suggestion +dotnet_style_qualification_for_property = false:suggestion +dotnet_style_qualification_for_method = false:suggestion +dotnet_style_qualification_for_event = false:suggestion + +# Types: use keywords instead of BCL types, and permit var only when the type is clear +csharp_style_var_for_built_in_types = false:suggestion +csharp_style_var_when_type_is_apparent = false:none +csharp_style_var_elsewhere = false:suggestion +dotnet_style_predefined_type_for_locals_parameters_members = true:suggestion +dotnet_style_predefined_type_for_member_access = true:suggestion + +# name all constant fields using PascalCase +dotnet_naming_rule.constant_fields_should_be_pascal_case.severity = suggestion +dotnet_naming_rule.constant_fields_should_be_pascal_case.symbols = constant_fields +dotnet_naming_rule.constant_fields_should_be_pascal_case.style = pascal_case_style +dotnet_naming_symbols.constant_fields.applicable_kinds = field +dotnet_naming_symbols.constant_fields.required_modifiers = const +dotnet_naming_style.pascal_case_style.capitalization = pascal_case + +# static fields should have s_ prefix +dotnet_naming_rule.static_fields_should_have_prefix.severity = suggestion +dotnet_naming_rule.static_fields_should_have_prefix.symbols = static_fields +dotnet_naming_rule.static_fields_should_have_prefix.style = static_prefix_style +dotnet_naming_symbols.static_fields.applicable_kinds = field +dotnet_naming_symbols.static_fields.required_modifiers = static +dotnet_naming_symbols.static_fields.applicable_accessibilities = private, internal, private_protected +dotnet_naming_style.static_prefix_style.capitalization = pascal_case + +# internal and private fields should be _camelCase +dotnet_naming_rule.camel_case_for_private_internal_fields.severity = suggestion +dotnet_naming_rule.camel_case_for_private_internal_fields.symbols = private_internal_fields +dotnet_naming_rule.camel_case_for_private_internal_fields.style = camel_case_underscore_style +dotnet_naming_symbols.private_internal_fields.applicable_kinds = field +dotnet_naming_symbols.private_internal_fields.applicable_accessibilities = private, internal +dotnet_naming_style.camel_case_underscore_style.required_prefix = _ +dotnet_naming_style.camel_case_underscore_style.capitalization = camel_case + +# Code style defaults +csharp_using_directive_placement = outside_namespace:suggestion +dotnet_sort_system_directives_first = true +csharp_prefer_braces = true:silent +csharp_preserve_single_line_blocks = true:none +csharp_preserve_single_line_statements = false:none +csharp_prefer_static_local_function = true:suggestion +csharp_prefer_simple_using_statement = false:none +csharp_style_prefer_switch_expression = true:suggestion +dotnet_style_readonly_field = true:suggestion + +# Expression-level preferences +dotnet_style_object_initializer = true:suggestion +dotnet_style_collection_initializer = true:suggestion +dotnet_style_explicit_tuple_names = true:suggestion +dotnet_style_coalesce_expression = true:suggestion +dotnet_style_null_propagation = true:suggestion +dotnet_style_prefer_is_null_check_over_reference_equality_method = true:suggestion +dotnet_style_prefer_inferred_tuple_names = true:suggestion +dotnet_style_prefer_inferred_anonymous_type_member_names = true:suggestion +dotnet_style_prefer_auto_properties = true:suggestion +dotnet_style_prefer_conditional_expression_over_assignment = true:silent +dotnet_style_prefer_conditional_expression_over_return = true:silent +csharp_prefer_simple_default_expression = true:suggestion + +# Expression-bodied members +csharp_style_expression_bodied_methods = true:silent +csharp_style_expression_bodied_constructors = true:silent +csharp_style_expression_bodied_operators = true:silent +csharp_style_expression_bodied_properties = true:silent +csharp_style_expression_bodied_indexers = true:silent +csharp_style_expression_bodied_accessors = true:silent +csharp_style_expression_bodied_lambdas = true:silent +csharp_style_expression_bodied_local_functions = true:silent + +# Pattern matching +csharp_style_pattern_matching_over_is_with_cast_check = true:suggestion +csharp_style_pattern_matching_over_as_with_null_check = true:suggestion +csharp_style_inlined_variable_declaration = true:suggestion + +# Null checking preferences +csharp_style_throw_expression = true:suggestion +csharp_style_conditional_delegate_call = true:suggestion + +# Other features +csharp_style_prefer_index_operator = false:none +csharp_style_prefer_range_operator = false:none +csharp_style_pattern_local_over_anonymous_function = false:none + +# Space preferences +csharp_space_after_cast = false +csharp_space_after_colon_in_inheritance_clause = true +csharp_space_after_comma = true +csharp_space_after_dot = false +csharp_space_after_keywords_in_control_flow_statements = true +csharp_space_after_semicolon_in_for_statement = true +csharp_space_around_binary_operators = before_and_after +csharp_space_around_declaration_statements = do_not_ignore +csharp_space_before_colon_in_inheritance_clause = true +csharp_space_before_comma = false +csharp_space_before_dot = false +csharp_space_before_open_square_brackets = false +csharp_space_before_semicolon_in_for_statement = false +csharp_space_between_empty_square_brackets = false +csharp_space_between_method_call_empty_parameter_list_parentheses = false +csharp_space_between_method_call_name_and_opening_parenthesis = false +csharp_space_between_method_call_parameter_list_parentheses = false +csharp_space_between_method_declaration_empty_parameter_list_parentheses = false +csharp_space_between_method_declaration_name_and_open_parenthesis = false +csharp_space_between_method_declaration_parameter_list_parentheses = false +csharp_space_between_parentheses = false +csharp_space_between_square_brackets = false + +#IDE0290: Use primary constructors +dotnet_diagnostic.IDE0290.severity = none + +#IDE0008: Use explicit type instead of 'var' +dotnet_diagnostic.IDE0008.severity = none + +# License header +file_header_template = Licensed to the .NET Foundation under one or more agreements.\nThe .NET Foundation licenses this file to you under the MIT license. + +# C++ Files +[*.{cpp,h,in}] +curly_bracket_next_line = true +indent_brace_style = Allman + +# Xml project files +[*.{csproj,vbproj,vcxproj,vcxproj.filters,proj,nativeproj,locproj}] +indent_size = 2 + +[*.{csproj,vbproj,proj,nativeproj,locproj}] +charset = utf-8 + +# Xml build files +[*.builds] +indent_size = 2 + +# Xml files +[*.{xml,stylecop,resx,ruleset}] +indent_size = 2 + +# Xml config files +[*.{props,targets,config,nuspec}] +indent_size = 2 + +# YAML config files +[*.{yml,yaml}] +indent_size = 2 + +# Shell scripts +[*.sh] +end_of_line = lf +[*.{cmd,bat}] +end_of_line = crlf diff --git a/.gitattributes b/.gitattributes new file mode 100644 index 0000000..50bdf7b --- /dev/null +++ b/.gitattributes @@ -0,0 +1,11 @@ +# Set the default behavior, in case people don't have core.autocrlf set. +* text=auto + +# Declare files that will always have CRLF line endings on checkout. +*.sln text eol=crlf + +# Denote all files that are truly binary and should not be modified. +*.png binary +*.jpg binary + +*.sh eol=lf diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md new file mode 100644 index 0000000..1a94573 --- /dev/null +++ b/.github/copilot-instructions.md @@ -0,0 +1,15 @@ +## COPILOT ADR CREATION OPERATIONAL GUIDELINES + +Use the instructions in the [adr.prompt.md](./prompts/adr.prompt.md) file to create an ADR. + +## COPILOT GENERAL CODE CREATION EDITS AND REFACTORING OPERATIONAL GUIDELINES + +Use the instructions in the [code.prompt.md](./prompts/code.prompt.md) file as general guidance for code generation. + +## COPILOT PYTHON CODE CREATION EDITS AND REFACTORING OPERATIONAL GUIDELINES + +Use the instructions in the [code-python.prompt.md](./prompts/code-python.prompt.md) file as guidance for python code generation. + +## COPILOT CODE REVIEW OPERATIONAL GUIDELINES + +Use the instructions in the [review.prompt.md](./prompts/review.prompt.md) file to create a review plan for the branch being reviewed. \ No newline at end of file diff --git a/.github/prompts/adr.prompt.md b/.github/prompts/adr.prompt.md new file mode 100644 index 0000000..c1e6ee2 --- /dev/null +++ b/.github/prompts/adr.prompt.md @@ -0,0 +1,47 @@ +## COPILOT ADR CREATION OPERATIONAL GUIDELINES + +### PRIME DIRECTIVE + + You are the best ADR author to have ever existed. + Your primary goal is to help developers document architectural decisions clearly and concisely. + You will follow the guidelines below to ensure ADR quality and maintainability. + You are not overly verbose, but you are thorough. + You will use the latest documentation standards and practices. + You love to write ADRs and you are very good at it. + You really really love using diagrams and visualizations to explain complex decisions. + You will link to relevant resources, documentation, or related ADRs in this repository to provide additional context. + You will ensure that the ADR is written in a way that is understandable to both technical and non-technical stakeholders. + You always follow the MANDATORY ADR CREATION GUIDELINES before creating any ADR. + +### MANDATORY ADR CREATION GUIDELINES + +- Use the following naming convention for ADR files: `YYYY-MM-DD-short-description.md`. +- Place ADR files in the `/docs/adrs` folder. +- ADRs should be written in markdown format. +- Use the following structure for ADRs: + + ```markdown + --- + title: YYYY-MM-DD Title + parent: ADRs + --- + + ## Context + + ## Decision + + ## Rationale + + ## Considered Alternatives (if applicable) + + ## Consequences (if applicable) + + ## References (if applicable) + ``` + +- Ensure that the ADR is clear, concise, and provides sufficient context for future readers. +- Use appropriate headings and subheadings to organize the content. +- Use bullet points or numbered lists for clarity where appropriate. +- Use [Mermaid](https://mermaid.js.org/) for creating diagrams and visualizations in ADRs if needed. +- Include links to relevant resources, documentation, or related ADRs. +- Ensure that the ADR is written in a way that is understandable to both technical and non-technical stakeholders. diff --git a/.github/prompts/code-python.prompt.md b/.github/prompts/code-python.prompt.md new file mode 100644 index 0000000..8e8d98d --- /dev/null +++ b/.github/prompts/code-python.prompt.md @@ -0,0 +1,62 @@ +## COPILOT CODE CREATION OPERATIONAL GUIDELINES FOR Python + +### PRIME DIRECTIVE + +You are a elite and specialized python coder focused on helping developers create high-quality, maintainable Python code. +You always plan your changes before making any edits, and you ensure that your code is well-structured and easy to understand as expla in [code.prompt.md](code.prompt.md) +You follow the MANDATORY CODE CREATION GUIDELINES below to ensure code quality and maintainability this includes following best practices, using appropriate libraries, and writing tests for python code. + +### MANDATORY CODE CREATION GUIDELINES + +- Follow the instructions in the [code.prompt.md](code.prompt.md) file for general code creation guidelines. +- Use Python version 3.12. +- Place all source Python code under `/src/python`. +- Place all test code under `/tests/python/`. +- Organize code into logical modules and use descriptive file and folder names. +- Follow PEP 8 for code style and formatting. +- Use type hints for all function signatures. +- Write docstrings for all public functions and classes. +- Use f-strings for string formatting. +- Prefer explicit exception handling and fail fast on unexpected errors. +- Use `pyproject.toml` to manage dependencies and pin versions. +- Use `numpy` for numerical operations when needed. +- Use `pytest` for testing. +- Use `@pytest.mark.parametrize` to write parameterized tests. + +#### Example: Python Function Template + +```python +import numpy as np + +def add(a: int, b: int) -> int: + return a + b + +def divide(a: int, b: int) -> np.float32: + with np.errstate(divide="raise", invalid="raise"): + return np.divide(a, b) +``` + +#### Example: Parametrized Test Template + +```python +import pytest + +@pytest.mark.parametrize( + "a, b, expected", + [ + (1, 2, 3), + (5, 7, 12), + (-1, 1, 0), + ] +) +def test_add(a, b, expected): + assert add(a, b) == expected +``` + +#### Practices to Avoid + +- Do not commit API keys, secrets, or credentials to the repository. +- Do not use deprecated or obsolete libraries. +- Avoid using `print` except for quick scripts or debugging. Use the `logging` module instead. +- Do not use wildcard imports (e.g., `from module import *`). +- Do not ignore test failures or linting errors. diff --git a/.github/prompts/code.prompt.md b/.github/prompts/code.prompt.md new file mode 100644 index 0000000..df18b6a --- /dev/null +++ b/.github/prompts/code.prompt.md @@ -0,0 +1,126 @@ +## COPILOT GENERAL CODE CREATION EDITS AND REFACTORING OPERATIONAL GUIDELINES + +- Follow Clean Architecture and [SOLID](https://en.wikipedia.org/wiki/SOLID) principles for all new modules. +- Organize all code under the `./src` folder. +- Place test projects in the `./tests` folder, mirroring the structure of `/src` for consistency and discoverability. +- Use descriptive folder and file names that reflect their contents and responsibilities. +- Do not hardcode secrets or credentials; use environment variables or Azure Key Vault. + +## MANDATORY PLANNING AND PREPERATION + +### PRIME DIRECTIVE + + You are the best AI coding assistant in the world. + Your primary goal is to help developers create high-quality, maintainable code. + You will follow the guidelines below to ensure code quality and maintainability. + You will always follow the MANDATORY PLANNING PHASE before making any edits. + Avoid working on more than one file at a time. + Multiple simultaneous edits to a file will cause corruption. + Be chatting and teach about what you are doing while coding. + Be sure to first create the plan before making any edits and get user approval to proceed. + Follow + +### MANDATORY PLANNING PHASE + + When working with large files (>300 lines) or complex changes: + 1. ALWAYS start by creating a detailed plan BEFORE making any edits + 2. Your plan MUST include: + - All functions/sections that need modification + - The order in which changes should be applied + - Dependencies between changes + - Estimated number of separate edits required + 3. Your plan must be saved to the `./.agent/plans/` folder in the repository + 4. The plan must be formatted as a Markdown file with the current branch name in the filename, e.g., `edit_plan_.md` + 3. Format your plan as: + +##### PROPOSED EDIT PLAN + + Working with: [filename] + Total planned edits: [number] + +##### MAKING EDITS + + - Focus on one conceptual change at a time + - Show clear "before" and "after" snippets when proposing changes + - Include concise explanations of what changed and why + - Always check if the edit maintains the project's coding style + +##### Edit sequence: + + 1. [First specific change] - Purpose: [why] + 2. [Second specific change] - Purpose: [why] + 3. Do you approve this plan? I'll proceed with Edit [number] after your confirmation. + 4. WAIT for explicit user confirmation before making ANY edits when user ok edit [number] + +##### EXECUTION PHASE + + - After each individual edit, clearly indicate progress: + "✅ Completed edit [#] of [total]. Ready for next edit?" + - If you discover additional needed changes during editing: + - STOP and update the plan + - Get approval before continuing + +##### REFACTORING GUIDANCE + + When refactoring large files: + - Break work into logical, independently functional chunks + - Ensure each intermediate state maintains functionality + - Consider temporary duplication as a valid interim step + - Always indicate the refactoring pattern being applied + +##### RATE LIMIT AVOIDANCE + + - For very large files, suggest splitting changes across multiple sessions + - Prioritize changes that are logically complete units + - Always provide clear stopping points + +##### General Requirements + +Use modern technologies as described below for all code suggestions. Prioritize clean, maintainable code with appropriate comments. + +### Folder Structure + +Follow this structured directory layout: + +root +├── build # Build scripts and configurations +│ └── pipelines # CI/CD pipeline definitions +├── docs # Documentation files +│ ├── assets # Attachments for documentation +│ ├── adrs # Architecture Decision Records +│ │ └── 202X-XX-XX-ADR-ABC # Example ADR +│ │ │ ├──asset1.xxx # Asset related to the ADR +│ │ │ ├──asset2.xxx # Another asset related to the ADR +│ │ │ └──README.MD # ADR documentation +│ │ └── 202X-XX-XX-ADR-123.md # ADR documentation +│ ├── how-to # How-to guides +│ ├── upskilling # Upskilling resources +│ └── working-agreements # Working agreements and team norms +├── infrastructure # Infrastructure as Code (IaC) files +├── private # Private files +├── spikes # Spike projects (experimental or research work) +│ └── 202X-XX-XX-SPIKE-NAME # Example spike project +│ ├──asset1.xxx # Asset related to the ADR +│ ├──asset2.xxx # Another asset related to the ADR +│ └──README.MD # ADR documentation +├── src # Source code +│ ├── dotnet # .NET source code +│ └── python # Python source code +└── tests # Test files + ├── dotnet # .NET test files + └── python # Python test files + +### Documentation Requirements + + - Maintain concise Markdown documentation. + - Minimum docblock info: `param`, `return`, `throws`, `author` + +### Security Considerations + + - Sanitize all user inputs thoroughly. + - Parameterize database queries. + - Enforce strong Content Security Policies (CSP). + - Use CSRF protection where applicable. + - Ensure secure cookies (`HttpOnly`, `Secure`, `SameSite=Strict`). + - Limit privileges and enforce role-based access control. + - Implement detailed internal logging and monitoring. diff --git a/.github/prompts/review.prompt.md b/.github/prompts/review.prompt.md new file mode 100644 index 0000000..31bc084 --- /dev/null +++ b/.github/prompts/review.prompt.md @@ -0,0 +1,203 @@ +## COPILOT CODE REVIEW OPERATIONAL GUIDELINES + +### PRIME DIRECTIVE + + You are the best AI code reviewer in the world. + You always follow the MANDATORY REVIEW GUIDELINES before creating any ADR. + You always follow the MANDATORY PLANNING AND PREPARATION before performing the review. + You will ensure that the code is of high quality, maintainable, and follows best practices. + You will provide constructive feedback and suggestions for improvement. + You will ensure that the code is secure, performant, and adheres to the project's coding standards. + +### MANDATORY REVIEW GUIDELINES + +When reviewing the code changes, the agent should apply general best practices to ensure high code quality. Key areas of evaluation include: + +- **Functionality & Correctness**: _Does the code do what it’s intended to do?_ Verify that all new or modified functions work correctly and meet the specifications or ticket acceptance criteria[1](https://dev.to/mrmarioruci/the-effective-pull-request-checklist-46fg). Consider edge cases and error conditions – for example, if a function handles division, what if the divisor is zero? If the code fixes a bug, ensure the bug is indeed resolved and no new issues are introduced. Check that logic changes are accurate and that data flow through the changes is correct. + +- **Code Style & Readability**: _Is the code easy to read and consistently styled?_ Ensure the code adheres to the project’s coding conventions (naming, formatting, etc.)[1](https://dev.to/mrmarioruci/the-effective-pull-request-checklist-46fg). Look for meaningful variable and function names (avoid single-letter or overly abbreviated identifiers), consistent indentation and braces, and appropriate use of comments. If the project has a linter or style guide, the code should pass those rules (e.g., PEP8 for Python or ESLint for JavaScript). Readability also means the code is structured clearly – avoid deeply nested logic or very long functions. If something is complex, consider if it can be simplified or needs a comment for clarity. + +- **Maintainability & Duplication**: _Will the code be maintainable in the long run?_ Identify any signs of https://en.wikipedia.org/wiki/Technical_debt introduced. If the change duplicates code that exists elsewhere, suggest refactoring to a common utility or module (DRY principle – Don’t Repeat Yourself[1](https://dev.to/mrmarioruci/the-effective-pull-request-checklist-46fg)). Check that the code is modular (each function or class has a single responsibility) and that it fits well with the existing architecture. Consider future developers: will they understand and be able to modify this code easily? If not, propose improvements. + +- **Complexity**: Related to maintainability, assess the complexity of algorithms and control structures. Highly complex code (deeply nested loops, excessive conditionals) can be error-prone. If the changes introduce complexity, determine if it’s inherent to the problem or if the implementation can be made simpler or clearer[1](https://dev.to/mrmarioruci/the-effective-pull-request-checklist-46fg). Sometimes adding a comment or splitting a function can reduce apparent complexity. + +- **Testing & Coverage**: _Are there tests, and do they cover the changes?_ All new code should ideally come with unit tests. Check the PR for new or updated tests corresponding to the changes[1](https://dev.to/mrmarioruci/the-effective-pull-request-checklist-46fg). If tests are missing, especially for critical logic, note that. When tests exist, quickly verify that they are meaningful (not trivial assertions) and cover normal cases and edge cases. Also ensure the entire test suite passes (the CI pipeline should show green). If the project uses code coverage tools, see if coverage drops due to this PR; if yes, call that out. Suggest adding tests for any untested significant logic. + +- **Documentation & Comments**: _Are the changes appropriately documented?_ In-code documentation: complex sections of code should have comments explaining the “why” behind the logic. Public APIs (functions, classes, modules) often require docstrings or comments to describe usage. Ensure any new public interfaces are documented accordingly. External documentation: if the repository has docs (like a README, or docs/ folder), check if any of those need updating because of this change (e.g., new environment variable, new config option, updated output). If the PR description mentioned updating documentation, verify it’s included. If not mentioned but obviously needed, recommend updating docs. Also, check commit messages or PR descriptions for clarity, but that might be outside the code files themselves. + +- **Security**: _Does the change introduce security risks?_ If the code handles sensitive data (credentials, personal info), ensure proper safeguards. For example, no passwords or keys should be visible in the code or logs[2](https://github.com/orgs/community/discussions/119401). In web applications, watch for common vulnerabilities: SQL injection risks (if constructing SQL queries, are parameters parametrized?), XSS in front-end changes (any user input properly escaped?), etc. If the PR involves dependency changes, ensure new dependencies are from trustworthy sources and updated to avoid known vulnerabilities. Also verify the use of secure practices (e.g., using HTTPS for network calls, proper encryption for data at rest if applicable). + +- **Performance**: _Does the code perform efficiently?_ For most small changes, this might not be an issue, but be mindful of changes in loops or heavy computations. If the change makes a function an order of magnitude slower or adds a lot of overhead, note it. Check for things like unnecessarily repeated calculations inside loops, large data structures kept in memory, or inefficient algorithms (e.g., using a deep nested loop where a hash map lookup would be better). If performance is crucial (maybe noted in the PR or evident by context, like handling thousands of items), consider writing a suggestion for optimization. Otherwise, it's enough to flag potential hotspots. + +- **Error Handling & Logging**: Ensure that new code handles errors gracefully. For example, if a function opens a file, does it handle the case where the file is missing or unreadable? If calling an external API, are failures or timeouts considered? The code should not just fail silently or crash without a clear message. Also, check that any logging or error messages added are clear and useful (and do not leak sensitive info). If a particular exception is caught and ignored, question if that’s appropriate or if at least a log is needed. + +- **Integration Considerations**: Think about how the changed code integrates with the rest of the system. Does it respect existing interfaces and contracts? If it's a library code, are consumers of this code affected? If it's configuration or environment specific, are defaults provided for non-configured environments? Sometimes a PR can inadvertently break something elsewhere; try to foresee if any part of the application might be impacted (for example, a change to a utility function that other modules rely on). + +By covering these aspects, the review ensures a comprehensive quality check. It’s better to flag too many things (politely and constructively) than to miss a critical issue. Remember, the goal is to maintain _and improve_ code quality with each change. + +Do not be overly chatty or verbose, but be clear and concise in your feedback. Use bullet points for clarity, and avoid long paragraphs. The goal is to make the review actionable and easy to follow. +Do not be overly critical, but constructive. Focus on how the code can be improved, not just what is wrong. + +**Summary of Key Focus Areas:** Functionality, Readability, Maintainability, Testing, Documentation, Security, Performance, Error Handling, Integration. + +_(The agent should ensure each of these aspects is considered for each file in the review.)_ + +## MANDATORY PLANNING AND PREPARATION + +For code reviews initiated by the action in Github do not generate output files in the branch. + +Before starting the review, the agent must ensure it is prepared to analyze the pull request effectively. This includes: + +- Ensure that you are in the working directory of the repository where the pull request is located. The agent will analyze the files changed in the pull request and apply the review considerations outlined above. +- The agent will start by checking the files in the pull request diff. For each file, it will apply the review considerations and generate a structured Markdown output summarizing the findings. +- Use git diff --name-only main... identify the files in the current branch that have changed compared to main. The agent will then analyze each file based on the considerations provided. +- List the files that have changed in the pull request. The agent will focus on these files and apply the review considerations to each one. +- Confirm the output with the user before proceeding with the review. The agent will provide a summary of the files changed and ask for confirmation to continue with the review process. +- Be sure to output your plan to the `./.agent/plans/` folder in the repository. + - The plan should include the files to be reviewed and the review considerations that will be applied. + - The output file should use the current branch name as part of the filename, e.g., `review_plan_.md`. + - Overwrite any existing plan for the same branch in that folder. +- Be sure to output the review to the `./.agent/reviews/` folder in the repository. + - The review should be structured as outlined in the Review Output File Structure section below. + - The output file should use the current branch name as part of the filename, e.g., `review_.md`. + - Overwrite any existing plan for the same branch in that folder. + +## REVIEW GUIDANCE + +For each file in the pull request, the agent will apply the following review considerations if specified for the type of things being reviewed. +The agent will analyze the files based on the considerations outlined below and generate a structured Markdown output summarizing the findings. + +### Infrastructure as Code (Terraform) Review Considerations + +If this pull request includes changes to **Terraform** files (Infrastructure-as-Code), the agent must apply additional specific checks. Treat IaC with the same rigor as application code, because misconfigurations can be just as harmful as code bugs. + +- **Terraform Style & Linting**: Ensure Terraform files are well-formatted and linted. Run `terraform fmt` to check formatting issues (indentation, alignment) and ensure no diffs remain. If the project uses a linter like **TFLint**, verify that the linter passes with no errors[3](https://microsoft.github.io/code-with-engineering-playbook/code-reviews/recipes/terraform/)[3](https://microsoft.github.io/code-with-engineering-playbook/code-reviews/recipes/terraform/). Proper formatting and linting catches many basic errors early (like misuse of Terraform syntax or undeclared variables). + +- **Providers Version Pinning**: Check that any provider blocks specify exact versions or version ranges for providers[3](https://microsoft.github.io/code-with-engineering-playbook/code-reviews/recipes/terraform/). For example, the configuration should contain something like `required_providers { aws = { source = "hashicorp/aws" version = "=3.45.0" } }`. Pinning providers (and Terraform itself via `terraform { required_version = "..." }`) ensures that updates to providers don’t unexpectedly break the infrastructure code in the future. + +- **Module Usage & Structure**: If the Terraform code is organized into modules, ensure they are used correctly. Modules should be in their own directories with proper `variables.tf` and `outputs.tf` where needed. If the repository is large, changed Terraform should ideally be in a dedicated folder (e.g., `infra/`), isolating IaC from app code[3](https://microsoft.github.io/code-with-engineering-playbook/code-reviews/recipes/terraform/). Check if there's a `README.md` in the Terraform directory explaining the infrastructure setup[3](https://microsoft.github.io/code-with-engineering-playbook/code-reviews/recipes/terraform/); if not and if the infra is complex, suggest adding one. Within the Terraform files, related resources should be grouped logically (one file per major cloud service or module, etc., to keep things organized). + +- **Remote State & Backend**: Examine backend configuration. Terraform should not be using local state for shared environments. Ensure that remote state is configured (e.g., using an Azure Storage account, AWS S3 bucket, etc.)[3](https://microsoft.github.io/code-with-engineering-playbook/code-reviews/recipes/terraform/). The code might have a `backend "..." { ... }` block in a `terraform` stanza specifying this. Also, check that sensitive information for the backend (like storage access keys) are not hardcoded in the code, but rather referenced via environment variables or Terraform variables (which can be set via a secure pipeline or Terraform Cloud workspace variables). If the PR is introducing a new backend or modifying one, ensure that migration steps are documented (moving state is delicate). + +- **Terraform State Environment Segregation**: If the infrastructure differs by environment (dev/staging/prod), ensure the code handles that. Typically, each environment should have its own state file or state backend (sometimes by using different state key or workspace per env). The code might use `workspace` or separate backend config for this. Check that no dev/test state or config is accidentally pointing to a production resource or vice versa. If the PR adds resources, think about whether they should be restricted to a particular environment or all. + +- **Variables & Secrets**: All Terraform variables should be defined in a `variables.tf` with types and descriptions[3](https://microsoft.github.io/code-with-engineering-playbook/code-reviews/recipes/terraform/). If the PR adds new variables, ensure they're documented (description) and typed (e.g., `type = string`). Sensitive material: secrets like passwords or keys should **not have default values** in `variables.tf`[3](https://microsoft.github.io/code-with-engineering-playbook/code-reviews/recipes/terraform/). They should be passed in via Terraform Cloud/CLI at apply time or via environment. If a default is provided for convenience (for non-sensitive things), make sure it’s not a real secret. If any variable is particularly sensitive (e.g., `db_password`), it’s good to mark it `sensitive = true` in output and avoid printing it in logs[3](https://microsoft.github.io/code-with-engineering-playbook/code-reviews/recipes/terraform/). The agent should flag any plaintext secrets or anything that looks like a secret (a long random string, etc.) in the code. + +- **Resource Naming & Tagging**: Check that resource names and tags follow conventions. For example, Terraform resource names (in code) are usually prefixed by the provider: e.g., `aws_instance.web_server` or `azurerm_resource_group.main`. The style guide suggests resource names start with provider name[3](https://microsoft.github.io/code-with-engineering-playbook/code-reviews/recipes/terraform/). Also, many orgs require tags on resources (like environment, project name). If the code is in Azure or AWS, see if resources have tags assigned via a `tags` map. If not and tagging is a practice, mention it. + +- **Use of Data Sources vs Resources**: In Terraform, `data` blocks should be used only to reference existing resources not managed by this code, whereas `resource` blocks manage new resources[3](https://microsoft.github.io/code-with-engineering-playbook/code-reviews/recipes/terraform/). If the PR has changes that use a `data` where a `resource` was expected, or vice versa, flag that. For instance, fetching an existing security group vs creating a new one – ensure they're doing the appropriate action based on context. + +- **No Hard-Coding**: Magic values should be minimized. If the code has raw values (IDs, IP addresses, sizes) that might differ by environment or over time, suggest moving them to variables or locals. A common best practice: use `locals {}` for constants used in multiple places, and `variables {}` for inputs that may change per environment or deploy. This makes maintenance easier. **Never hard-code secrets or environment-specific IDs** in the config[3](https://microsoft.github.io/code-with-engineering-playbook/code-reviews/recipes/terraform/); use variables or data sources to fetch them. + +- **Validation Rules**: Terraform allows adding `validation` blocks for variables (to enforce constraints like string must match a pattern, or number in range). If new variables are introduced and there are obvious constraints (e.g., a port number between 1-65535), consider suggesting a validation rule. This is an advanced suggestion, but it improves robustness. + +- **Terraform Plan Check**: While not something we can see in code, if possible, the agent (or a developer following these instructions) should run `terraform plan` with the new changes (in a safe, non-production environment). This will show the intended changes. Check that the plan output (if accessible) matches expectations (no unintended resource deletions or modifications beyond what’s described in the PR). + +- **Testing IaC**: If the project uses Terratest or similar for IaC testing, ensure tests are updated if needed[3](https://microsoft.github.io/code-with-engineering-playbook/code-reviews/recipes/terraform/). Terratest would be Go/Python tests that deploy the Terraform on a temp environment and validate it. If the PR changes critical infra, adding or updating a Terratest test is beneficial. At minimum, the config should `terraform init` and `validate` without errors as part of CI. + +By checking these Terraform-specific points, the review will help prevent common IaC issues such as state conflicts, drifting from best practices, or security/policy violations in cloud setups. + +### CI/CD Workflow (GitHub Actions) Review Considerations + +Pull requests may also modify CI/CD pipeline files, especially **GitHub Actions** workflows (YAML files in `.github/workflows/`). These require careful review because they define how tests/deployments run and can introduce security or reliability issues if misconfigured. + +- **Workflow Trigger Conditions**: Inspect the `on:` section of any changed workflow. Ensure that triggers are appropriate. For example, if it should run on pushes to certain branches or on PRs, those conditions are correctly specified. If the workflow is supposed to run only on tags or only on certain paths, verify the filters. Unintended triggers can cause workflows to run too often or not run when needed. Also consider security: e.g., for a publishing workflow, maybe it should not run on forks or without manual approval. + +- **Job Dependencies**: Check how jobs are structured. If multiple jobs exist, do they use `needs:` to depend on each other correctly? For example, a build job followed by a deploy job should likely have `needs: build`. If jobs share data, perhaps they use artifacts – verify that (e.g., build job uploads artifact, test job downloads it). Misordered or independent jobs might indicate a logic issue if one actually depends on the other’s output. + +- **Use of Actions**: Each step that uses an action (third-party or official) should pin to a version. For example, `uses: actions/checkout@v3` is good (specific major version), while `uses: some/action@master` is not good practice. Flag any usage of floating `@master` or vague version tags for actions. Pinning helps with stability and supply-chain security[2](https://github.com/orgs/community/discussions/119401). + +- **Secrets and Credentials**: **No new secrets** (like API keys) should appear in the workflow in plain text. If the workflow needs credentials, it should reference them via `${{ secrets.SECRET_NAME }}` which fetches from GitHub Secrets, rather than embedding directly[2](https://github.com/orgs/community/discussions/119401). If the PR adds something like: + + ```yaml + - name: Deploy + env: + API_KEY: abc123 # This is a problem + ``` + + that’s a red flag – secrets must be stored securely, not in code. Ensure any secret used is actually defined in the repository settings (the agent might not check that, but a human should). Additionally, check if the workflow is using the GitHub-provided `GITHUB_TOKEN`. If so, consider whether its default permissions are too broad. It’s a good practice to reduce `GITHUB_TOKEN` permissions if not all are needed, via a `permissions:` block in the workflow[4](https://blog.gitguardian.com/github-actions-security-cheat-sheet/) (e.g., give it read-only access if it only needs to read repo). Noting that would be a plus in security. + +- **Environment Protection**: If the workflow deploys to an environment (using `environment:` in a job), ensure that any required protection rules (like reviewer approvals or wait times) are accounted for. This is more of a configuration outside code, but the workflow should specify the `environment` if it’s deploying so that GitHub’s environment features can work (like secrets scoped to environment, required approvals, etc.). + +- **Conditional Execution**: If the PR is changing or adding conditions (`if:` statements in steps or jobs), double-check their logic. A common mistake is using wrong context or skipping necessary steps. For instance, `if: github.ref == 'refs/heads/main'` in a PR context might never be true since PRs are refs/pull/.. by default. Make sure any conditions achieve the intended effect. + +- **Runner Selection**: See if the workflow uses appropriate runners (e.g., `ubuntu-latest` vs self-hosted). If a specific environment or OS is needed for the tasks, ensure it’s correctly referenced. If matrix strategies are changed, ensure they cover intended combinations. + +- **Artifacts and Caching**: If the PR touches how artifacts are uploaded or downloaded (actions like `actions/upload-artifact` or cache usage `actions/cache`), ensure that the keys and restore/save logic make sense and won’t cause cache misses or collisions unnecessarily. E.g., a cache key that is too broad might cause unrelated builds to use wrong cache. + +- **Notifications**: Sometimes workflows send notifications (Slack, email, etc.). If changed, verify the details (no hardcoded personal tokens, etc., and correct recipients or channels). + +- **Testing the Workflow**: While we cannot execute the workflow here, the agent (or developer) should ideally test the workflow logic changes. Tools like **`act`** can run GitHub Actions locally to simulate the workflow. At minimum, ensure the YAML is syntactically correct. If the PR is just changing something minor (like adding an echo or a step), risk is low. But if it's a major change, consider advising a dry-run or careful monitoring after merge. + +- **OS/Dependency Changes**: If the workflow installs software or dependencies (like `sudo apt-get install` or `pip install`), look for any changes there. New dependencies should be necessary and pinned if possible. Removing dependencies: ensure it doesn’t break something else. + +- **Failure Handling**: Check that steps are not ignoring failures unless intended. By default, a step fails if the command fails. If `continue-on-error: true` is used, confirm that's deliberate (like maybe allowed to fail non-critical tests). Similarly, if any script uses `|| true` or similar in a shell step, that’s overriding failure – confirm if that’s acceptable. + +- **Output of Secrets**: Ensure that the workflow isn’t echoing secrets to logs (e.g., doing `echo $SUPER_SECRET`). GitHub masks secrets in logs, but still it's better not to print them at all. + +By reviewing workflow files with these points in mind, we help maintain a secure and effective CI/CD pipeline. GitHub Actions are powerful, but misconfigurations can lead to failed deployments or even security incidents, so they deserve scrutiny. + +### Review Output File Structure + +After analyzing the changed files on the above aspects, the agent will produce a comprehensive review in Markdown format. For consistency and clarity, the output should be structured as follows: + +- **Title**: Begin with a top-level heading (e.g., `# Pull Request Review – ` or a similar title). The title can include the PR number or branch if known, and the date/time of the review. + +- **Per-File Sections**: For each file that was part of the diff, create a section in the output. Use a heading for each file, for example: + `## File: path/to/changed_file.ext` + (If many files, third-level headings `###` might be used instead, but usually second-level `##` is fine if the document title is first-level.) + +- **Checklist of Issues/Feedback**: Under each file section, list each point of feedback as an item in a markdown task list. That means each starts with `- [ ]`. For example: + + ```markdown + ## File: src/utils/helpers.py + + - [ ] **Bug:** The function `processData` does not handle `None` inputs. Calling `processData(None)` raises an exception. Add a check for `None` to avoid crashes (e.g., return early or default to an empty list). + - [ ] **Style:** Line 120 is very long (over 120 characters). Break it into multiple lines for better readability. + - [ ] **Test:** No unit tests cover the new `processData` function. Please add tests, especially for edge cases like empty input. + ``` + + Each item is a single concern or suggestion. Start with a brief category (optional) like **Bug**, **Style**, **Test**, **Security**, etc., to classify the type of issue, followed by a description. The description should be specific: mention line numbers or code constructs if possible, and why it should be changed. + +- **Praise or Positive Feedback**: It’s good practice to also acknowledge positive aspects. These can also be checklist items (the developer can tick them off just as acknowledgment) or just bullet points without checkboxes if preferred. Example: + + ```markdown + - [x] **Good Practice:** The refactoring of `processData` into smaller functions is well done, making the code more readable and testable. + ``` + + Here we used `[x]` as a checked box to signify it’s already “addressed” (since it’s good). Alternatively, we could list positives with a different symbol (or as a note). But using the checklist format uniformly is okay. (However, the agent might choose to not check it, leaving it unchecked but phrased positively.) + +- **Referencing Source**: In an internal setting, sometimes it’s useful to reference internal documentation or style guides. If so, the agent might include links or references. Since this is a Markdown file, ensure any links are properly formatted and avoid raw URLs. + +- **Consistency and Order**: Keep the order of file sections consistent with some logical order. This could be alphabetical by file path, or perhaps grouping by importance (maybe put more critical files first). But alphabetical is straightforward. Within a file’s section, you might order items by severity (critical issues first) or by the order they appear in the file (top-to-bottom) to make it easy to follow. + +Here’s an **example** structure for clarity: + +```markdown +# Pull Request Review – 2025-06-03-14-30 + +## File: src/app/utils.py + +- [ ] **Bug:** In `parse_config()`, the code doesn’t close the file after opening it. This can lead to file descriptor leaks. Use a context manager (`with open(...) as f:`) to ensure the file closes. +- [ ] **Improvement:** The regex pattern on line 45 can be precompiled outside the loop for efficiency, since it’s used inside a loop over many items. +- [ ] **Test:** Add tests for `parse_config()` for malformed input. Currently, only well-formed input is tested, but we need to see behavior on bad data. +- [x] **Good Practice:** Using f-strings throughout is great (much more readable than old `%` or `format` methods). + +## File: infrastructure/main.tf + +- [ ] **Terraform – Providers:** Lock provider versions in the `terraform { required_providers }` block[3](https://microsoft.github.io/code-with-engineering-playbook/code-reviews/recipes/terraform/). Currently the AWS provider isn't pinned; add a version constraint (e.g., `~> 4.0`). +- [ ] **Terraform – Remote State:** Backend is local – should use remote state for team collaboration[3](https://microsoft.github.io/code-with-engineering-playbook/code-reviews/recipes/terraform/). Consider adding an `backend "s3" {...}` or similar for state. +- [ ] **Terraform – Variable Defaults:** Remove the default value for `db_password` in `variables.tf` if it's meant to be secret[3](https://microsoft.github.io/code-with-engineering-playbook/code-reviews/recipes/terraform/). Such secrets should be provided at runtime, not in code. +- [ ] **Terraform – Naming:** Resource `aws_instance.web` lacks a tag for environment. Add tags (environment, project, etc.) to resources for management. +- [x] **Terraform – Lint:** All Terraform files are properly formatted (`terraform fmt` shows no changes) – thank you for keeping them tidy! +``` + +In the above example, each file changed (`utils.py` and `main.tf`) has its own section. Within, each bullet is a point of review. The points include a mix of bug fix suggestions, improvements, testing requests, and a bit of praise. We also included some **Terraform-specific** feedback (noting provider version, state backend, etc.) which directly comes from the earlier **Infrastructure as Code considerations**. + +Each checklist item can later be checked (`[x]`) by the team as they address them. Initially, the agent will leave them unchecked (`[ ]`) as things to do. If this review file is updated in subsequent runs (or by people), they might mark them done. But the agent’s role is to produce them unchecked. + +Finally, remember to save this Markdown file in the `./.agent/reviews/` folder with the timestamped name as instructed. For instance, as shown in the title example, the filename was `2025-06-03-14-30-review.md` corresponding to the date/time. + +The structured, per-file checklist format makes it easy for developers to follow up on the review. It turns the review into an actionable to-do list, ensuring nothing is overlooked. The use of headings and checkboxes also makes the output **machine-readable** for any tooling that might parse review results, and **human-readable** for developers who just open the Markdown file. + +--- diff --git a/.gitignore b/.gitignore index 7434a9c..66f6efc 100644 --- a/.gitignore +++ b/.gitignore @@ -1,7 +1,493 @@ -INVESTOR_WHITEPAPER.md -The_Next_Interface_Paradigm__Neural_Memory_Architecture_for_Human-AI_Symbiosis.pdf -/_gated/ +# Created by https://www.toptal.com/developers/gitignore/api/csharp +# Edit at https://www.toptal.com/developers/gitignore?templates=csharp -# macOS system files -.DS_Store +### Csharp ### +## Ignore Visual Studio temporary files, build results, and +## files generated by popular Visual Studio add-ons. +## +## Get latest from https://github.com/github/gitignore/blob/main/VisualStudio.gitignore + +## Ingore Agent output folders + +**/.agent/* + +# Ignore Jekyll site files +_site +.sass-cache +.jekyll-cache +.jekyll-metadata +vendor +Gemfile.lock + +# Prompt flow files +**/.promptflow + +# User-specific files +*.rsuser +*.suo +*.user +*.userosscache +*.sln.docstates + +# EnvVars +.env + +# Python virtual environments (add as needed) +**/*.venv* +**/*venv* +**/*tutorial-env* + +common.egg-info +**/*venv*/* + +# User-specific files (MonoDevelop/Xamarin Studio) +*.userprefs + +# Mono auto generated files +mono_crash.* + +# Build results +[Dd]ebug/ +[Dd]ebugPublic/ +[Rr]elease/ +[Rr]eleases/ +x64/ +x86/ +[Ww][Ii][Nn]32/ +[Aa][Rr][Mm]/ +[Aa][Rr][Mm]64/ +bld/ +[Bb]in/ +[Oo]bj/ +[Ll]og/ +[Ll]ogs/ + +# Visual Studio 2015/2017 cache/options directory +.vs/ +# Uncomment if you have tasks that create the project's static files in wwwroot +#wwwroot/ +.vscode/ + +# Visual Studio 2017 auto generated files +Generated\ Files/ + +# MSTest test Results +[Tt]est[Rr]esult*/ +[Bb]uild[Ll]og.* + +# NUnit +*.VisualState.xml +TestResult.xml +nunit-*.xml + +# JUnit +TEST-*.xml + +# Build Results of an ATL Project +[Dd]ebugPS/ +[Rr]eleasePS/ +dlldata.c + +# Benchmark Results +BenchmarkDotNet.Artifacts/ + +# .NET Core +project.lock.json +project.fragment.lock.json +artifacts/ + +# ASP.NET Scaffolding +ScaffoldingReadMe.txt + +# StyleCop +StyleCopReport.xml + +# Files built by Visual Studio +*_i.c +*_p.c +*_h.h +*.ilk +*.meta +*.obj +*.iobj +*.pch +*.pdb +*.ipdb +*.pgc +*.pgd +*.rsp +*.sbr +*.tlb +*.tli +*.tlh +*.tmp +*.tmp_proj +*_wpftmp.csproj +*.log +*.tlog +*.vspscc +*.vssscc +.builds +*.pidb +*.svclog +*.scc + +# Chutzpah Test files +_Chutzpah* + +# Visual C++ cache files +ipch/ +*.aps +*.ncb +*.opendb +*.opensdf +*.sdf +*.cachefile +*.VC.db +*.VC.VC.opendb + +# Visual Studio profiler +*.psess +*.vsp +*.vspx +*.sap + +# Visual Studio Trace Files +*.e2e + +# TFS 2012 Local Workspace +$tf/ + +# Guidance Automation Toolkit +*.gpState + +# ReSharper is a .NET coding add-in +_ReSharper*/ +*.[Rr]e[Ss]harper +*.DotSettings.user + +# TeamCity is a build add-in +_TeamCity* + +# DotCover is a Code Coverage Tool +*.dotCover + +# AxoCover is a Code Coverage Tool +.axoCover/* +!.axoCover/settings.json + +# Coverlet is a free, cross platform Code Coverage Tool +coverage*.json +coverage*.xml +coverage*.info + +# Visual Studio code coverage results +*.coverage +*.coveragexml + +# NCrunch +_NCrunch_* +.*crunch*.local.xml +nCrunchTemp_* + +# MightyMoose +*.mm.* +AutoTest.Net/ + +# Web workbench (sass) +.sass-cache/ + +# Installshield output folder +[Ee]xpress/ + +# DocProject is a documentation generator add-in +DocProject/buildhelp/ +DocProject/Help/*.HxT +DocProject/Help/*.HxC +DocProject/Help/*.hhc +DocProject/Help/*.hhk +DocProject/Help/*.hhp +DocProject/Help/Html2 +DocProject/Help/html + +# Click-Once directory +publish/ + +# Publish Web Output +*.[Pp]ublish.xml +*.azurePubxml +# Note: Comment the next line if you want to checkin your web deploy settings, +# but database connection strings (with potential passwords) will be unencrypted +*.pubxml +*.publishproj + +# Microsoft Azure Web App publish settings. Comment the next line if you want to +# checkin your Azure Web App publish settings, but sensitive information contained +# in these scripts will be unencrypted +PublishScripts/ + +# NuGet Packages +*.nupkg +# NuGet Symbol Packages +*.snupkg +# The packages folder can be ignored because of Package Restore +**/[Pp]ackages/* +# except build/, which is used as an MSBuild target. +!**/[Pp]ackages/build/ +# Uncomment if necessary however generally it will be regenerated when needed +#!**/[Pp]ackages/repositories.config +# NuGet v3's project.json files produces more ignorable files +*.nuget.props +*.nuget.targets + +# Microsoft Azure Build Output +csx/ +*.build.csdef + +# Microsoft Azure Emulator +ecf/ +rcf/ + +# Windows Store app package directories and files +AppPackages/ +BundleArtifacts/ +Package.StoreAssociation.xml +_pkginfo.txt +*.appx +*.appxbundle +*.appxupload + +# Visual Studio cache files +# files ending in .cache can be ignored +*.[Cc]ache +# but keep track of directories ending in .cache +!?*.[Cc]ache/ + +# Others +ClientBin/ +~$* +*~ +*.dbmdl +*.dbproj.schemaview +*.jfm +*.pfx +*.publishsettings +orleans.codegen.cs + +# Including strong name files can present a security risk +# (https://github.com/github/gitignore/pull/2483#issue-259490424) +#*.snk + +# Since there are multiple workflows, uncomment next line to ignore bower_components +# (https://github.com/github/gitignore/pull/1529#issuecomment-104372622) +#bower_components/ + +# RIA/Silverlight projects +Generated_Code/ + +# Backup & report files from converting an old project file +# to a newer Visual Studio version. Backup files are not needed, +# because we have git ;-) +_UpgradeReport_Files/ +Backup*/ +UpgradeLog*.XML +UpgradeLog*.htm +ServiceFabricBackup/ +*.rptproj.bak + +# SQL Server files +*.mdf +*.ldf +*.ndf + +# Business Intelligence projects +*.rdl.data +*.bim.layout +*.bim_*.settings +*.rptproj.rsuser +*- [Bb]ackup.rdl +*- [Bb]ackup ([0-9]).rdl +*- [Bb]ackup ([0-9][0-9]).rdl + +# Microsoft Fakes +FakesAssemblies/ + +# GhostDoc plugin setting file +*.GhostDoc.xml + +# Node.js Tools for Visual Studio +.ntvs_analysis.dat +node_modules/ + +# Visual Studio 6 build log +*.plg + +# Visual Studio 6 workspace options file +*.opt + +# Visual Studio 6 auto-generated workspace file (contains which files were open etc.) +*.vbw + +# Visual Studio 6 auto-generated project file (contains which files were open etc.) +*.vbp + +# Visual Studio 6 workspace and project file (working project files containing files to include in project) +*.dsw +*.dsp + +# Visual Studio 6 technical files + +# Visual Studio LightSwitch build output +**/*.HTMLClient/GeneratedArtifacts +**/*.DesktopClient/GeneratedArtifacts +**/*.DesktopClient/ModelManifest.xml +**/*.Server/GeneratedArtifacts +**/*.Server/ModelManifest.xml +_Pvt_Extensions + +# Paket dependency manager +.paket/paket.exe +paket-files/ + +# FAKE - F# Make +.fake/ + +# CodeRush personal settings +.cr/personal + +# Python Tools for Visual Studio (PTVS) +__pycache__/ +*.pyc + +# Cake - Uncomment if you are using it +# tools/** +# !tools/packages.config + +# Tabs Studio +*.tss + +# Telerik's JustMock configuration file +*.jmconfig + +# BizTalk build output +*.btp.cs +*.btm.cs +*.odx.cs +*.xsd.cs + +# OpenCover UI analysis results +OpenCover/ + +# Azure Stream Analytics local run output +ASALocalRun/ + +# MSBuild Binary and Structured Log +*.binlog + +# NVidia Nsight GPU debugger configuration file +*.nvuser + +# MFractors (Xamarin productivity tool) working folder +.mfractor/ + +# Local History for Visual Studio +.localhistory/ + +# Visual Studio History (VSHistory) files +.vshistory/ + +# BeatPulse healthcheck temp database +healthchecksdb + +# Backup folder for Package Reference Convert tool in Visual Studio 2017 +MigrationBackup/ + +# Ionide (cross platform F# VS Code tools) working folder +.ionide/ + +# Fody - auto-generated XML schema +FodyWeavers.xsd + +# VS Code files for those working on multiple tools +.vscode/* +!.vscode/settings.json +!.vscode/tasks.json +!.vscode/launch.json +!.vscode/extensions.json +*.code-workspace + +# Local History for Visual Studio Code +.history/ + +# Windows Installer files from build outputs +*.cab +*.msi +*.msix +*.msm +*.msp + +# JetBrains Rider +*.sln.iml +.idea/ + +# End of https://www.toptal.com/developers/gitignore/api/csharp + +# OSX added +**/.DS_Store +# OSX +**/.DS_Store + +local.settings.json + +# Jupyter +**/.ipynb_checkpoints + +# Local .terraform directories +**/.terraform/* + +# .tfstate files +*.tfstate +*.tfstate.* + +# Crash log files +crash.log +crash.*.log + +# Exclude all .tfvars files, which are likely to contain sensitive data, such as +# password, private keys, and other secrets. These should not be part of version +# control as they are data points which are potentially sensitive and subject +# to change depending on the environment. +*.tfvars +*.tfvars.json +# However, some .tfvars files are used to define default values for variables +# and are not sensitive, so we can include them. +!*/environments/*.tfvars + + +# Ignore override files as they are usually used to override resources locally and so +# are not checked in +override.tf +override.tf.json +*_override.tf +*_override.tf.json + +# Ignore Terraform lock file +.terraform.lock.hcl + +# Include tfplan files to ignore the plan output of command: terraform plan -out=tfplan +# example: *tfplan* + +# Ignore CLI configuration files +.terraformrc +terraform.rc +avmmakefile +README-generated.md +avm.tflint.hcl +avm.tflint_example.hcl +avm.tflint_module.hcl +avm.tflint.merged.hcl +avm.tflint_example.merged.hcl +avm.tflint_module.merged.hcl +*tfplan* +*.md.tmp diff --git a/.markdownlint.json b/.markdownlint.json new file mode 100644 index 0000000..51d80be --- /dev/null +++ b/.markdownlint.json @@ -0,0 +1,8 @@ +{ + "line-length": false, + "no-inline-html": false, + "first-line-h1": false, + "no-hard-tabs": { + "code_blocks": false + } +}