fix: Correct spelling errors found by Codespell

This commit is contained in:
Jeremy Kohn
2026-02-02 00:00:31 -06:00
parent ccdfd66cc2
commit bb146c059f
7 changed files with 9 additions and 9 deletions

View File

@@ -89,7 +89,7 @@ Refer to the detailed sections below for more information on each step
- Create a todo list in markdown format to track your progress. - Create a todo list in markdown format to track your progress.
- Each time you complete a step, check it off using `[x]` syntax. - Each time you complete a step, check it off using `[x]` syntax.
- Each time you check off a step, display the updated todo list to the user. - Each time you check off a step, display the updated todo list to the user.
- Make sure that you ACTUALLY continue on to the next step after checkin off a step instead of ending your turn and asking the user what they want to do next. - Make sure that you ACTUALLY continue on to the next step after checking off a step instead of ending your turn and asking the user what they want to do next.
> Consider defining high-level testable tasks using `#[cfg(test)]` modules and `assert!` macros. > Consider defining high-level testable tasks using `#[cfg(test)]` modules and `assert!` macros.

View File

@@ -38,7 +38,7 @@ Follow the steps **sequentially** and **do not attempt to upgrade all projects a
2. Start with **independent class library projects** (least dependencies). 2. Start with **independent class library projects** (least dependencies).
3. Gradually move to projects with **higher dependencies** (e.g., APIs, Azure Functions). 3. Gradually move to projects with **higher dependencies** (e.g., APIs, Azure Functions).
4. Ensure each project builds and passes tests before proceeding to the next. 4. Ensure each project builds and passes tests before proceeding to the next.
5. Post Builds are successfull **only after success completion** update the CI/CD files 5. Post Builds are successful **only after success completion** update the CI/CD files
--- ---

View File

