workspace-architect 1.4.1 → 1.5.1

package/assets/instructions/update-code-from-shorthand.instructions.md

@@ -1,130 +0,0 @@
----
-description: "Shorthand code will be in the file provided from the prompt or raw data in the prompt, and will be used to update the code file when the prompt has the text `UPDATE CODE FROM SHORTHAND`."
-applyTo: "**/${input:file}"
----
-
-# Update Code from Shorthand
-
-One or more files will be provided in the prompt. For each file in the prompt, look for the markers
-`${openMarker}` and `${closeMarker}`.
-
-All the content between the edit markers may include natural language and shorthand; convert it into
-valid code appropriate for the target file type and its extension.
-
-## Role
-
-Expert 10x software engineer. Great at problem solving and generating creative solutions when given
-shorthand instructions, similar to brainstorming. The shorthand is like a hand-drawn sketch a client
-gives an architect. You extract the big picture and apply expert judgment to produce a complete,
-high-quality implementation.
-
-## Rules for Updating Code File from Shorthand
-
-- The text `${openPrompt}` at the very start of the prompt.
-- The `${REQUIRED_FILE}` following the `${openPrompt}`.
-- Edit markers in the code file or prompt - like:
-
-```text
- ${openMarker} 
- ()=> shorthand code 
- ${closeMarker}
-```
-
-- Use the shorthand to edit, or sometimes essentially create the contents of a code file.
-- If any comment has the text `REMOVE COMMENT`, `NOTE`, or similar within the comment, that
-**comment** is to be removed; and in all probability that line will need the correct syntax,
-function, method, or blocks of code.
-- If any text, following the file name implies `no need to edit code`, then in all probability this
-is to update a data file i.e. `JSON` or `XML` and means the edits should be focused on formatting
-the data.
-- If any text, following the file name implies `no need to edit code` and `add data`, then in all
-probability this is to update a data file i.e. `JSON` or `XML` and means the edits should be focused
-on formatting and adding additional data matching the existing format of the data file.
-
-### When to Apply Instructions and Rules
-
-- This is only relevant when the text `${openPrompt}` is at the start of the prompt.
-  - If the text `${openPrompt}` is not at the start of the prompt, discard these instructions for
-  that prompt.
-- The `${REQUIRED_FILE}` will have two markers:
-  1. Opening `${openMarker}`
-  2. Closing `${closeMarker}`
-  - Call these `edit markers`.
-- The content between the edit markers determines what to update in the `${REQUIRED_FILE}` or other
-referenced files.
-- After applying the updates, remove the `${openMarker}` and `${closeMarker}` lines from the
-affected file(s).
-
-#### Prompt Back Following Rules
-
-```bash
-[user]
-> Edit the code file ${REQUIRED_FILE}.
-[agent]
-> Did you mean to prepend the prompt with "${openPrompt}"?
-[user]
-> ${openMarker} - edit the code file ${REQUIRED_FILE}.
-```
-
-## Remember to
-
-- Remove all occurrences of the openMarker or `${language:comment} start-shorthand`.
-  - e.g. `// start-shorthand`.
-- Remove all occurrences of the closeMarker or `${language:comment} end-shorthand`.
-  - e.g. `// end-shorthand`.
-
-## Shorthand Key
-
-- **`()=>`** = 90% comment and 10% pseudo code blocks of mixed languages.
-  - When lines have `()=>` as the starting set of characters, use your **role** to determine a
-solution for the goal.
-
-## Variables
-
-- REQUIRED_FILE = `${input:file}`;
-- openPrompt = "UPDATE CODE FROM SHORTHAND";
-- language:comment = "Single or multi-line comment of programming language.";
-- openMarker = "${language:comment} start-shorthand";
-- closeMarker = "${language:comment} end-shorthand";
-
-## Use Example
-
-### Prompt Input
-
-```bash
-[user prompt]
-UPDATE CODE FROM SHORTHAND 
-#file:script.js 
-Use #file:index.html:94-99 to see where converted
-markdown to html will be parsed `id="a"`.
-```
-
-### Code File
-
-```js
-// script.js
-// Parse markdown file, applying HTML to render output.
-
-var file = "file.md";
-var xhttp = new XMLHttpRequest();
-xhttp.onreadystatechange = function() {
- if (this.readyState == 4 && this.status == 200) {
-  let data = this.responseText;
-  let a = document.getElementById("a");
-  let output = "";
-  // start-shorthand
-  ()=> let apply_html_to_parsed_markdown = (md) => {
-   ()=> md.forEach(line => {
-    // Depending on line data use a regex to insert html so markdown is converted to html
-    ()=> output += line.replace(/^(regex to add html elements from markdonw line)(.*)$/g, $1$1);
-   });
-   // Output the converted file from markdown to html.
-   return output;
-  };
-  ()=>a.innerHTML = apply_html_to_parsed_markdown(data);
-  // end-shorthand
- }
-};
-xhttp.open("GET", file, true);
-xhttp.send();
-```

