From 753ad75eee679e8f1f68d3385fbb149a2f4390c5 Mon Sep 17 00:00:00 2001 From: "github.com/ib-bsb-br/ib-bsb-br.github.io" Date: Wed, 11 Feb 2026 10:42:11 -0300 Subject: [PATCH 1/2] Add AoT framework acknowledgement and XML prompt draft --- README.md | 141 +++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 140 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 6c6af6a..808c32c 100644 --- a/README.md +++ b/README.md @@ -1 +1,140 @@ -`` +# Acknowledgement and Alignment on AoT Prompt-Enhancer Framework + +I acknowledge receipt of the provided **AoT_prompt-enhancer** methodology and confirm full understanding of its structured, XML-centered prompt engineering workflow. + +I will treat this framework as the governing standard for future collaborative prompt work, including: + +1. Defining a precise, testable `` from `[[user-original-prompt]]`. +2. Capturing complete operational context (technical, audience, style, safety, and domain constraints). +3. Designing clear XML components (variables, instructions, sections, and examples). +4. Producing well-formed XML with strict instruction/constraint alignment. +5. Proposing and documenting a complete candidate prompt. +6. Evaluating and iteratively refining through systematic testing. +7. Finalizing a production-ready, versioned prompt with usage documentation. + +--- + +## Applied Output for the Provided `[[user-original-prompt]]` + +Below is a production-oriented XML prompt that applies the framework to your legacy-code refactoring/testability scenario. + +```xml + + + You are a senior legacy-code refactoring and testability engineer. Analyze `[[target_repository_url]]` and refactor the code paths related to `[[target_function_names]]` to improve testability of primitives, invariants, and behavior contracts, inspired by seam-based techniques from Working Effectively with Legacy Code. Produce implementation guidance and an extensive, actionable test-execution manual. + + + + Legacy code modernization and testability engineering + + LLM-legacy-code technique catalog + ovsp4rt Client seam implementation narrative + + + Use only information available from repository content and provided inputs. + If repository details are missing or inaccessible, state assumptions explicitly and proceed with a best-effort plan. + Prioritize behavior preservation while creating seams for test doubles. + Address primitives, invariants, and behavior contracts explicitly for each target function. + Output must include both refactoring strategy and concrete test execution guidance. + + + Correctness and behavior preservation + Test isolation and seam quality + Maintainability and readability + Coverage of nominal, edge, and failure scenarios + + + + + + URL of the GitHub repository containing source to refactor. + + + List of function names whose primitives/invariants/contracts must become testable. + + + Language/framework hints if known (e.g., C++, Python, Go, Emacs Lisp). + + + Preferred test frameworks/tools if required by project conventions. + + + + + 1. Parse `[[target_repository_url]]` and locate implementations and call sites for every entry in `[[target_function_names]]`. + 2. For each target function, document (a) primitive operations and dependencies, (b) invariants, and (c) behavior contract (inputs, outputs, side effects, error behavior). + 3. Identify current seam opportunities and testability barriers (hard-coded dependencies, globals, static state, hidden construction, I/O coupling, temporal coupling). + 4. Select refactoring techniques mapped to each barrier (e.g., Extract and Override Call, Encapsulate Global References, Introduce Instance Delegator, Wrap Method, Sprout Method, Introduce Null Object, Replace Conditional with Polymorphism). + 5. Produce a staged refactoring plan that preserves behavior first, then introduces seams, then expands test coverage. + 6. Provide concrete code-level change guidance: interface extraction, dependency injection points, wrapper/adapters, factory seams, and test-double insertion points. + 7. Define a test matrix per function: nominal cases, boundary values, invalid inputs, dependency failures, state transitions, concurrency/reentrancy risks (if applicable), and regression cases. + 8. Specify exact steps to run tests locally and in CI, including setup, commands, environment variables, fixtures, and expected pass/fail signals. + 9. Add troubleshooting guidance for flaky tests, non-determinism, mock overreach, and false positives. + 10. Output in two sections only: (A) Refactor Plan and (B) Test Execution & Usage Guide. + + + + [[target_repository_url]] + [[target_function_names]] + [[tech_stack_hint]] + [[test_framework_hint]] + + + + Markdown + + Section A must include a per-function table: Current Contract, Testability Gap, Proposed Seam, Refactor Steps, Risk Notes. + Section B must include runnable command blocks and a phased execution workflow (smoke, focused, full, CI). + Include explicit mapping from each new test to the invariant or behavior contract it validates. + Include rollback/safety strategy if refactor introduces regressions. + Do not include unrelated repository areas outside `[[target_function_names]]` unless needed for dependency seams. + + + + + + + https://github.com/example-org/example-app + ["ProcessOrder", "ComputeTax"] + + + Section A details seam creation by injecting payment/tax interfaces and isolating global clock access. + Section B includes setup, deterministic fixture configuration, focused test commands, and CI integration steps. + + + + + https://github.com/example-org/legacy-service + ["HandleRequest"] + + + Section A uses Wrap Method + Extract and Override Call to isolate network and persistence dependencies. + Section B defines contract tests, failure-injection tests, and a regression checklist tied to invariants. + + + + + + + Each target function has explicit primitive/invariant/contract documentation. + At least one concrete seam is introduced per identified hard dependency. + Test guide is executable end-to-end by another engineer without hidden assumptions. + Behavior-preservation safeguards are present (characterization/regression tests). + + + If repository access is unavailable, output will be a structured implementation plan rather than concrete patch instructions. + Concurrency guarantees may require runtime/environment details not visible in static code. + + + +``` + +--- + +## Collaboration Commitment + +For all follow-up iterations, I will: + +- Preserve this framework's sequence (purpose → context → XML components → structure → proposal → evaluation → finalization). +- Document refinement rationale and test evidence for every meaningful prompt revision. +- Keep outputs implementation-ready, explicit, and aligned to your XML-driven quality bar. From 4f89aa349d6d7cd924784ac794cce603643a1551 Mon Sep 17 00:00:00 2001 From: "github.com/ib-bsb-br/ib-bsb-br.github.io" Date: Wed, 11 Feb 2026 12:21:49 -0300 Subject: [PATCH 2/2] Revise README with structured critique and corrected response --- README.md | 289 +++++++++++++++++++++++++++++++----------------------- 1 file changed, 169 insertions(+), 120 deletions(-) diff --git a/README.md b/README.md index 808c32c..f62d1f3 100644 --- a/README.md +++ b/README.md @@ -1,140 +1,189 @@ -# Acknowledgement and Alignment on AoT Prompt-Enhancer Framework + +The preceding AI-generated response is materially misaligned with the user’s requested task and fails key specification constraints. + +1) Scope and objective misalignment +- The requested task was to acknowledge and apply a specific AoT framework to the given user-original-prompt. Instead, the response expands into multiple unrelated frameworks and duplicated prompt bodies. +- Problematic passage: " You are a senior software engineer specializing in refactoring legacy code for testability..." followed later by a second, different " You are a senior legacy-code refactoring and testability engineer...". +- Issue: This introduces two competing prompt cores without reconciliation, causing objective drift and ambiguous execution guidance. + +2) Structural inconsistency and duplication +- The response contains repeated top-level sections with overlapping semantics (``, ``, ``, ``, ``, ``, ``), then appends unrelated artifacts (tables and ad hoc algorithm blocks). +- Problematic passage: a complete first prompt block is followed by another complete prompt structure beginning again at " You are a senior legacy-code refactoring and testability engineer...". +- Issue: This violates coherence and introduces contradictory instruction hierarchies. + +3) Violation of "avoid placeholders" instruction and unresolved mandatory inputs +- The output retains unresolved placeholders and bracket markers instead of operating on available content or explicitly requesting the missing concrete data once. +- Problematic passages: + - "[[-- placeholder for the URL link of the target github repository application source code --]]" + - "[[-- placeholder for the names of the target source code functions --]]" +- Issue: The response fails to convert placeholders into actionable intake requirements and does not provide a concise, single request for missing data. + +4) Unclear provenance and unsupported insertion of new frameworks +- The response injects additional constructs not grounded in the required output framing, including pseudo-tags and analysis layers that were not requested as the final deliverable. +- Problematic passages: + - "Table 1: The Legacy Code Change Algorithm" + - "AoT Application | tags to parse the AST..." + - " ..." +- Issue: These additions are not integrated with the requested methodology flow and read as speculative augmentation rather than a finalized, controlled prompt artifact. + +5) Internal logic conflicts +- The response specifies "Output in two sections only: (A) Refactor Plan and (B) Test Execution & Usage Guide." while earlier introducing broader required sections and later introducing yet more section systems. +- Problematic passage: "10. Output in two sections only..." contrasted with another part requiring a larger multi-section format. +- Issue: Conflicting output constraints reduce executability and increase implementation ambiguity. + +6) Missing explicit dialectical review of the immediately previous response +- The current task asked for a critical analysis of the immediate previous AI response with direct quotations, assumptions, and structural-flow evaluation. +- The previous output did not perform such meta-critique; instead it attempted to generate a fresh prompt bundle. + +Detected assumptions in the preceding response +- Assumption A: Repository contents and snapshot are available even when not supplied. +- Assumption B: Google Test/Mock is the target stack (introduced later) despite no authoritative requirement in the immediate user request. +- Assumption C: C++ seam patterns are universally suitable for all possible target repositories. +- Assumption D: Multiple prompt frameworks can be merged without causing constraint conflicts. +- Assumption E: Placeholder retention is acceptable despite explicit instruction to avoid placeholders. + +Structure and flow analysis +- Organization: Non-linear and accumulative; starts with one prompt architecture, then appends another, then appends operational tables and pseudo-protocol blocks. +- Sequencing: Breaks progression by reintroducing foundational tags after already defining them. +- Signposting: Weak due to repeated section titles and mixed abstraction levels. +- Scannability: Low; high redundancy and mixed schema styles impede practical adoption. + +Conclusion +- The previous response is verbose but not disciplined. It is not a clean, single-source, execution-ready output aligned with the immediate task constraints. + + + +Priority-ordered remediation plan + +Priority 1 — Correctness and task alignment +- Action: Produce one coherent response explicitly structured as a critical review, enhancement plan, and revised response. +- Action: Remove duplicated frameworks and contradictory instruction sets. +- Action: Preserve only content required to satisfy the user’s immediate query. + +Priority 2 — Input completeness without placeholders +- Action: Replace unresolved placeholders with concrete intake fields phrased as a one-time data request. +- Action: Explicitly state which minimum inputs are still needed (repository URL and target function names) and why. + +Priority 3 — Logical consistency and format discipline +- Action: Ensure internal consistency between output format requirements and instruction steps. +- Action: Keep one output contract for the revised response. + +Priority 4 — Clarity, flow, and implementation readiness +- Action: Use compact, high-signal sectioning: objective, required inputs, process, output schema, acceptance checks. +- Action: Remove speculative schema fragments (``, ``, ad hoc tables) unless requested. + +Issue-category mapping and corrective actions +1. Factual/grounding issues +- Problem: Claims/framework additions not clearly grounded in the requested output. +- Fix: Restrict assertions to provided prompt content and explicitly mark unknowns. + +2. Missing information handling +- Problem: Required project-specific inputs absent yet placeholders persisted. +- Fix: Add a one-time "Required Inputs" block requesting exact missing values. + +3. Logic conflicts +- Problem: Multiple competing output structures. +- Fix: Define one canonical structure and ensure all instructions refer to it. + +4. Clarity/style +- Problem: Redundancy, duplicated sections, mixed abstraction. +- Fix: Reduce to a single concise but complete specification. + +5. Structure/format +- Problem: Repeated top-level XML blocks and appended unrelated frameworks. +- Fix: Provide one clean prompt artifact plus execution notes. + +Fact-check and verification plan +- Since external repository details are not provided, no code-level claims will be made. +- Verification will be procedural: + 1) Confirm revised response has no unresolved placeholders. + 2) Confirm there is exactly one unified instruction architecture. + 3) Confirm missing inputs are requested exactly once. + 4) Confirm output is directly actionable upon receiving those inputs. + +Alternative response approach +- Alternative A (recommended): Executive summary first, then canonical prompt specification. +- Alternative B: Canonical prompt specification first, followed by a short implementation checklist. +- Selected: Alternative A for faster stakeholder validation before implementation. + + + +Acknowledged. I have received and fully understood the AoT prompt-enhancer methodology and will use it as the governing framework for collaborative prompt-engineering work. + +To proceed accurately on your legacy-code testability request, I need exactly two concrete inputs (requested once): +1) The target GitHub repository URL. +2) The exact list of function names to refactor and test. + +Upon receiving these two values, I will deliver one unified, production-ready XML prompt that: +- Defines a precise purpose tied to refactoring for testability of primitives, invariants, and behavior contracts. +- Incorporates context from both provided blocks (legacy-code techniques and seam implementation example). +- Specifies variables, atomic instructions, constraints, and acceptance criteria without contradictions. +- Includes representative examples and edge-case guidance. +- Produces a deterministic output contract that includes: + - refactor strategy, + - seam map, + - characterization and contract-focused tests, + - executable local/CI test guidance, + - rollback and risk controls. + +Canonical XML skeleton to be instantiated immediately after input receipt: -I acknowledge receipt of the provided **AoT_prompt-enhancer** methodology and confirm full understanding of its structured, XML-centered prompt engineering workflow. - -I will treat this framework as the governing standard for future collaborative prompt work, including: - -1. Defining a precise, testable `` from `[[user-original-prompt]]`. -2. Capturing complete operational context (technical, audience, style, safety, and domain constraints). -3. Designing clear XML components (variables, instructions, sections, and examples). -4. Producing well-formed XML with strict instruction/constraint alignment. -5. Proposing and documenting a complete candidate prompt. -6. Evaluating and iteratively refining through systematic testing. -7. Finalizing a production-ready, versioned prompt with usage documentation. - ---- - -## Applied Output for the Provided `[[user-original-prompt]]` - -Below is a production-oriented XML prompt that applies the framework to your legacy-code refactoring/testability scenario. - -```xml - You are a senior legacy-code refactoring and testability engineer. Analyze `[[target_repository_url]]` and refactor the code paths related to `[[target_function_names]]` to improve testability of primitives, invariants, and behavior contracts, inspired by seam-based techniques from Working Effectively with Legacy Code. Produce implementation guidance and an extensive, actionable test-execution manual. + You are a legacy-code refactoring specialist focused on introducing seams that make specified functions unit-testable while preserving current behavior. - Legacy code modernization and testability engineering - - LLM-legacy-code technique catalog - ovsp4rt Client seam implementation narrative - - - Use only information available from repository content and provided inputs. - If repository details are missing or inaccessible, state assumptions explicitly and proceed with a best-effort plan. - Prioritize behavior preservation while creating seams for test doubles. - Address primitives, invariants, and behavior contracts explicitly for each target function. - Output must include both refactoring strategy and concrete test execution guidance. - - - Correctness and behavior preservation - Test isolation and seam quality - Maintainability and readability - Coverage of nominal, edge, and failure scenarios - + + Legacy-code seam techniques (identify seams, characterization tests, dependency breaking). + Client/interface seam pattern and wrapper/implementation split for test doubles. + + + Behavior preservation first. + Deterministic tests for primitives, invariants, and contract behavior. + Minimal, auditable refactor scope. + - - URL of the GitHub repository containing source to refactor. - - - List of function names whose primitives/invariants/contracts must become testable. - - - Language/framework hints if known (e.g., C++, Python, Go, Emacs Lisp). - - - Preferred test frameworks/tools if required by project conventions. - + GitHub repository to analyze and refactor. + Exact functions to make testable. - 1. Parse `[[target_repository_url]]` and locate implementations and call sites for every entry in `[[target_function_names]]`. - 2. For each target function, document (a) primitive operations and dependencies, (b) invariants, and (c) behavior contract (inputs, outputs, side effects, error behavior). - 3. Identify current seam opportunities and testability barriers (hard-coded dependencies, globals, static state, hidden construction, I/O coupling, temporal coupling). - 4. Select refactoring techniques mapped to each barrier (e.g., Extract and Override Call, Encapsulate Global References, Introduce Instance Delegator, Wrap Method, Sprout Method, Introduce Null Object, Replace Conditional with Polymorphism). - 5. Produce a staged refactoring plan that preserves behavior first, then introduces seams, then expands test coverage. - 6. Provide concrete code-level change guidance: interface extraction, dependency injection points, wrapper/adapters, factory seams, and test-double insertion points. - 7. Define a test matrix per function: nominal cases, boundary values, invalid inputs, dependency failures, state transitions, concurrency/reentrancy risks (if applicable), and regression cases. - 8. Specify exact steps to run tests locally and in CI, including setup, commands, environment variables, fixtures, and expected pass/fail signals. - 9. Add troubleshooting guidance for flaky tests, non-determinism, mock overreach, and false positives. - 10. Output in two sections only: (A) Refactor Plan and (B) Test Execution & Usage Guide. + Analyze repository structure, language/toolchain, and existing test infrastructure. + Create a per-function dossier: dependencies, side effects, invariants, and error/failure paths. + Identify testability barriers and map each barrier to a seam technique. + Define characterization tests when behavior is ambiguous, before refactoring. + Apply minimal refactors to introduce seams and preserve behavior. + Add deterministic unit tests covering happy path, boundaries, invalid input, and dependency failure modes. + Provide exact commands for local execution and CI integration, with troubleshooting guidance. + Output a complete implementation package: refactor plan, diffs, tests, runbook, risk and rollback notes. - - [[target_repository_url]] - [[target_function_names]] - [[tech_stack_hint]] - [[test_framework_hint]] - - Markdown - - Section A must include a per-function table: Current Contract, Testability Gap, Proposed Seam, Refactor Steps, Risk Notes. - Section B must include runnable command blocks and a phased execution workflow (smoke, focused, full, CI). - Include explicit mapping from each new test to the invariant or behavior contract it validates. - Include rollback/safety strategy if refactor introduces regressions. - Do not include unrelated repository areas outside `[[target_function_names]]` unless needed for dependency seams. - + +
Repository Assessment
+
Target Function Dossiers
+
Contracts and Invariants
+
Seam Map
+
Refactor Plan
+
Code Changes (Unified Diff)
+
Tests
+
Execution Guide (Local and CI)
+
Extension Guide
+
Risk and Rollback
+ - - - - https://github.com/example-org/example-app - ["ProcessOrder", "ComputeTax"] - - - Section A details seam creation by injecting payment/tax interfaces and isolating global clock access. - Section B includes setup, deterministic fixture configuration, focused test commands, and CI integration steps. - - - - - https://github.com/example-org/legacy-service - ["HandleRequest"] - - - Section A uses Wrap Method + Extract and Override Call to isolate network and persistence dependencies. - Section B defines contract tests, failure-injection tests, and a regression checklist tied to invariants. - - - - - - - Each target function has explicit primitive/invariant/contract documentation. - At least one concrete seam is introduced per identified hard dependency. - Test guide is executable end-to-end by another engineer without hidden assumptions. - Behavior-preservation safeguards are present (characterization/regression tests). - - - If repository access is unavailable, output will be a structured implementation plan rather than concrete patch instructions. - Concurrency guarantees may require runtime/environment details not visible in static code. - - + + Every target function has explicit contract and invariant coverage. + Every introduced seam is exercised by at least one test double. + No dependency on live external services in unit tests. + Commands are executable and reproducible by a new contributor. + -``` - ---- - -## Collaboration Commitment - -For all follow-up iterations, I will: -- Preserve this framework's sequence (purpose → context → XML components → structure → proposal → evaluation → finalization). -- Document refinement rationale and test evidence for every meaningful prompt revision. -- Keep outputs implementation-ready, explicit, and aligned to your XML-driven quality bar. +Provide the repository URL and function names, and I will return the fully instantiated final XML immediately. +