Customer-specific development module — typical cases

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

Change the issue process for this product.

Specific failure illustrated

A product's process code is updated, but Camunda still runs the old BPMN version or the wrong product path.

Initial solution take

A product's process code is updated, but Camunda still runs the old BPMN version or the wrong product path.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. Core restart/upload behaviour is part of the BPMN release, not just the image build.
2. The customer's process files and user-task code can live at different paths from master.
3. Existing in-flight instances may continue on their original process version.

Return to solution take

Change the approved product process and release its compatible Core/BPMN components.

Reject this shortcut: The image is new but Camunda still serves the old process: no delivery.

Confirmation and application

1. Pin the product process key, branch heads, BPMN and user-task code; confirm placement.
2. Implement and test the requested path in isolated worktrees, including any Configuration registration dependency.
3. Deploy the declared Core image and BPMN set, then start the permitted test instance.

Verification

1. The target process definition/version is the intended one.
2. A test instance reaches the requested stage with correct user tasks.
3. Existing in-flight instances have an explicit treatment rather than being silently assumed migrated.

Recovery

Use the recorded prior image/process version and account for instances started under the new definition; a code rollback does not rewrite process history.

What is retained

Memory: Image publication and process-definition activation are distinct events.

Skill: Require process key/version and a real workflow transition in release proof.

Tool candidate: Automate source/BPMN/target-version comparison and capture the test instance's stage transitions.

Next request: Inspect the live process and branch counterpart before adapting the previous implementation.

Source basis: DV-01 evidence, mechanism and delivery census — aisa-next/10 Architecture/30 Source/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

The bank clause is missing from the printed document.

Specific failure illustrated

The bank-beneficiary print change is only half-promoted: the selector is enabled before its evaluator and data dependencies are ready.

Initial solution take

The bank-beneficiary print change is only half-promoted: the selector is enabled before its evaluator and data dependencies are ready.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. SD-1863's archived PROD review found missing configuration rows and an empty POLQRY.gINSIS_CREDITED_OBJ_IDS body.
2. The unknown print token failed open, producing unwanted documents rather than safely suppressing them.
3. C# selection, shared library, PL/SQL, registration rows and the external BI template must agree.

Return to solution take

Deliver the complete print contract in compatibility order and test both wanted and unwanted documents.

Reject this shortcut: C# is deployed but a configuration toggle, PL/SQL body or BI template is missing: fail.

Confirmation and application

1. Reproduce per-object bank-beneficiary selection and inventory the exact C#/library/POLQRY/row/template versions.
2. Prepare the reviewed code and stored-code change; join the Configuration and BI-owner obligations before enabling the selector.
3. Promote the compatible set and invoke the exact credited/non-credited object examples.

Verification

1. The requested bank clause contains the intended object and parameters.
2. A non-credited object emits no unwanted bank document.
3. POLQRY has the required implementation, and the target serves all declared components.

Recovery

Restore the compatible selector/evaluator/registration set; previously generated documents remain recorded external effects and may require separate handling.

What is retained

Memory: A fail-open print gate turns an incomplete release into extra output, not just a missing feature.

Skill: Never activate the new selector ahead of its evaluator, rows and template.

Tool candidate: Automate a print-release manifest plus positive/negative document-selection probes, including a stored-code-body capability check.

Next request: Check current invocation and all component versions before using the old print pattern.

Source basis: Case 4 / SD-1863: missing rows, POLQRY stub and fail-open print token — aisa-next/10 Architecture/40 Support/Case Studies.md; DV-02: code, library, PL/SQL, rows and BI-template release obligations — aisa-next/10 Architecture/30 Source/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

Build the reinsurance capability.

Specific failure illustrated

A request for a reinsurance capability is treated as one small fix despite programme-scale scope.

Initial solution take