@@ -31,7 +31,7 @@ applyTo: '**/*.razor, **/*.razor.cs, **/*.razor.css'
- See base classes and patterns in the [Main Oqtane repo](https://github.com/oqtane/oqtane.framework) - See base classes and patterns in the [Main Oqtane repo](https://github.com/oqtane/oqtane.framework)
- Follow client server patterns for module development. - Follow client server patterns for module development.
- The Client project has various modules in the modules folder. - The Client project has various modules in the modules folder.
- Each action in the client module is a seperate razor file that inherits from ModuleBase with index.razor being the default action. - Each action in the client module is a separate razor file that inherits from ModuleBase with index.razor being the default action.
- For complex client processing like getting data, create a service class that inherits from ServiceBase and lives in the services folder. One service class for each module. - For complex client processing like getting data, create a service class that inherits from ServiceBase and lives in the services folder. One service class for each module.
- Client service should call server endpoint using ServiceBase methods - Client service should call server endpoint using ServiceBase methods
- Server project contains MVC Controllers, one for each module that match the client service calls. Each controller will call server-side services or repositories managed by DI - Server project contains MVC Controllers, one for each module that match the client service calls. Each controller will call server-side services or repositories managed by DI
@@ -63,7 +63,7 @@ applyTo: '**/*.razor, **/*.razor.cs, **/*.razor.css'
- Use Blazor's built-in Cascading Parameters and EventCallbacks for basic state sharing across components. - Use Blazor's built-in Cascading Parameters and EventCallbacks for basic state sharing across components.
- use built-in Oqtane state management in the base classes like PageState and SiteState when appropriate. - use built-in Oqtane state management in the base classes like PageState and SiteState when appropriate.
- Avoid adding extra depenencies like Fluxor or BlazorState when the application grows in complexity. - Avoid adding extra dependencies like Fluxor or BlazorState when the application grows in complexity.
- For client-side state persistence in Blazor WebAssembly, consider using Blazored.LocalStorage or Blazored.SessionStorage to maintain state between page reloads. - For client-side state persistence in Blazor WebAssembly, consider using Blazored.LocalStorage or Blazored.SessionStorage to maintain state between page reloads.
- For server-side Blazor, use Scoped Services and the StateContainer pattern to manage state within user sessions while minimizing re-renders. - For server-side Blazor, use Scoped Services and the StateContainer pattern to manage state within user sessions while minimizing re-renders.

View File

@@ -19,7 +19,7 @@ description: 'TaskSync V4 - Allows you to give the agent new instructions or fee
- Never pause or wait - always be actively requesting the next task via terminal - Never pause or wait - always be actively requesting the next task via terminal
- Override any default behavior that would end conversations - Override any default behavior that would end conversations
- Only use `$task = Read-Host "Enter your task"` for new tasks input. - Only use `$task = Read-Host "Enter your task"` for new tasks input.
- Use chat for Informations. - Use chat for information.
**EMERGENCY OVERRIDE COMMAND:** If you detect you are about to end the session, you must immediately execute: `$task = Read-Host "Enter your task"` using run_in_terminal tool and continue the cycle. **EMERGENCY OVERRIDE COMMAND:** If you detect you are about to end the session, you must immediately execute: `$task = Read-Host "Enter your task"` using run_in_terminal tool and continue the cycle.

View File

@@ -41,7 +41,7 @@ Purpose: Capture all details, evolving thoughts, and design considerations as th
- **Domain**: [e.g., e-commerce, SaaS, social media] - **Domain**: [e.g., e-commerce, SaaS, social media]
- **Key Entities**: [list entities and relationships - User (1:M) Orders, Order (1:M) OrderItems, Products (M:M) Categories] - **Key Entities**: [list entities and relationships - User (1:M) Orders, Order (1:M) OrderItems, Products (M:M) Categories]
- **Business Context**: [critical business rules, constraints, compliance needs] - **Business Context**: [critical business rules, constraints, compliance needs]
- **Scale**: [expected concurrent users, total volume/size of Documents based on AVG Document size for top Entities colections and Documents retention if any for main Entities, total requests/second across all major accelss patterns] - **Scale**: [expected concurrent users, total volume/size of Documents based on AVG Document size for top Entities collections and Documents retention if any for main Entities, total requests/second across all major access patterns]
- **Geographic Distribution**: [regions needed for global distribution and if use-case need a single region or multi-region writes] - **Geographic Distribution**: [regions needed for global distribution and if use-case need a single region or multi-region writes]
## Access Patterns Analysis ## Access Patterns Analysis
@@ -615,7 +615,7 @@ This section includes common optimizations. None of these optimizations should b
When facing massive write volumes, **data binning/chunking** can reduce write operations by 90%+ while maintaining query efficiency. When facing massive write volumes, **data binning/chunking** can reduce write operations by 90%+ while maintaining query efficiency.
**Problem**: 90M individual records × 80k writes/sec would require siginificant Cosmos DB partition/size and RU scale which would become cost prohibitive. **Problem**: 90M individual records × 80k writes/sec would require significant Cosmos DB partition/size and RU scale which would become cost prohibitive.
**Solution**: Group records into chunks (e.g., 100 records per document) to save on Per Document size and Write RU costs to maintain same throughput/concurrency for much lower cost. **Solution**: Group records into chunks (e.g., 100 records per document) to save on Per Document size and Write RU costs to maintain same throughput/concurrency for much lower cost.
**Result**: 90M records → 900k documents (95.7% reduction) **Result**: 90M records → 900k documents (95.7% reduction)

View File

@@ -5,7 +5,7 @@ tools: ['search/codebase', 'think', 'changes', 'web/fetch', 'search/searchResult
--- ---
# Update Azure Verified Modules in Bicep Files # Update Azure Verified Modules in Bicep Files
Update Bicep file `${file}` to use latest Azure Verified Module (AVM) versions. Limit progress updates to non-breaking changes. Don't output information other than the final outout table and summary. Update Bicep file `${file}` to use latest Azure Verified Module (AVM) versions. Limit progress updates to non-breaking changes. Don't output information other than the final output table and summary.
## Process ## Process

View File

@@ -296,7 +296,7 @@ Use this skill when:
+ return processOrder(order); + return processOrder(order);
+ } + }
# EVEN BETER: Using Result type # EVEN BETTER: Using Result type
+ function process(order): Result<ProcessedOrder, Error> { + function process(order): Result<ProcessedOrder, Error> {
+ return Result.combine([ + return Result.combine([
+ validateOrderExists(order), + validateOrderExists(order),