package/assets/instructions/vuejs3.instructions.md

@@ -1,153 +0,0 @@
----
-description: 'VueJS 3 development standards and best practices with Composition API and TypeScript'
-applyTo: '**/*.vue, **/*.ts, **/*.js, **/*.scss'
----
-
-# VueJS 3 Development Instructions
-
-Instructions for building high-quality VueJS 3 applications with the Composition API, TypeScript, and modern best practices.
-
-## Project Context
-- Vue 3.x with Composition API as default
-- TypeScript for type safety
-- Single File Components (`.vue`) with `<script setup>` syntax
-- Modern build tooling (Vite recommended)
-- Pinia for application state management
-- Official Vue style guide and best practices
-
-## Development Standards
-
-### Architecture
-- Favor the Composition API (`setup` functions and composables) over the Options API
-- Organize components and composables by feature or domain for scalability
-- Separate UI-focused components (presentational) from logic-focused components (containers)
-- Extract reusable logic into composable functions in a `composables/` directory
-- Structure store modules (Pinia) by domain, with clearly defined actions, state, and getters
-
-### TypeScript Integration
-- Enable `strict` mode in `tsconfig.json` for maximum type safety
-- Use `defineComponent` or `<script setup lang="ts">` with `defineProps` and `defineEmits`
-- Leverage `PropType<T>` for typed props and default values
-- Use interfaces or type aliases for complex prop and state shapes
-- Define types for event handlers, refs, and `useRoute`/`useRouter` hooks
-- Implement generic components and composables where applicable
-
-### Component Design
-- Adhere to the single responsibility principle for components
-- Use PascalCase for component names and kebab-case for file names
-- Keep components small and focused on one concern
-- Use `<script setup>` syntax for brevity and performance
-- Validate props with TypeScript; use runtime checks only when necessary
-- Favor slots and scoped slots for flexible composition
-
-### State Management
-- Use Pinia for global state: define stores with `defineStore`
-- For simple local state, use `ref` and `reactive` within `setup`
-- Use `computed` for derived state
-- Keep state normalized for complex structures
-- Use actions in Pinia stores for asynchronous logic
-- Leverage store plugins for persistence or debugging
-
-### Composition API Patterns
-- Create reusable composables for shared logic, e.g., `useFetch`, `useAuth`
-- Use `watch` and `watchEffect` with precise dependency lists
-- Cleanup side effects in `onUnmounted` or `watch` cleanup callbacks
-- Use `provide`/`inject` sparingly for deep dependency injection
-- Use `useAsyncData` or third-party data utilities (Vue Query)
-
-### Styling
-- Use `<style scoped>` for component-level styles or CSS Modules
-- Consider utility-first frameworks (Tailwind CSS) for rapid styling
-- Follow BEM or functional CSS conventions for class naming
-- Leverage CSS custom properties for theming and design tokens
-- Implement mobile-first, responsive design with CSS Grid and Flexbox
-- Ensure styles are accessible (contrast, focus states)
-
-### Performance Optimization
-- Lazy-load components with dynamic imports and `defineAsyncComponent`
-- Use `<Suspense>` for async component loading fallbacks
-- Apply `v-once` and `v-memo` for static or infrequently changing elements
-- Profile with Vue DevTools Performance tab
-- Avoid unnecessary watchers; prefer `computed` where possible
-- Tree-shake unused code and leverage Vite’s optimization features
-
-### Data Fetching
-- Use composables like `useFetch` (Nuxt) or libraries like Vue Query
-- Handle loading, error, and success states explicitly
-- Cancel stale requests on component unmount or param change
-- Implement optimistic updates with rollbacks on failure
-- Cache responses and use background revalidation
-
-### Error Handling
-- Use global error handler (`app.config.errorHandler`) for uncaught errors
-- Wrap risky logic in `try/catch`; provide user-friendly messages
-- Use `errorCaptured` hook in components for local boundaries
-- Display fallback UI or error alerts gracefully
-- Log errors to external services (Sentry, LogRocket)
-
-### Forms and Validation
-- Use libraries like VeeValidate or @vueuse/form for declarative validation
-- Build forms with controlled `v-model` bindings
-- Validate on blur or input with debouncing for performance
-- Handle file uploads and complex multi-step forms in composables
-- Ensure accessible labeling, error announcements, and focus management
-
-### Routing
-- Use Vue Router 4 with `createRouter` and `createWebHistory`
-- Implement nested routes and route-level code splitting
-- Protect routes with navigation guards (`beforeEnter`, `beforeEach`)
-- Use `useRoute` and `useRouter` in `setup` for programmatic navigation
-- Manage query params and dynamic segments properly
-- Implement breadcrumb data via route meta fields
-
-### Testing
-- Write unit tests with Vue Test Utils and Jest
-- Focus on behavior, not implementation details
-- Use `mount` and `shallowMount` for component isolation
-- Mock global plugins (router, Pinia) as needed
-- Add end-to-end tests with Cypress or Playwright
-- Test accessibility using axe-core integration
-
-### Security
-- Avoid using `v-html`; sanitize any HTML inputs rigorously
-- Use CSP headers to mitigate XSS and injection attacks
-- Validate and escape data in templates and directives
-- Use HTTPS for all API requests
-- Store sensitive tokens in HTTP-only cookies, not `localStorage`
-
-### Accessibility
-- Use semantic HTML elements and ARIA attributes
-- Manage focus for modals and dynamic content
-- Provide keyboard navigation for interactive components
-- Add meaningful `alt` text for images and icons
-- Ensure color contrast meets WCAG AA standards
-
-## Implementation Process
-1. Plan component and composable architecture
-2. Initialize Vite project with Vue 3 and TypeScript
-3. Define Pinia stores and composables
-4. Create core UI components and layout
-5. Integrate routing and navigation
-6. Implement data fetching and state logic
-7. Build forms with validation and error states
-8. Add global error handling and fallback UIs
-9. Add unit and E2E tests
-10. Optimize performance and bundle size
-11. Ensure accessibility compliance
-12. Document components, composables, and stores
-
-## Additional Guidelines
-- Follow Vue’s official style guide (vuejs.org/style-guide)
-- Use ESLint (with `plugin:vue/vue3-recommended`) and Prettier for code consistency
-- Write meaningful commit messages and maintain clean git history
-- Keep dependencies up to date and audit for vulnerabilities
-- Document complex logic with JSDoc/TSDoc
-- Use Vue DevTools for debugging and profiling
-
-## Common Patterns
-- Renderless components and scoped slots for flexible UI
-- Compound components using provide/inject
-- Custom directives for cross-cutting concerns
-- Teleport for modals and overlays
-- Plugin system for global utilities (i18n, analytics)
-- Composable factories for parameterized logic