A request for a reinsurance capability is treated as one small fix despite programme-scale scope.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. The catalogue describes facultative, treaty, claims and reporting work across many plugins and services.
2. No single generic 'done' test can establish that entire capability.
3. The current Development charter accepts bounded changes, not an unbounded new-module programme.

Return to solution take

Return a scoped programme referral with its accountable owner and separately definable implementation slices.

Reject this shortcut: 84 commits are treated as one small extension with one generic done test: reject scope.

Confirmation and application

1. Identify the requested business capability, existing modules and the coordination owner.
2. Separate bounded defects/extensions from the programme's deliverables and dependencies.
3. Record the acknowledged scope/referral and any independently authorised slice.

Verification

1. The owner and scope boundary are acknowledged.
2. No claim says that all facultative/treaty/reporting capability is delivered.
3. Any future slice has its own input, tests and delivery acceptance.

Recovery

Amend the scope/referral if it was wrong; there is no target rollback for a programme that was not implemented.

What is retained

Memory: A long commit stream is evidence of programme scope, not one completed small case.

Skill: Keep programme intake distinct from ordinary implementation tasks.

Tool candidate: Use a read-only component/dependency inventory to support scope assessment; do not invent an execution tool for an unapproved programme.

Next request: Route a new bounded reinsurance fix normally; recognise another programme-scale request before implementation.

Source basis: DV-03 evidence, mechanism and delivery census — aisa-next/10 Architecture/30 Source/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

Change this premium or cover calculation.

Specific failure illustrated

A premium-rule library is released, but an active consumer still computes the old result.

Initial solution take

A premium-rule library is released, but an active consumer still computes the old result.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. The rule may belong to a customer plugin or a shared service on the actual lineage.
2. Publishing a NuGet version does not rebuild its consumers.
3. A family calculation needs boundary examples and unchanged sibling products.

Return to solution take

Implement the agreed rule at its approved seam and release every required consumer.

Reject this shortcut: NuGet is published but an active consumer still runs the old rule: fail.

Confirmation and application

1. Reproduce the exact product/cover rule with approved arithmetic and inspect actual placement.
2. Implement the narrow change, test affected boundaries and review the package/row dependencies.
3. Publish and rebuild/deploy all declared consumers, then repeat the worked quotes on target.

Verification

1. The affected product/cover examples match the intended calculation and currency.
2. Boundary and unchanged-sibling examples remain correct.
3. Serving consumers use the reviewed package version.

Recovery

Roll back the compatible package/consumer set and account for quotes or policies already produced under the changed rule.

What is retained

Memory: A package release is not a deployed calculation change.

Skill: Keep the worked-example set and consumer manifest in the release packet.

Tool candidate: Automate package-to-serving-consumer version checks and replay the per-product arithmetic matrix.

Next request: Re-run the reproducer on current source and pricing versions before reusing code or examples.

Source basis: DV-04 evidence, mechanism and delivery census — aisa-next/10 Architecture/30 Source/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

Harden the partner policy-registration API.

Specific failure illustrated

RegisterPolicy returns success, but the partner's policy later fails transfer or printing.

Initial solution take

RegisterPolicy returns success, but the partner's policy later fails transfer or printing.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. The registration plugin, identity client and database schema form one contract.
2. Repeated requests and supplied policy numbers need declared idempotency/validation behaviour.
3. The partner's requested target may be staging without a production release.

Return to solution take

Deliver the bounded registration-contract change with its schema and identity dependencies.

Reject this shortcut: REST success precedes a failed transfer or missing print: no end-to-end result.

Confirmation and application

1. Pin the exact partner request examples, target and registration/identity/schema versions.
2. Implement and test valid, invalid and repeated requests at the approved plugin seam.
3. Deploy only the agreed target set and exercise register → transfer → print.

Verification

1. Valid examples produce the intended policy and document.
2. Invalid and repeated requests follow the approved response/effect behaviour.
3. Transfer and print proof accompany REST success.

Recovery

Reconcile policies already registered before retry or compensation; preserve issued numbers and identity-client changes outside the packet.

