CtrlK
BlogDocsLog inGet started
Tessl Logo

sdas/leg-spec-from-code-oracle

Extract a complete, source-traceable legacy evidence specification for one Oracle Forms module from Forms XML/FMT/FMB/FMX, PLL/PLD, DDL, message catalogues, menus/object libraries, and screenshots. Use for fresh or incremental reverse engineering when the output must preserve every evidenced screen region, tab, field, operation, rule, message, database dependency, provenance locator, uncertainty, and source-supported detail without inventing target requirements, target architecture, target tests, POC assumptions, or implementation decisions.

66

Quality

83%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Overview
Quality
Evals
Security
Files

specification-template.mdreferences/

Oracle Module Legacy Evidence Specification Template

This template is an executable output contract. It describes legacy evidence only. It must not contain target requirements, target UI design, target architecture, target tests, migration treatment, POC assumptions, or feasibility/readiness conclusions.

Use one package ID, MOD-<MODULE-ID>. Use semantic local keys only for material sections, tabs, grids, operations, and rules. Identify fields by their natural BLOCK.ITEM locator.


artifact_kind: legacy_evidence_specification module_id: MODULE module_evidence_id: MOD-MODULE evidence_fingerprint: SHA256 extraction_run_id: RUN extraction_mode: fresh legacy_evidence_status: extracted_with_open_gaps comparison_oracle_sha256: not-supplied operation_details: MODULE-operation-details.md decoded_source: MODULE-decoded-source.md database_reference: MODULE-database-reference.md

— Legacy Evidence Specification

1. Document Control

Module scope, run identity, source fingerprint, extraction mode, and evidence boundary.

2. Evidence Summary

Source-backed capability and coverage summary.

3. Legacy Screen Overview

Windows, canvases, interaction pattern, and screenshot links.

Visible regions, tabs, grids, and section keys.

4. Module Structure

Every block, relation, canvas, window, tab page, attached library, menu, and called module with its extracted properties. Counts alone are not sufficient.

5. Legacy Capability Inventory

Source-backed module capabilities grouped by operation and screen region.

6. Operation Behavior Ledger

One concise row per query, insert, update, delete, validation, save/commit/rollback, or custom-action path. Summarize triggers/preconditions, business/data effects, messages/outcomes, confidence, and gaps; link each row to the complete normalized record in the operation-detail child. Do not place exhaustive normalized collections in master table cells. These are legacy behavior records, not target requirements.

7. Screen Layout And Regions

Canvas, tab, section, and grid structure with semantic local keys.

8. Field And Control Evidence

One subsection per visible section, tab, or grid, plus hidden/helper items. Every Forms item appears once or is explicitly cross-referenced. Each resolved item mapping includes the authoritative physical DDL type as TABLE.COLUMN (TYPE).

9. Query And Retrieval Evidence

Query data sources, clauses, ordering, criteria behavior, LOVs, and relevant SQL.

10. Record Selection And Master-Detail Evidence

Row identity, relations, coordination, selection effects, and detail navigation.

11. Actions And Buttons

Buttons, key triggers, custom commands, navigation, and observable outcomes.

12. Business Rules And Validation

Source-backed conditions, branches, validation, calculations, and outcomes. Use the columns Applies during | Business condition | Message code | Message text | Effect | Association basis | Source. Bind a message to a condition only when it occurs inside the active decoded IF/ELSIF branch in the same unit or another explicit control-flow relation proves it; preserve unbound messages explicitly and never repeat a path-wide message set for every rule.

Delete, save, commit, rollback, dependency, and transaction evidence. Include a complete inbound foreign-key matrix for each selected persistence object and distinguish it from the narrower set of dependencies checked by Forms routines.

13. LOV And Lookup Evidence

LOV, record-group, lookup query, return mapping, validation, and default evidence.

14. Workflow And State Evidence

Legacy mode/state transitions and runtime property changes.

15. Data Model And Database Mapping

Referenced database objects and item-to-column mappings.

Constraints, keys, cascades, and dependency evidence.

Database and Forms defaults, plus required audit-column population ownership. If ownership is not established by a DDL default, decoded assignment, or supplied database trigger, render an explicit evidence gap.

16. Data Retrieval And Processing Logic

SQL, call chains, calculation logic, processing order, and side effects.

17. Error And Message Catalogue

Message codes/text, conditions, severity where known, and source locators.

18. Evidenced Operational Characteristics

Only characteristics established by supplied source, such as locking, commit ownership, external calls, file or host interaction, and security-sensitive behavior. Unknown runtime qualities remain unknown.

19. Behavior Coverage Scenarios

Observed entry-condition-action-outcome slices used to check extraction coverage. These are not target application test cases.

20. Evidence Traceability

Mapping from module/group local keys and natural legacy locators to source evidence and gaps.

21. Conflicts, Unknowns, And Open Evidence Questions

Conflicting evidence, unresolved calls, unreadable sources, missing artifacts, and questions that require more evidence or human clarification.

22. Appendices

Appendix A. Source And Screenshot Inventory

All relevant source files and every plausibly associated screenshot, including link, association basis, confidence, hash, readability, and parse disposition.

Appendix B. Item Evidence Inventory

Every Forms item with natural BLOCK.ITEM locator, region/tab/grid placement, properties, mapping, and evidence status.

Appendix C. Trigger And Program Unit Inventory

Compact inventory summary and link to the decoded-source child. The child preserves every decoded trigger and program unit, including source, scope, calls, SQL, messages, parse status, exact full decoded source, and source hash. Exact call arguments and sequence SQL must remain visible package-wide.

Appendix D. Legacy Event And Outcome Mapping

Legacy event, entry point, call chain, database effects, messages, navigation, and observable outcome.

Appendix E. Framework And External Boundary Evidence

Framework calls, attached libraries, menus, called modules, host/file/report interactions, unresolved boundaries, and exact evidence limits.

Appendix F. DDL Inventory

Compact DDL package index and link to the database-reference child. Section 15 retains material persistence, relationship, delete, default, and audit evidence; the child preserves relevant tables, views, sequences, synonyms, packages, triggers, constraints, every column with physical type/default/nullability, dependencies, and source locators. Do not duplicate the exhaustive DDL representation in both Section 15 and Appendix F, and do not use truncation placeholders.

Appendix G. Technical Evidence Notes

Source-supported comparison anchors, SQL notes, precedence decisions, conflicts, and technical extraction notes.

Appendix H. Glossary

Legacy terms, Forms terminology, abbreviations, and domain labels present in source.

Appendix I. Extraction Coverage And Missing Sources

Coverage denominators, accounted/extracted/unknown counts, and status by evidence dimension.

Precise gaps with affected behavior, current fallback evidence, confidence impact, and acquisition/validation action.

Appendix J. Extraction History

Run fingerprint, compiler version, mode, source delta, comparison oracle, and changed evidence dimensions.

SKILL.md

tile.json