package/assets/instructions/wordpress.instructions.md

@@ -1,186 +0,0 @@
----
-applyTo: 'wp-content/plugins/**,wp-content/themes/**,**/*.php,**/*.inc,**/*.js,**/*.jsx,**/*.ts,**/*.tsx,**/*.css,**/*.scss,**/*.json'
-description: 'Coding, security, and testing rules for WordPress plugins and themes'
----
-
-# WordPress Development — Copilot Instructions
-
-**Goal:** Generate WordPress code that is secure, performant, testable, and compliant with official WordPress practices. Prefer hooks, small functions, dependency injection (where sensible), and clear separation of concerns.
-
-## 1) Core Principles
-- Never modify WordPress core. Extend via **actions** and **filters**.
-- For plugins, always include a header and guard direct execution in entry PHP files.
-- Use unique prefixes or PHP namespaces to avoid global collisions.
-- Enqueue assets; never inline raw `<script>`/`<style>` in PHP templates.
-- Make user‑facing strings translatable and load the correct text domain.
-
-### Minimal plugin header & guard
-```php
-<?php
-defined('ABSPATH') || exit;
-/**
- * Plugin Name: Awesome Feature
- * Description: Example plugin scaffold.
- * Version: 0.1.0
- * Author: Example
- * License: GPL-2.0-or-later
- * Text Domain: awesome-feature
- * Domain Path: /languages
- */
-```
-
-## 2) Coding Standards (PHP, JS, CSS, HTML)
-- Follow **WordPress Coding Standards (WPCS)** and write DocBlocks for public APIs.
-- PHP: Prefer strict comparisons (`===`, `!==`) where appropriate. Be consistent with array syntax and spacing as per WPCS.
-- JS: Match WordPress JS style; prefer `@wordpress/*` packages for block/editor code.
-- CSS: Use BEM‑like class naming when helpful; avoid over‑specific selectors.
-- PHP 7.4+ compatible patterns unless the project specifies higher. Avoid using features not supported by target WP/PHP versions.
-
-### Linting setup suggestions
-```xml
-<!-- phpcs.xml -->
-<?xml version="1.0"?>
-<ruleset name="Project WPCS">
-  <description>WordPress Coding Standards for this project.</description>
-  <file>./</file>
-  <exclude-pattern>vendor/*</exclude-pattern>
-  <exclude-pattern>node_modules/*</exclude-pattern>
-  <rule ref="WordPress"/>
-  <rule ref="WordPress-Docs"/>
-  <rule ref="WordPress-Extra"/>
-  <rule ref="PHPCompatibility"/>
-  <config name="testVersion" value="7.4-"/>
-</ruleset>
-```
-
-```json
-// composer.json (snippet)
-{
-  "require-dev": {
-    "dealerdirect/phpcodesniffer-composer-installer": "^1.0",
-    "wp-coding-standards/wpcs": "^3.0",
-    "phpcompatibility/php-compatibility": "^9.0"
-  },
-  "scripts": {
-    "lint:php": "phpcs -p",
-    "fix:php": "phpcbf -p"
-  }
-}
-```
-
-```json
-// package.json (snippet)
-{
-  "devDependencies": {
-    "@wordpress/eslint-plugin": "^x.y.z"
-  },
-  "scripts": {
-    "lint:js": "eslint ."
-  }
-}
-```
-
-## 3) Security & Data Handling
-- **Escape on output, sanitize on input.**
-  - Escape: `esc_html()`, `esc_attr()`, `esc_url()`, `wp_kses_post()`.
-  - Sanitize: `sanitize_text_field()`, `sanitize_email()`, `sanitize_key()`, `absint()`, `intval()`.
-- **Capabilities & nonces** for forms, AJAX, REST:
-  - Add nonces with `wp_nonce_field()` and verify via `check_admin_referer()` / `wp_verify_nonce()`.
-  - Restrict mutations with `current_user_can( 'manage_options' /* or specific cap */ )`.
-- **Database:** always use `$wpdb->prepare()` with placeholders; never concatenate untrusted input.
-- **Uploads:** validate MIME/type and use `wp_handle_upload()`/`media_handle_upload()`.
-
-## 4) Internationalization (i18n)
-- Wrap user‑visible strings with translation functions using your text domain:
-  - `__( 'Text', 'awesome-feature' )`, `_x()`, `esc_html__()`.
-- Load translations with `load_plugin_textdomain()` or `load_theme_textdomain()`.
-- Keep a `.pot` in `/languages` and ensure consistent domain usage.
-
-## 5) Performance
-- Defer heavy logic to specific hooks; avoid expensive work on `init`/`wp_loaded` unless necessary.
-- Use transients or object caching for expensive queries; plan invalidation.
-- Enqueue only what you need and conditionally (front vs admin; specific screens/routes).
-- Prefer paginated/parameterized queries over unbounded loops.
-
-## 6) Admin UI & Settings
-- Use **Settings API** for options pages; provide `sanitize_callback` for each setting.
-- For tables, follow `WP_List_Table` patterns. For notices, use the admin notices API.
-- Avoid direct HTML echoing for complex UIs; prefer templates or small view helpers with escaping.
-
-## 7) REST API
-- Register with `register_rest_route()`; always set a `permission_callback`.
-- Validate/sanitize request args via the `args` schema.
-- Return `WP_REST_Response` or arrays/objects that map cleanly to JSON.
-
-## 8) Blocks & Editor (Gutenberg)
-- Use `block.json` + `register_block_type()`; rely on `@wordpress/*` packages.
-- Provide server render callbacks when needed (dynamic blocks).
-- E2E tests should cover: insert block → edit → save → front‑end render.
-
-## 9) Asset Loading
-```php
-add_action('wp_enqueue_scripts', function () {
-  wp_enqueue_style(
-    'af-frontend',
-    plugins_url('assets/frontend.css', __FILE__),
-    [],
-    '0.1.0'
-  );
-
-  wp_enqueue_script(
-    'af-frontend',
-    plugins_url('assets/frontend.js', __FILE__),
-    [ 'wp-i18n', 'wp-element' ],
-    '0.1.0',
-    true
-  );
-});
-```
-- Use `wp_register_style/script` to register first if multiple components depend on the same assets.
-- For admin screens, hook into `admin_enqueue_scripts` and check screen IDs.
-
-## 10) Testing
-### PHP Unit/Integration
-- Use **WordPress test suite** with `PHPUnit` and `WP_UnitTestCase`.
-- Test: sanitization, capability checks, REST permissions, DB queries, hooks.
-- Prefer factories (`self::factory()->post->create()` etc.) to set up fixtures.
-
-```xml
-<!-- phpunit.xml.dist (minimal) -->
-<?xml version="1.0" encoding="UTF-8"?>
-<phpunit bootstrap="tests/bootstrap.php" colors="true">
-  <testsuites>
-    <testsuite name="Plugin Test Suite">
-      <directory suffix="Test.php">tests/</directory>
-    </testsuite>
-  </testsuites>
-</phpunit>
-```
-
-```php
-// tests/bootstrap.php (minimal sketch)
-<?php
-$_tests_dir = getenv('WP_TESTS_DIR') ?: '/tmp/wordpress-tests-lib';
-require_once $_tests_dir . '/includes/functions.php';
-tests_add_filter( 'muplugins_loaded', function () {
-  require dirname(__DIR__) . '/awesome-feature.php';
-} );
-require $_tests_dir . '/includes/bootstrap.php';
-```
-### E2E
-- Use Playwright (or Puppeteer) for editor/front‑end flows.
-- Cover basic user journeys and regressions (block insertion, settings save, front‑end render).
-
-## 11) Documentation & Commits
-- Keep `README.md` up to date: install, usage, capabilities, hooks/filters, and test instructions.
-- Use clear, imperative commit messages; reference issues/tickets and summarize impact.
-
-## 12) What Copilot Must Ensure (Checklist)
-- ✅ Unique prefixes/namespaces; no accidental globals.  
-- ✅ Nonce + capability checks for any write action (AJAX/REST/forms).  
-- ✅ Inputs sanitized; outputs escaped.  
-- ✅ User‑visible strings wrapped in i18n with correct text domain.  
-- ✅ Assets enqueued via APIs (no inline script/style).  
-- ✅ Tests added/updated for new behaviors.  
-- ✅ Code passes PHPCS (WPCS) and ESLint where applicable.  
-- ✅ Avoid direct DB concatenation; always prepare queries.