What is retained

Memory: A successful HTTP response is not proof of completed registration delivery.

Skill: Use the approved partner collection as an end-to-end contract with negative and repeat examples.

Tool candidate: Automate request replay and downstream policy/transfer/print correlation, with credentials and customer identifiers excluded from retained fixtures.

Next request: Recheck the current partner contract and schema; do not reuse a past partner's credentials or launch authority.

Source basis: DV-05 evidence, mechanism and delivery census — aisa-next/10 Architecture/30 Source/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

Correct how these customer details are handled.

Specific failure illustrated

The UI accepts party data that the active backend rejects or transfers differently.

Initial solution take

The UI accepts party data that the active backend rejects or transfers differently.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. Customer fields pass through UI validation, backend rules and INSIS propagation.
2. custPid, optional addresses and account-related fields have distinct source/format rules.
3. A same-day UI/backend pair can still be only partly deployed.

Return to solution take

Change and deliver the compatible field contract across the affected consumers.

Reject this shortcut: UI accepts a value that the active backend rejects: fail the pair.

Confirmation and application

1. Reproduce create/edit with the exact valid and invalid field examples on the current target.
2. Implement the narrow UI/backend/identity change at the approved seams.
3. Deploy the compatible pair and inspect the resulting participant data after transfer.

Verification

1. The UI and backend agree on valid and invalid input.
2. The intended optional and required fields behave correctly.
3. Transferred participant data matches the approved source meaning.

Recovery

Restore the compatible client/server contract; review records already saved or transferred under the changed rules before attempting data compensation.

What is retained

Memory: A UI validator change does not establish the server's field contract.

Skill: Keep source-of-truth and negative/optional-field examples with the paired release.

Tool candidate: Automate the UI-request-backend-target field comparison using sanitised fixtures.

Next request: Check both current client validation and server behaviour before applying the previous pattern.

Source basis: DV-06 evidence, mechanism and delivery census — aisa-next/10 Architecture/30 Source/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

Fix participant search and commission defaults.

Specific failure illustrated

The participant/commission UI reaches production while its required backend half remains on staging.

Initial solution take

The participant/commission UI reaches production while its required backend half remains on staging.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. The participant search and commission default depend on both UI and backend behaviour.
2. The catalogue's SD-1709 example specifically exposes a missing backend promotion.
3. Office/agent rules and downstream defaults must be checked together.

Return to solution take

Deliver the reviewed compatible UI/backend change and retain any missing half as an open obligation.

Reject this shortcut: The UI reaches PROD but its required backend half remains on staging: reject delivery.

Confirmation and application

1. Reproduce the participant search/default and identify the actual serving revisions.
2. Implement or promote only the required pair, including the declared plugin/consumer changes.
3. Run the target search and a test quote with the approved intermediary/office scope.

Verification

1. The intended participant is returned.
2. Commission defaults follow the correct agent/office rule.
3. Both serving halves match the release packet.

Recovery

Roll back the compatible pair, not only the visible UI, and account for quotes created with changed defaults.

What is retained

Memory: A green UI deployment can conceal an absent backend capability.

Skill: Make required client/server halves explicit in the release join.

Tool candidate: Automate a serving-capability/version check before the participant and commission regression probes.

Next request: Inspect serving versions first; the next ticket may be an undeployed half rather than a new defect.

Source basis: DV-07 evidence, mechanism and delivery census — aisa-next/10 Architecture/30 Source/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

Coordinate the currency change across products.

Specific failure illustrated

The BGN-to-EUR programme is compressed into one case and legacy-currency behaviour is lost.

Initial solution take

The BGN-to-EUR programme is compressed into one case and legacy-currency behaviour is lost.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. The change spans plugins, shared models, rating filters, printing and UI interpretation.
2. The history contains reverts and restoration of conversion behaviour.
3. A new EUR quote and a legacy BGN policy have different obligations.

Return to solution take

