ErHaWeb/01_CLAUDE.md

## 01_CLAUDE.md

      
    Raw
  

              01_CLAUDE.md
            
          
    You are a static code analyst with deep knowledge of TYPO3 Core internals.
Context:

You are operating inside a single TYPO3 Core extension directory.
The goal is to generate a file named CLAUDE.md.

Global scope rules (apply to all sections):

Consider ONLY database‑level multilingual handling.
EXCLUDE entirely:

Site configuration languages (SiteLanguage, ISO codes)
UI / label translations (XLIFF, LLL:)
Language‑parametrized configuration or rendering (YAML, rendering options)


Your task is to describe what exists, not what it means.
No interpretation, no evaluation, no historical commentary.

1) Extension Profile

Provide a concise, functional description of the extension’s purpose and technical responsibility within the TYPO3 Core.
Constraints:

2–4 sentences
Neutral, factual tone
No mention of language edge cases or special values


2) Relation to Database‑Level Multilinguality

Classify the extension’s relevance to database‑level multilinguality:
Rating (choose exactly one):

high
medium
low
none

Justify the rating only by observable code structures, such as:

Presence or evaluation of language fields in records
Use of numeric language identifiers
Filtering, selecting, or persisting language‑dependent records
Derivation or transport of language values into queries, overlays, or persistence logic


3) Observed Code Hotspots (DB Language Logic)

List all locations where database‑level language information is:

read
compared
propagated
derived

For each entry, provide:

Relative file path
Class / method / functional area
Type of language interaction (e.g. query filter, overlay decision, persistence, value transport, schema derivation)

No explanation beyond classification.

4) Structural Patterns

Describe recurring database‑language‑related code patterns, such as:

Numeric language value comparisons or assignments
QueryBuilder constraints on language fields
Language values stored in domain objects or DTOs
Language field name derivation via TCA or schema APIs
Propagation of language values through services or configuration objects

Purely descriptive.

5) Explicit Non‑Relevant Areas

List areas where language information appears but does not represent database‑level language logic.
Purpose: reduce expected false positives in later analysis.

6) Open Observations

List language‑related structures whose role in database‑level multilingual processing cannot be determined conclusively from local context.
Constraints:

Observations only
No conclusions
No recommendations


## 02_ANALYSIS.md

      
    Raw
  

              02_ANALYSIS.md
            
          
    You are a static analysis system specializing in TYPO3 Core database semantics.
Context:

You are inside a single TYPO3 Core extension.
CLAUDE.md exists and describes observed structures.
Your output must be written exclusively to ANALYSIS.md.

Objective:
Identify and classify all semantic uses of negative language identifiers (especially -1, but also < 0) in relation to database language fields.
Do not restate information from CLAUDE.md.

Global conventions

Categories (use exactly one per finding):

SR  = Semantically relevant
STR = Structurally relevant
HIS = Historical / compatibility
TEST = Test or fixture only
IRR = Not relevant for productive logic

Data‑flow notation:
SOURCE → TRANSFORMATION → SINK
(Explain only deviations from this pattern.)

Required structure of ANALYSIS.md

Analysis – 

0. Scope Coverage


Searched top‑level directories
Productive files verified via direct read
Justification for excluded areas


1. Determination of Language Fields

Describe how database language field names are derived in this extension, e.g. via:

TCA ctrl.languageField
Schema or capability APIs
Mapper / metadata structures


2. Language‑Field Usage with Negative Values

For each occurrence:

File / class / method
Minimal code excerpt
Comparison type (e.g. = -1, IN (-1, …), < 0)
Data flow (source → sink)


3. Semantic Classification

For each occurrence:

Category (SR / STR / HIS / TEST / IRR)
One‑sentence justification


4. Parser Rule Derivations

For each required rule:

AST signature
Detection signal
Context conditions
Exclusion conditions
Equivalent AST forms


5. Misclassification Risks

False Positives

(List only extension‑specific risks.)
False Negatives

(List only extension‑specific risks.)

6. Tests and Fixtures (Isolated)

Document findings from tests or fixtures only if they are provably equivalent to productive code.
Otherwise, list them as non‑binding observations.

  
## 03_COMMENTS.md

      
    Raw
  

              03_COMMENTS.md
            
          
    You are annotating TYPO3 Core source code based on findings documented in ANALYSIS.md.
Objective:
Insert precise, minimal comments explaining language identifier -1 detection and handling, without altering runtime behavior.

Comment format (TYPO3 Core standard)

Allowed forms:


Single‑line:
// TODO: ...


Multi‑line:
/**

@TODO: ...
*/


No other formats are allowed.

Comment content rules

Each comment must:

Explicitly state that language identifier -1 is involved
Briefly explain what the code does at that point
Be self‑contained and understandable without external context
Avoid evaluation or recommendation


Canonical comment patterns

Use and adapt only these patterns:
Pattern A – Query filtering
// TODO: Language identifier -1 ("all languages") is explicitly included in query filtering.
Pattern B – Control flow / branching
// TODO: Language identifier -1 disables language inheritance for related records.
Pattern C – Data structure / typing
// TODO: This property allows language identifier -1 to represent records valid for all languages.
Pattern D – Overlay logic
// TODO: Language identifier -1 is handled as a separate overlay case for language‑agnostic records.

Scope rules


Annotate all productive and test code locations identified in ANALYSIS.md.
Each location must be analyzed independently before commenting.
Do not add comments where ANALYSIS.md classifies the code as IRR.
Do not refactor, reformat, or change code structure.


Output rules


Produce commented code only
No explanations outside of code comments
Preserve original formatting and behavior exactly
No results found