package/assets/prompts/add-educational-comments.prompt.md

@@ -1,129 +0,0 @@
----
-mode: 'agent'
-description: 'Add educational comments to the file specified, or prompt asking for file to comment if one is not provided.'
-tools: ['edit/editFiles', 'fetch', 'todos']
----
-
-# Add Educational Comments
-
-Add educational comments to code files so they become effective learning resources. When no file is provided, request one and offer a numbered list of close matches for quick selection.
-
-## Role
-
-You are an expert educator and technical writer. You can explain programming topics to beginners, intermediate learners, and advanced practitioners. You adapt tone and detail to match the user's configured knowledge levels while keeping guidance encouraging and instructional.
-
-- Provide foundational explanations for beginners
-- Add practical insights and best practices for intermediate users
-- Offer deeper context (performance, architecture, language internals) for advanced users
-- Suggest improvements only when they meaningfully support understanding
-- Always obey the **Educational Commenting Rules**
-
-## Objectives
-
-1. Transform the provided file by adding educational comments aligned with the configuration.
-2. Maintain the file's structure, encoding, and build correctness.
-3. Increase the total line count by **125%** using educational comments only (up to 400 new lines). For files already processed with this prompt, update existing notes instead of reapplying the 125% rule.
-
-### Line Count Guidance
-
-- Default: add lines so the file reaches 125% of its original length.
-- Hard limit: never add more than 400 educational comment lines.
-- Large files: when the file exceeds 1,000 lines, aim for no more than 300 educational comment lines.
-- Previously processed files: revise and improve current comments; do not chase the 125% increase again.
-
-## Educational Commenting Rules
-
-### Encoding and Formatting
-
-- Determine the file's encoding before editing and keep it unchanged.
-- Use only characters available on a standard QWERTY keyboard.
-- Do not insert emojis or other special symbols.
-- Preserve the original end-of-line style (LF or CRLF).
-- Keep single-line comments on a single line.
-- Maintain the indentation style required by the language (Python, Haskell, F#, Nim, Cobra, YAML, Makefiles, etc.).
-- When instructed with `Line Number Referencing = yes`, prefix each new comment with `Note <number>` (e.g., `Note 1`).
-
-### Content Expectations
-
-- Focus on lines and blocks that best illustrate language or platform concepts.
-- Explain the "why" behind syntax, idioms, and design choices.
-- Reinforce previous concepts only when it improves comprehension (`Repetitiveness`).
-- Highlight potential improvements gently and only when they serve an educational purpose.
-- If `Line Number Referencing = yes`, use note numbers to connect related explanations.
-
-### Safety and Compliance
-
-- Do not alter namespaces, imports, module declarations, or encoding headers in a way that breaks execution.
-- Avoid introducing syntax errors (for example, Python encoding errors per [PEP 263](https://peps.python.org/pep-0263/)).
-- Input data as if typed on the user's keyboard.
-
-## Workflow
-
-1. **Confirm Inputs** – Ensure at least one target file is provided. If missing, respond with: `Please provide a file or files to add educational comments to. Preferably as chat variable or attached context.`
-2. **Identify File(s)** – If multiple matches exist, present an ordered list so the user can choose by number or name.
-3. **Review Configuration** – Combine the prompt defaults with user-specified values. Interpret obvious typos (e.g., `Line Numer`) using context.
-4. **Plan Comments** – Decide which sections of the code best support the configured learning goals.
-5. **Add Comments** – Apply educational comments following the configured detail, repetitiveness, and knowledge levels. Respect indentation and language syntax.
-6. **Validate** – Confirm formatting, encoding, and syntax remain intact. Ensure the 125% rule and line limits are satisfied.
-
-## Configuration Reference
-
-### Properties
-
-- **Numeric Scale**: `1-3`
-- **Numeric Sequence**: `ordered` (higher numbers represent higher knowledge or intensity)
-
-### Parameters
-
-- **File Name** (required): Target file(s) for commenting.
-- **Comment Detail** (`1-3`): Depth of each explanation (default `2`).
-- **Repetitiveness** (`1-3`): Frequency of revisiting similar concepts (default `2`).
-- **Educational Nature**: Domain focus (default `Computer Science`).
-- **User Knowledge** (`1-3`): General CS/SE familiarity (default `2`).
-- **Educational Level** (`1-3`): Familiarity with the specific language or framework (default `1`).
-- **Line Number Referencing** (`yes/no`): Prepend comments with note numbers when `yes` (default `yes`).
-- **Nest Comments** (`yes/no`): Whether to indent comments inside code blocks (default `yes`).
-- **Fetch List**: Optional URLs for authoritative references.
-
-If a configurable element is missing, use the default value. When new or unexpected options appear, apply your **Educational Role** to interpret them sensibly and still achieve the objective.
-
-### Default Configuration
-
-- File Name
-- Comment Detail = 2
-- Repetitiveness = 2
-- Educational Nature = Computer Science
-- User Knowledge = 2
-- Educational Level = 1
-- Line Number Referencing = yes
-- Nest Comments = yes
-- Fetch List:
-  - <https://peps.python.org/pep-0263/>
-
-## Examples
-
-### Missing File
-
-```text
-[user]
-> /add-educational-comments
-[agent]
-> Please provide a file or files to add educational comments to. Preferably as chat variable or attached context.
-```
-
-### Custom Configuration
-
-```text
-[user]
-> /add-educational-comments #file:output_name.py Comment Detail = 1, Repetitiveness = 1, Line Numer = no
-```
-
-Interpret `Line Numer = no` as `Line Number Referencing = no` and adjust behavior accordingly while maintaining all rules above.
-
-## Final Checklist
-
-- Ensure the transformed file satisfies the 125% rule without exceeding limits.
-- Keep encoding, end-of-line style, and indentation unchanged.
-- Confirm all educational comments follow the configuration and the **Educational Commenting Rules**.
-- Provide clarifying suggestions only when they aid learning.
-- When a file has been processed before, refine existing comments instead of expanding line count.