Refer the programme explicitly and accept only bounded currency slices with named dependencies.

Reject this shortcut: One successful EUR quote is treated as proof of every legacy policy, report and transfer: reject.

Confirmation and application

1. Identify affected product/system seams and the accountable programme owner.
2. Separate the requested slice from the cross-product programme; define both new-EUR and legacy cases for that slice.
3. Record the scope decision or deliver only the separately approved slice.

Verification

1. The referral is labelled as a referral, not a completed currency programme.
2. Any implemented slice preserves the intended legacy interpretation.
3. Its quote, transfer and print examples reconcile with currency displayed.

Recovery

Review conversion semantics and records already produced before reversing a slice; do not undo the programme with a bulk currency-string replacement.

What is retained

Memory: Currency code replacement is not the same as preserving monetary meaning.

Skill: Require paired new-currency/legacy-policy fixtures for every bounded slice.

Tool candidate: Automate a slice-specific quote/transfer/print comparison with explicit currency and conversion basis.

Next request: Separate new programme scope from a repeat defect and recheck the effective currency/version context.

Source basis: DV-08 evidence, mechanism and delivery census — aisa-next/10 Architecture/30 Source/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations. The current AISA path is classification and commercial communication only. No offer, price or delivery date is invented.

Customer request

The number changes when I enter a comma.

Specific failure illustrated

A Bulgarian number field looks correct but submits a different numeric value after parsing or blur.

Initial solution take

A Bulgarian number field looks correct but submits a different numeric value after parsing or blur.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. The relevant path includes toNumberParser, form validation and the actual outgoing payload.
2. Comma/dot entry, blur and reopening exercise different transitions.
3. The correct master path may differ from the customer's serdica-shared/Formly lineage.

Return to solution take

Route this Core Development offer type into Assessment & Offers. Clarify the request, investigate required effort through scoped domain evidence, draft owner-backed terms, obtain customer approval and communicate the decision. No implementation follows from offer approval.

Reject this shortcut: An offer or acceptance starts Source implementation, or missing owner terms are presented as a committed delivery: fail.

Confirmation and application

1. Clarify the exact requested shared behaviour and success examples with the customer.
2. Assess the required work and dependencies using current source evidence and comparable cases; record uncertainty and separate active effort from external waiting.
3. Prepare owner-backed scope/price/delivery terms, obtain the customer’s decision on the exact offer revision, and communicate it. Missing terms remain pending.

Verification

1. The numeric-input gesture and posted value are attached to the owner brief.
2. Every quoted offer or delivery term has an owner/source reference and its proposed/committed status.
3. No Core implementation tasks or grants exist; absent commercial terms remain visible as pending.

Recovery

Correct the request or communicated terms through the same reviewed channel. There is no target code/data change to reverse.

What is retained

Memory: Retain the shared-versus-customer classification, reproducible evidence and the source of commercial/delivery terms; do not retain a fictitious executed repair.

Skill: Assess required work and craft a sourced offer; retain comparable effort evidence and the customer decision.

Tool candidate: Reuse the common request/packet and channel tools; this request does not justify a new code-execution tool.

Next request: Check whether the new request is the same shared behaviour or a customer-specific variant, then prepare a fresh owner brief and obtain current offer/delivery terms.

Source basis: DV-09 evidence, mechanism and delivery census — aisa-next/10 Architecture/30 Source/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

The object dialog does not behave as requested.

Specific failure illustrated

The requested object-dialog behaviour already exists in source but the target serves an older version.

Initial solution take

The requested object-dialog behaviour already exists in source but the target serves an older version.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. Feature absence, a bug and a missing promotion require different work.
2. The description/dialog history includes changes that did not reach production.
3. Opening, editing and saving exercise more than the initial render.

Return to solution take

Implement only a missing approved capability, or promote the existing reviewed change when deployment is the gap.

Reject this shortcut: A code diff exists but the target still serves the older dialog: no completion.

Confirmation and application

1. Compare the target interaction and serving UI revision with the known source change.
2. Prepare the smallest required dialog/label/data-contract delta or promotion.
3. Test open, edit, validate, save and repeated navigation on the target.

Verification

1. The requested dialog or description feature is actually present on target.
2. Edits persist with valid data-contract behaviour.
3. Reopening and subsequent navigation remain usable.

Recovery

Restore the prior compatible UI/data-contract version and keep already-saved record changes explicit.

What is retained

Memory: Source presence does not prove user-visible availability.

Skill: Check the serving revision before treating a reported missing UI feature as new development.

Tool candidate: Automate the target-version check and a small dialog interaction/persistence regression.

Next request: Inspect deployed feature/version before reopening development; reuse the real interaction test.

Source basis: DV-10 evidence, mechanism and delivery census — aisa-next/10 Architecture/30 Source/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

Support the framework contract type across the product.

Specific failure illustrated

A framework contract-type column exists, but required values are NULL or never selected by the process.

Initial solution take

A framework contract-type column exists, but required values are NULL or never selected by the process.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. Schema, configuration values, code/plugin and workflow are separate dependencies.
2. Cargo FRAME/group-policy behaviour may touch shared Annexes consumers.
3. A new column on both environments does not establish a working feature.

Return to solution take

Join the contract-type schema, values and consumers with the intended framework flow.

Reject this shortcut: A new column exists on both environments but every required value is NULL: fail.

Confirmation and application

1. Pin actual schema, code and workflow versions and list the expected contract-type values.
2. Implement the approved source changes and join the Configuration delta before activation.
3. Create the permitted child under the intended framework and inspect the consumed contract type.

Verification

1. The required values are populated and meaningful.
2. The active consumer selects the declared FRAME/contract type.
3. The child is created under the correct framework and unrelated contracts still work.

Recovery

Restore a compatible code/value set; account for children or process instances created under the new contract type.

What is retained

Memory: Schema presence, population and runtime consumption are three separate proofs.

Skill: Require the mixed code/configuration release and its consumer test.

Tool candidate: Automate schema/value/consumer checks and capture the framework/child linkage in the smoke test.

Next request: Recheck column support, row population and consumer behaviour before reusing the FRAME pattern.

Source basis: DV-11 evidence, mechanism and delivery census — aisa-next/10 Architecture/30 Source/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

Correct this motor-policy flow.

Specific failure illustrated

A motor-flow change handles one subtype but retries an ambiguous partner timeout or breaks a sibling product.

Initial solution take

A motor-flow change handles one subtype but retries an ambiguous partner timeout or breaks a sibling product.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. Product/subtype and process version determine which rule executes.
2. A timeout may follow a completed external effect.
3. A Next Release wish is a waiting request, not an implicitly authorised deployment.

Return to solution take

Implement the bounded subtype rule or retain the explicit release wait, with timeout reconciliation preserved.

Reject this shortcut: A timeout is assumed to mean nothing landed and the action is retried blindly: reject.

Confirmation and application

1. Reproduce the exact motor subtype, partner response and current process/riskmodel path.
2. Implement the approved plugin/service/filter change and test affected plus sibling cases.
3. Deploy only as authorised and reconcile an unknown external outcome before any retry.

Verification

1. The requested subtype follows the intended flow.
2. Sibling products and relevant negative responses remain valid.
3. Ambiguous external effects are reconciled rather than repeated.

Recovery

Use the declared code/process reversal and reconcile external registrations or documents already produced.

What is retained

Memory: Timeout classification and subtype discrimination belong in the fix, not in an operator's memory.

Skill: Keep subtype, response and current-process inputs in the regression fixture.

Tool candidate: Automate subtype/response replay with explicit unknown-outcome checks instead of a blanket retry script.

Next request: Check current service/flow version and outstanding release before proposing a second fix.

Source basis: DV-12 evidence, mechanism and delivery census — aisa-next/10 Architecture/30 Source/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

Correct the pricing pre/post-filter.

Specific failure illustrated

A routine port restores a pricing filter that was deliberately reversed on production.

Initial solution take

A routine port restores a pricing filter that was deliberately reversed on production.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. Python riskmodel pre/post-filters choose or transform rating inputs/results.
2. Target-only reversals are part of the intended target state until reviewed.
3. The deployed anl-risk-model artifact, not a source file alone, determines behaviour.

Return to solution take

Apply the reviewed target-specific filter change using the repository's Python toolchain.

Reject this shortcut: A change deliberately reverted on PROD is restored by a routine port without review: reject.

Confirmation and application

1. Read the current pre/post-filter, selected template and source/target reversal history.
2. Implement and test the approved input/output behaviour without restoring an excluded target change.
3. Deploy the declared artifact and run current get_rates fixtures per cover and template.

Verification

1. The intended template and per-cover premiums are selected.
2. Unchanged cases retain their expected output.
3. The target serves the approved filter revision, including its intentional exclusions.

Recovery

Restore the recorded prior filter/artifact with its target exceptions; do not use a generic port to erase a deliberate reversal.

What is retained

Memory: A target reversal is evidence of intended behaviour, not automatically a missing commit.

Skill: Keep target-specific exclusions and exact filter input/output fixtures.

Tool candidate: Automate per-cover filter regressions and compare the proposed port with recorded target-only reversals.

Next request: Inspect the target's actual filter and prior reversal before using a staging implementation.

Source basis: DV-13 evidence, mechanism and delivery census — aisa-next/10 Architecture/30 Source/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

Fix the transfer and return-to-application behaviour.

Specific failure illustrated

The C# caller is promoted but the live PL/SQL still implements the old transfer/revert contract.

Initial solution take

The C# caller is promoted but the live PL/SQL still implements the old transfer/revert contract.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. Stored code may not be versioned in the repository alongside its caller.
2. A return-to-application sequence can affect an entire multi-year family.
3. Cross-system timeouts leave effects that must be reconciled before replay.

Return to solution take

Deliver the compatible caller and stored-code contract, then prove the transfer/revert sequence.

Reject this shortcut: The C# side is deployed but the database still has the old contract: fail.

Confirmation and application

1. Reproduce the caller/database boundary and retain the current package body and effect evidence.
2. Prepare the reviewed source and PL/SQL artifacts in compatible order, with declared effect/DDL gates.
3. Run the authorised target sequence and compare family state before and after.

Verification

1. The active caller and package implement the same contract.
2. Transfer/revert completes without duplicate effects.
3. Required family membership and state invariants still hold.

Recovery

Restore compatible caller/package versions and compensate only known landed data effects; a package rollback does not undo policy changes.

What is retained

Memory: Caller deployment and database-contract deployment must join before delivery.

Skill: Retain the triggering action, live package identity and whole-family regression.

Tool candidate: Automate caller/package capability checks and the journal-backed transfer/revert assertion sequence.

Next request: Load current caller and package signatures before applying the regression; check whether the causal fix is already live.

Source basis: DV-14 evidence, mechanism and delivery census — aisa-next/10 Architecture/30 Source/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

Enable the new operator check and its message.

Specific failure illustrated

The new validation library builds successfully, but no enabling row or Bulgarian message reaches the target.

Initial solution take

The new validation library builds successfully, but no enabling row or Bulgarian message reaches the target.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. The generic Operations library, configuration activation and SR_MESSAGES are separate components.
2. A package version is not enough if a consumer was not rebuilt.
3. Human-readable error arguments are part of the operator-facing contract.

Return to solution take

Deliver the compatible library, consumers, enabling rows and message keys.

Reject this shortcut: A successful build with no enabling row is reported as a working control: reject.

Confirmation and application

1. Identify the generic capability, required activation rows and message parameters.
2. Implement/review the narrow change and join the Configuration or owner's row delivery.
3. Rebuild the declared consumers and trigger valid/invalid examples on target.

Verification

1. The invalid input is blocked by the intended control.
2. A permitted policy start date still passes the enabled control.
3. The Bulgarian message and its arguments resolve from the deployed code/row set.

Recovery

Restore compatible activation/message/library versions and account for cases already processed under the rule.

What is retained

Memory: A build can be green while a configurable control is inert.

Skill: Make code, enabling rows, message keys and consumer versions one release checklist.

Tool candidate: Automate capability/activation/message completeness checks and replay the invalid/valid operator examples.

Next request: Check whether the code exists but lacks activation or messages before writing new code.

Source basis: DV-15 evidence, mechanism and delivery census — aisa-next/10 Architecture/30 Source/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations. The current AISA path is classification and commercial communication only. No offer, price or delivery date is invented.

Customer request

Prevent this incident from recurring.

Specific failure illustrated

A robustness patch exists but the affected query still scans, truncates useful results or leaks the wrong error.

Initial solution take

A robustness patch exists but the affected query still scans, truncates useful results or leaks the wrong error.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. The original boundary workload determines whether the clamp/index fix is valid.
2. An index's existence does not prove the query uses an appropriate predicate.
3. Shared library fixes require all affected consumers to be rebuilt.

Return to solution take

Route this Core Development offer type into Assessment & Offers. Clarify the request, investigate required effort through scoped domain evidence, draft owner-backed terms, obtain customer approval and communicate the decision. No implementation follows from offer approval.

Reject this shortcut: An offer or acceptance starts Source implementation, or missing owner terms are presented as a committed delivery: fail.

Confirmation and application

1. Clarify the exact requested shared behaviour and success examples with the customer.
2. Assess the required work and dependencies using current source evidence and comparable cases; record uncertainty and separate active effort from external waiting.
3. Prepare owner-backed scope/price/delivery terms, obtain the customer’s decision on the exact offer revision, and communicate it. Missing terms remain pending.

Verification

1. The paging workload, shared cap/default semantics and affected consumers are attached to the owner brief.
2. Every quoted offer or delivery term has an owner/source reference and its proposed/committed status.
3. No Core implementation tasks or grants exist; absent commercial terms remain visible as pending.

Recovery

Correct the request or communicated terms through the same reviewed channel. There is no target code/data change to reverse.

What is retained

Memory: Retain the shared-versus-customer classification, reproducible evidence and the source of commercial/delivery terms; do not retain a fictitious executed repair.

Skill: Assess required work and craft a sourced offer; retain comparable effort evidence and the customer decision.

Tool candidate: Reuse the common request/packet and channel tools; this request does not justify a new code-execution tool.

Next request: Check whether the new request is the same shared behaviour or a customer-specific variant, then prepare a fresh owner brief and obtain current offer/delivery terms.

Source basis: DV-16 evidence, mechanism and delivery census — aisa-next/10 Architecture/30 Source/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

Port this change without losing target-only work.

Specific failure illustrated

A cross-branch port matches a commit subject but loses target-only behaviour or lands on the wrong layout.

Initial solution take

A cross-branch port matches a commit subject but loses target-only behaviour or lands on the wrong layout.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. Source and target paths can differ substantially.
2. Target-only fixes and reversals must be preserved explicitly.
3. A history rewrite invalidates previously reviewed head relationships.

Return to solution take

Port the reviewed semantic change in the requested direction against freshly pinned heads.

Reject this shortcut: Protected target history was rewritten after approval: invalidate preflight and re-review.

Confirmation and application

1. Capture source/target heads, path correspondence and target-only exceptions.
2. Apply the narrow semantic delta in an isolated target worktree and review the target diff.
3. Run target tests and record equivalence evidence against the actual heads.

Verification

1. The target behaviour implements the intended source change.
2. Target-only accepted work remains intact.
3. The reviewed heads still match before promotion; rewritten history forces new review.

Recovery

Use a reviewed revert/continuation on the target's actual history; do not reset away unrelated target work.

What is retained

Memory: Subject matching is retrieval help, not proof of an equivalent port.

Skill: Keep directional path maps and target exceptions with the port packet.

Tool candidate: Automate head/path/patch correspondence and flag target-only or rewritten-history conflicts for review.

Next request: Measure current heads and differences again; a historic path map is only a hypothesis.

Source basis: DV-17 evidence, mechanism and delivery census — aisa-next/10 Architecture/30 Source/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

Repair this build or dependency problem.

Specific failure illustrated

The image is published after a tooling change, but a clean build or the actual deployment job still fails.

Initial solution take

The image is published after a tooling change, but a clean build or the actual deployment job still fails.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. CI configuration, runtime dependencies, lockfiles and generated schemas can change together.
2. The job identity and target environment must be explicit.
3. Generated artifacts or instruction files cannot be silently omitted from review.

Return to solution take

Fix the specific build/runtime boundary and prove the complete reproducible artifact/job path.

Reject this shortcut: Generated lock/schema changes are excluded from review and hide an incompatible dependency: reject.

Confirmation and application

1. Reproduce the failing clean build or job with the pinned toolchain and dependency graph.
2. Make the scoped CI/dependency/tooling change and review lock/schema/instruction changes with it.
3. Run a clean build and the declared runtime/job checks, then verify target use if deployment was requested.

Verification

1. The clean build is reproducible from the reviewed inputs.
2. The intended job produces the correct artifact for the named target.
3. Runtime/deployment proof accompanies registry publication where required.

Recovery

Restore compatible toolchain/config/lock versions; preserve produced artifacts and actual job effects for reconciliation.

What is retained

Memory: An image in a registry is not deployment or runtime acceptance.

Skill: Include generated and tooling-control files in the reviewable change.

Tool candidate: Automate a pinned clean-build/job/artifact verification run and report the exact failing boundary.

Next request: Reproduce on the current toolchain and inspect dependency changes before adopting the old command.

Source basis: DV-18 evidence, mechanism and delivery census — aisa-next/10 Architecture/30 Source/Typical Cases.md

Representative proposed run grounded in the documented case family. Findings and success states are scenario content, not new live observations.

Customer request

Correct this environment setting.

Specific failure illustrated

An appsettings reset overwrites an environment-specific route or secret reference.

Initial solution take

An appsettings reset overwrites an environment-specific route or secret reference.

The related procedure is a candidate until its current preconditions are checked.

Evidence to establish — investigation or the known skill’s preflight

1. The active service may read values from a different source than the edited local file.
2. Environment-specific routes are intentional differences until reviewed.
3. Secret values must remain in the existing secret store, not copied into example configuration.

Return to solution take

Apply only the approved target setting delta through the actual configuration/image release path.

Reject this shortcut: A local file reset overwrites unrelated target routes or secret references: reject.

Confirmation and application

1. Compare intended settings, local resets, target configuration sources and the consuming service.
2. Prepare the minimal reviewed value/reference change while preserving unrelated target settings.
3. Deploy through the declared path and exercise the integration that consumes the setting.

Verification

1. The active service reads the intended target value.
2. The required route/integration works.
3. Unrelated routes and secret references are preserved.

Recovery

Restore the recorded prior target value/reference via the same release mechanism; never restore an entire developer-local file over the target.

What is retained

Memory: A local reset is not evidence that the target should match the developer's defaults.

Skill: Keep per-environment setting meaning and consumption in the deployment checklist.

Tool candidate: Automate a redacted target-setting diff and a focused consumption probe, showing references rather than secrets.

Next request: Read the effective setting and target lineage; never copy one environment's complete file.

Source basis: DV-19 evidence, mechanism and delivery census — aisa-next/10 Architecture/30 Source/Typical Cases.md