TEKNIK — THE FOUNDATION MODULE

Everything downstream depends on this. No order, no production, no test can exist without data defined here.

February 2026 • Solen Kablo • Living Document

1. WHAT TEKNIK DOES

The Teknik module answers five questions that the entire factory depends on:

1. What cables can we produce? — Cable Playground designs them. Cable Database stores the approved results. Every cable is defined as an ordered sequence of machine steps with exact parameters.
2. What machines do we have? — Machine Management registers all 7 machine types with their physical capabilities (speed ranges, diameter limits, thickness ranges). The Playground uses these to validate that a design is physically producible.
3. What quality standards must be met? — Standards Management defines every test (IEC-EN, UL, SLN) with parameters, pass/fail criteria, and test frequencies. These are linked to cable designs — each design knows exactly which tests it requires at which production step.
4. What gets printed on the cable? — Markalama defines the ordered word arrays that the extruder prints during production (company name, standard, voltage, cross-section, etc.).
5. Who operates the machines? — Operator Management maintains the registry of production operators who are assigned to sessions.

2. THE DATA FLOW

Data flows in one direction: from Teknik outward. Here is how each submodule feeds the rest of the system.

The Cable Database is the convergence point. It stores the finalized design as structured JSON: the complete production flow, every half-product that will be created, the bill of raw materials, and all test requirements. When Sipariş calculates material needs or Üretim generates work cards, they read from Cable Database — never from the Playground or Machines directly.

3. THE DATABASE LAYER

12 tables serve the Teknik module. They fall into four groups:

Machine Tables (7)

One table per machine type. Each stores the physical capabilities of that machine as min/max/increment ranges. The system generates dropdown options by stepping through these ranges.

Every configurable parameter has a database-level CHECK constraint: max > min, increment > 0, min ≥ 0. This means invalid machine configurations are impossible to save — the database itself enforces physical sanity.

Design Tables (3)

The relationship: CableDesign → many DesignStep (cascade delete) → one CableDatabase entry on finalize. The Cable Database stores everything as denormalized JSON blobs — intentionally. When the Material Calculator needs to compute copper requirements for an order, it reads one row from cable_database and has the complete production flow without any joins.

Quality Tables (2)

A test standard has N parameters (cascade delete). When a test is assigned to a design step in the Playground, the standard ID and frequency (start/end/every reel) are embedded in the step’s JSON. This means the Cable Database carries the complete test map — Lab knows exactly what to test and when, without querying Teknik at production time.

Supporting Tables

4. THE BACKEND ARCHITECTURE

The Teknik backend is split into 6 route files mounted under /api/teknik/ and 6 utility modules that power the Playground’s simulation engine.

Route Files

Playground Engine (6 utility modules)

The Cable Playground is not a simple CRUD page — it is a real-time simulation engine that runs entirely in-memory on the backend. These are the modules that make it work:

5. THE FRONTEND

7 pages under /teknik/*, protected by the canTeknik access flag. All pages use Ant Design Pro’s ProTable with Turkish locale, client-side search, and blurred backdrop modals.

The Cable Playground alone accounts for more than half the frontend code. It is built as a modular component system: a usePlayground hook manages state and API calls, FlowCanvas renders the SVG diagram, MachineLibrary is the sidebar palette, ConfigurationDrawer holds 6 machine-specific forms (1,215 lines), and ProgressionPanel shows real-time material tracking.

6. THE SUBMODULES

The sections that follow document each submodule in full detail — every form field, every API endpoint, every database column, every validation rule, and the design decisions behind them. Ordered from foundational data to the tools that consume it.

6.1 MACHINE MANAGEMENT

Before you can design a cable, you need to tell the system what machines the factory has. Machine Management is the registry of every physical machine on the production floor — its brand, model, and most importantly, its capability ranges. These ranges (speed min/max, diameter min/max, etc.) are used throughout the system to generate dropdown options and validate that a cable design is physically producible.

6.1.1 The Seven Machine Types

The factory’s production line consists of 7 machine types, each performing a specific step in the cable manufacturing process:

6.1.2 Database Schema

7 tables, one per machine type. All share a common structure (id, brand, model, is_active, created_by, timestamps) plus type-specific parameter columns stored as min/max/increment triplets.

Common Columns (all 7 tables)

Kabatel Çekme — kabatel_cekme_machines

Kalaylama — kalaylama_machines

İncetel Çekme — incetel_cekme_machines

Buncher — buncher_machines

Extruder — extruder_machines

E-beam — ebeam_machines

Aktarma — aktarma_machines

No configurable parameters. Only the common columns (brand, model, is_active, timestamps). No CHECK constraints beyond the common ones.

6.1.3 Options Generation — The Core Mechanism

This is the mechanism that makes the entire Machine Management → Playground pipeline work. When the Playground needs to show dropdown options for a machine parameter, it calls the /options endpoint, which steps through the min/max/increment range and returns every valid value.

def generate_dropdown_options(min_val, max_val, increment):
    options = []
    current = min_val
    while current <= max_val:
        options.append(round(current, 4))  # Avoid floating point drift
        current += increment
    return options

# Example: machine with speed_min=5, speed_max=25, speed_increment=5
# → [5.0, 10.0, 15.0, 20.0, 25.0]

Special cases:

• Integer ranges (İncetel Çekme & Buncher input counts): Uses list(range(min, max + 1)) instead of float stepping — because you can’t have 3.5 input wires.
• Hardcoded values (Buncher twist direction): Returns ["S", "Z"] directly — these are the only two possible twist directions in cable manufacturing.
• No options (Aktarma): Has no /options endpoint at all — nothing to configure.

6.1.4 API Endpoints

38 total endpoints. Each machine type gets 5–6 endpoints following a consistent pattern (except Aktarma which has no /options).

Pattern per machine type (replace {type} with e.g. kabatel-cekme)

Common endpoints

Options response shapes per type

6.1.5 Permission Model

Uses check_permission_smart() which supports both the legacy user_type system and the granular permission system:

6.1.6 Frontend — The Machines Page

Single file: pages/Teknik/Machines/index.tsx (726 lines). Route: /teknik/machines, protected by canTeknik access flag.

Page Structure

A PageContainer wrapping a Card with 7 Tabs — one per machine type. Switching tabs fetches the machine list for that type and resets the search text. Default tab: Kabatel Çekme.

Table Columns

Every tab shows a ProTable with these base columns plus type-specific ones:

Type-specific columns:

• Kabatel Çekme: Hız Aralığı (speed_min–speed_max m/s), Tav Aralığı (tav_min–tav_max A), Çıkış Çapı (output_min–output_max mm)
• Kalaylama: Hız Aralığı, Kalay Kalınlığı (thickness_min–thickness_max μm)
• İncetel Çekme: Girdi Sayısı (input_number_min–max), Çıkış Çapı, Tav Aralığı
• Buncher: Girdi Sayısı, Hatve Aralığı (hatve_min–max)
• Extruder: İzolasyon Kalınlığı (insulation min–max mm), Kılıf Kalınlığı (sheath min–max mm)
• E-beam: Hız Aralığı, Radyasyon Seviyesi (radiation_level_min–max kGy)
• Aktarma: Base columns only

Search & Pagination

Search is client-side: a text input filters the loaded list by ID, brand, model, or status (“aktif”/“pasif”). No server-side search needed because machine counts are small (typically <50 per type).

Pagination defaults to 10 rows, with options [10, 20, 50, 100]. Total shown as “X-Y / Z kayıt”.

CRUD Flow

Create:

1. Click “Yeni Makine Ekle” button in the toolbar
2. Modal opens with title “Yeni Makine Ekle” (600px, blurred backdrop)
3. Form shows fields dynamically based on active tab (machine type)
4. On submit: POST /api/teknik/machines/{type} with form values
5. System fields (id, created_at, updated_at, created_by, input_type, input_code, accepted_input_codes) are automatically excluded
6. On success: toast “Makine başarıyla eklendi!”, close modal, refresh list

Edit:

1. Click edit icon in the Actions column
2. Modal opens with title “Makine Düzenle”, pre-filled with current values
3. On submit: PUT /api/teknik/machines/{type}/{id} with changed fields only
4. On success: toast “Makine başarıyla güncellendi!”, close modal, refresh list

Delete:

1. Click delete icon in the Actions column
2. Popconfirm asks: “Bu makineyi devre dışı bırakmak istediğinize emin misiniz?”
3. Delete button is disabled if machine is already inactive
4. On confirm: DELETE /api/teknik/machines/{type}/{id}
5. On success: toast “Makine devre dışı bırakıldı!”, refresh list

Form Fields Per Machine Type

The form renders dynamically via renderFormFields() based on the active tab. Common fields (Marka, Model) appear for all types. Type-specific fields use InputNumber with appropriate min, step, and Turkish labels:

6.1.7 Service Layer (Frontend)

API calls are wrapped in services/teknik/index.ts with a URL transformation: underscores in the machine type name are replaced with hyphens for the URL path.

// kabatel_cekme → kabatel-cekme in URL
export async function getMachines(type: MachineType) {
  return request(`/api/teknik/machines/${type.replace('_', '-')}`);
}

export async function createMachine(type: MachineType, data: any) {
  return request(`/api/teknik/machines/${type.replace('_', '-')}`, {
    method: 'POST', data
  });
}

// Same pattern for updateMachine (PUT), deleteMachine (DELETE)
// getMachineDropdown calls /{id}/dropdown for Playground use

6.1.8 How It Connects to Other Submodules

6.2 STANDARDS MANAGEMENT

Every cable sold must pass a set of quality tests defined by international standards bodies (IEC, CENELEC) or the customer. Standards Management is where those tests are defined — what to measure, how many samples, with which parameters, and what the reference standard number is. These definitions are then embedded into cable designs so that the Lab module knows exactly what to test and when during production.

6.2.1 Data Model

Three tables work together: standards define what to test, parameters define what to measure within each test, and results store the actual measurements from production.

test_standards

Unique constraint: (standard_category, test_name, standard_number) — prevents duplicate test definitions within the same standards body.

test_parameters

Unique constraint: (test_standard_id, parameter_name) — no duplicate parameter names within a single test.

test_results

Measurement storage: The measurements column stores a JSON array. Each entry is a MeasurementData object with parameter (name), values (float array), optional unit, and optional per-parameter result. The model has helper methods: get_measurements() parses the JSON, set_measurements() serializes it, and evaluate_result() returns PASS/FAIL/PENDING based on whether all required parameters have values.

6.2.2 Relationships

Delete behavior is smart: if a standard has test results, it is soft deleted (is_active = false) to preserve result traceability. If it has no results, it is hard deleted. Parameters always cascade — deleting a standard removes all its parameters.

6.2.3 API Endpoints

12 endpoints organized into three groups: standards CRUD, parameter management, and test results.

Test Standards

Test Parameters

Test Results

Reference Data

6.2.4 Test Frequencies — When Tests Run

When a test is assigned to a cable design step in the Playground, the user selects a frequency that tells the Lab when to execute the test during production:

6.2.5 How Standards Connect to Cable Designs

This is the critical integration point. When the Playground configures a machine step, tests are fetched and filtered by the design’s standard category:

# In db_integration.py — fetches tests matching the design's standard
def get_tests_by_standard(db, standard):
    # Maps frontend code to database category
    category_map = {'EN': 'IEC-EN', 'UL': 'UL', 'SLN': 'SLN'}
    category = category_map.get(standard, standard)

    standards = db.query(TestStandard).filter(
        TestStandard.standard_category == category,
        TestStandard.is_active == True
    ).all()
    return [{'id': s.id, 'test_name': s.test_name, ...} for s in standards]

When a design is finalized, the assigned tests are stored as a JSON array in cable_database.test_requirements:

# Storage format in cable_database.test_requirements
[
  {
    "step": 3,
    "machine_type": "extruder",
    "test_id": 12,
    "test_name": "Çekme Dayanımı",
    "standard_number": "EN 50618",
    "frequency": "her_ikisi"
  }
]

6.2.6 Permission Model

Note: lab_user has wider access here than in Machine Management — this is intentional because lab personnel are the primary users of the standards system.

6.2.7 Frontend — Standards Page

Single file: pages/Teknik/Standards/index.tsx (553 lines). Route: /teknik/standards.

Page Structure

PageContainer with a ProTable and a modal for create/edit. No tabs — all standards shown in one table, category distinguished by color-coded tags.

Table Columns (9)

Create/Edit Modal (800px, blurred backdrop)

The modal contains 7 form fields plus a dynamic parameter list:

Parameter Management (inside modal)

Below a “Test Parametreleri” divider, each parameter is rendered as a small Card with two fields:

• Parametre Adı — Input, placeholder “Parametre Adı (örn: Çekme Dayanımı, Uzama, Direnç)”
• Birim — Input, placeholder “Birim (örn: N/mm², %, ohm/km)”

“Parametre Ekle” button (dashed, full-width) adds a new empty parameter card. Each card has a delete button in the header. Order is auto-assigned sequentially. On update, all existing parameters are replaced with the new set (delete all + create new).

CRUD Flow

Create: Click “Yeni Test Standardı” → Modal opens → Fill category, name, standard number → Optionally add parameters → Click “Ekle” → POST /api/teknik/standards/tests → Toast “Test standardı başarıyla eklendi!” → Modal closes, list refreshes.

Edit: Click edit icon → Modal opens pre-filled → Modify fields/parameters → Click “Güncelle” → PUT /api/teknik/standards/tests/{id} → Toast “Test standardı başarıyla güncellendi!” → Modal closes, list refreshes.

Delete: Click delete icon → Popconfirm “Bu standardı devre dışı bırakmak istediğinize emin misiniz?” → DELETE /api/teknik/standards/tests/{id} → Toast “Test standardı devre dışı bırakıldı!” → List refreshes. Delete button disabled for already-inactive standards.

Search & Pagination

Search is client-side (200px rounded input). Searches across ID, category, test name, standard number, test type, sample count, and status (aktif/pasif). Pagination defaults to 10 rows with [10, 20, 50, 100] options. Sorted by ID descending (newest first).

6.2.8 How It Connects to Other Submodules

6.3 OPERATOR MANAGEMENT

Production operators are the people running the machines on the factory floor. They don’t need system logins — they are simply names in a registry that get assigned to production sessions when someone starts a manufacturing run. This is the simplest submodule in Teknik (284 lines of frontend, 4 endpoints), but its data appears in every production session, every work card, and every half-product record.

6.3.1 Database Schema

production_operators

That’s the entire table. Five columns. No foreign keys, no relationships, no JSON blobs. The UNIQUE constraint on name is the only business rule — you can’t have two operators with the same name.

6.3.2 API Endpoints

4 endpoints under /operators. Notably, there are no role checks beyond authentication — any logged-in user can manage operators. No Pydantic schemas either; the routes accept and return raw dictionaries.

Validation Details

6.3.3 How Operators Are Used in Production

This is where the simple name registry becomes critical. When a production session starts, the operator is assigned and their name is stored directly in the session record:

# In production_routes.py — starting a production session
if request.operator_id:
    prod_operator = db.query(ProductionOperator).filter(
        ProductionOperator.id == request.operator_id
    ).first()
    if prod_operator:
        operator_name = prod_operator.name

# Stored in production_sessions table:
# operator_id  → current_user.id (FK to users, for DB integrity)
# operator_name → prod_operator.name (denormalized, for history)

The Dual Storage Pattern

Production sessions store operator information in two ways:

This separation exists because the system tracks both who is logged in (the user account, stored as operator_id FK) and which production operator is physically running the machine (the name from this registry, stored as operator_name). The operator selects their own name from a dropdown when starting a production session for a work card that was pre-planned by the production manager.

Operator in the Production Lifecycle

• Session Start: Production page fetches operators with GET /operators/list?active_only=true. The operator selects their own name from the dropdown before starting a pre-planned work card. Required to start.
• Mid-Session Change: Operators can be swapped during a session via POST /production/update-operator — useful for shift changes.
• Half-Product Tracking: Stock pages enrich half-product records with operator_name from the production session that created them.
• History: Production history pages show operator name for every completed session.

6.3.4 Frontend — Operator Page

Single file: pages/Teknik/OperatorYonetimi/index.tsx (284 lines). Route: /teknik/operator-yonetimi. The smallest page in the entire Teknik module.

Table Columns (3)

No status column, no timestamps. Just the name. The is_active and created_at/updated_at fields exist in the data interface but are not displayed.

Create/Edit Modal (400px, blurred backdrop)

One field:

CRUD Flow

Create: Click “Yeni Operatör” → Modal (400px) → Enter name → Click “Oluştur” → POST /api/operators/create → Toast “Operatör oluşturuldu” → Modal closes, list refreshes.

Edit: Click edit icon → Modal pre-filled → Change name → Click “Güncelle” → PUT /api/operators/{id} → Toast “Operatör güncellendi” → Modal closes, list refreshes.

Delete: Click delete icon → Popconfirm “Operatörü silmek istediğinize emin misiniz?” → DELETE /api/operators/{id} → Toast “Operatör silindi” → List refreshes.

Search & Pagination

Search is client-side (200px input). Filters by name and ID (case-insensitive). Pagination defaults to 20 rows (higher than other pages, since the operator list is short), with [10, 20, 50, 100] options.

How Operators Appear in Production Pages

Production pages (KabatelÇekme, Kalaylama, etc.) show operator selection in two states:

• Before session: A Select dropdown with UserOutlined icon, placeholder “Operatör seçin”, populated from GET /operators/list?active_only=true. Required to enable the “Üretime Başla” button.
• During session: A card showing the current operator name with a “Değiştir” button that opens a modal listing all operators as clickable cards for mid-session changes.

6.3.5 How It Connects to Other Submodules

6.4 Markalama (Cable Marking)

Every meter of cable that leaves the factory has text physically printed on its sheath — company name, standard, voltage rating, cross-section, production year. Markalama is the submodule that manages these marking templates: ordered arrays of words/segments that the extruder machine prints during cable production.

6.4.1 Database Schema

One table. Minimal design.

Key Constraints

• UNIQUE name: No two marking templates can share the same name. Enforced at both database level (unique index) and application level (duplicate check before create/update).
• No foreign keys: The markings table has no FKs. Instead, order_cables.marking_id in the Sipariş module references this table. The relationship is consumer-side, not defined here.

6.4.2 API Endpoints

Six endpoints under /api/teknik/markings:

Validation Details

Delete Behavior

The delete endpoint is hard delete (db.delete(marking)). Unlike Standards Management, there is no smart delete logic. If a marking is referenced by existing orders, those orders retain the marking_id integer but the marking record is gone. The safer workflow is to toggle status to inactive using the /toggle-status endpoint, which hides the marking from new orders while keeping the record intact for historical lookups.

6.4.3 Pydantic Schemas

6.4.4 Dynamic Variables

Marking words support four runtime variables that get resolved during production:

Variable resolution happens at the production/extrusion layer, not in this submodule. Markalama just stores the templates with placeholder syntax. The frontend displays these as helper text in the form: “Değişkenler: {CABLE_SIZE}, {ORDER_NO}, {YEAR}, {METER}”.

6.4.5 Permission Model

Unlike Machines (which allow production_manager) or Standards (which allow lab_user), Markalama write operations are restricted to super_admin only. The check_permission_smart function validates both the role and the granular permission key. The toggle-status endpoint is an exception — any authenticated user can activate/deactivate a marking.

Permission Manifest (Frontend)

The frontend permission system defines 5 buttons for the Markalama page:

• access_page — Can view the Markalama page
• view_markings — Can see the marking list
• create_marking — Can add new markings
• edit_marking — Can edit existing markings
• delete_marking — Can permanently delete markings (critical)

6.4.6 Frontend — Page Structure

Single file: src/pages/Teknik/Markalama/index.tsx (374 lines). Route: /teknik/markalama.

Table Columns (4)

Create/Edit Modal

The modal has two form sections:

1. Name Field

• <Input> with placeholder “ör: SOLEN BEAM Standard”
• Required validation

2. Words (Dynamic List)

• Uses Ant Design <Form.List> for dynamic add/remove
• Each word is a numbered row: 1., 2., 3.… with a 550px-wide input
• Minimum 1 word enforced by custom validator
• Red <MinusCircleOutlined> to remove a word (hidden when only 1 word remains)
• Dashed “Kelime Ekle” (Add Word) button at bottom to append new rows
• On create, starts with one empty word slot
• On edit, pre-populates all existing words
• Variable hint text shown in the label: “Değişkenler: {CABLE_SIZE}, {ORDER_NO}, {YEAR}, {METER}”

CRUD Flow

Search & Pagination

Search is client-side (200px rounded input). Filters on name, status text (aktif/pasif), and word count number. Pagination defaults to 10 rows, options [10, 20, 50, 100]. Shows “X-Y / Z kayıt” total.

6.4.7 How Markings Flow Through the System

Markalama templates are reference data. They are created once in the Teknik module and then consumed at two critical points in the order-to-production pipeline:

Step 1: Order Creation (Sipariş Module)

In the order creation form, each cable entry has a “Markalama” dropdown (searchable <Select>). It shows only active markings. The user picks one, and the marking_id is stored in order_cables.marking_id (integer FK). Marking selection is required for a cable to be considered “complete” in the order form.

// Order form cable completion check (SiparisOlustur/index.tsx)
const isComplete = hasDesign && hasMeters && hasMakara
  && hasMarking && hasPrice && hasCurrency && materialsComplete;

Step 2: Work Card Generation & Production Planning

When an order is confirmed and work cards are generated:

The work_card_generator.py service resolves each cable’s marking_id to the actual marking name by querying the Marking table. Both marking_id and marking_name are embedded in the extruder work card’s material_details JSON:

# work_card_generator.py — extruder material_details
{
    'marking_id': cable_data.get('marking_id'),    # Integer FK
    'marking_name': cable_data.get('marking_name'), # Resolved text
    'tests': ex_tests,
    'breakdown': [],
    ...
}

Step 3: Production Planning Display

The Production Planning page reads the extruder work card’s material_details and displays the marking name in the card UI:

// Production/Planning/index.tsx
{materialDetails.marking_name && (
  <div>
    <div style={{ fontSize: 10, fontWeight: 600 }}>Markalama</div>
    <div style={{ fontSize: 11 }}>{materialDetails.marking_name}</div>
  </div>
)}

Step 4: Order Detail View

When viewing an existing order, the detail page shows the marking. The order_routes.py endpoint resolves marking_id to the name at query time:

# order_routes.py — marking resolution
marking_name = None
if cable.marking_id:
    marking = db.query(Marking).filter(Marking.id == cable.marking_id).first()
    marking_name = marking.name if marking else None

This pattern appears twice in order_routes.py: once for the single order detail endpoint, and once for the work card generation data extraction.

6.4.8 Data Storage Pattern — ID vs Name

6.4.9 Connections to Other Submodules

6.5 & 6.6 Kablo Tasarım (Cable Playground) & Kablo Veritabanı (Cable Database)

These two submodules are documented together because they are inseparable: Playground is where cables are designed step-by-step using real factory machines, and Cable Database is the permanent repository where finalized designs are stored. Every other module in the system — Orders, Production Planning, Work Cards, Material Calculations, Stock — ultimately depends on the records that Playground creates and saves into Cable Database.

6.5.1 Core Concept — How Cable Design Works

Cable manufacturing follows a strict sequential pipeline. Raw copper (8mm filmaşin) enters the first machine and is progressively transformed through 6 machine types until a finished cable emerges. The Playground simulates this entire process digitally.

The Six Machine Types (in order)

Machine Flow Constraints

Not every machine can follow every other machine. The system enforces a directed graph:

Critical loop capabilities:

• Buncher → Buncher: Multi-stage bunching (bunched wire can be re-bunched)
• Extruder → Extruder: Multi-layer extrusion (insulate first, then sheath)
• Extruder → Buncher: Multi-core cables (insulate individual cores, then bunch them together, then sheath)

# Machine flow constraints (playground_session.py)
MACHINE_FLOW = {
    'kabatel_cekme': ['kalaylama'],
    'kalaylama':     ['incetel_cekme', 'buncher'],
    'incetel_cekme': ['buncher', 'extruder'],
    'buncher':       ['extruder', 'buncher'],    # Self-loop!
    'extruder':      ['ebeam', 'extruder'],      # Self-loop!
    'ebeam':         []                          # Terminal
}

6.5.2 Backend Architecture — The Engine

The Playground backend is built from 8 Python files totaling ~4,700 lines:

Session Management (In-Memory)

Sessions are stored in a Python dictionary (_active_sessions: Dict[str, PlaygroundSession]). Each session contains:

• session_id: UUID v4
• standard: EN / UL / SLN (selected at session start)
• cross_section: e.g. “6mm²” (selected at session start)
• steps: List of DesignStep dataclass instances
• progression: ProgressionManager instance tracking all items
• history_stack / redo_stack: StateSnapshot lists (max 50) for undo/redo
• autosave: enabled by default, 30-second interval, tracks unsaved changes

The Progression Panel — Heart of the Design

The ProgressionManager maintains a list of ProgressionItem objects. Each item represents a physical product (wire, bunched wire, cable) at some stage of manufacturing:

# ProgressionItem fields
{
    'id': 'uuid',                    # Unique identifier
    'code': 'KC_18',                 # Deterministic product code
    'quantity': 21,                  # Current available amount
    'original_quantity': 21,         # Amount when first produced
    'structure': '1.8mm',            # Structure formula
    'specification': '1.8mm Tel',    # Human-readable name
    'status': 'active' | 'inactive', # Inactive = fully consumed
    'produced_by_step': 1,           # Which step created this
    'consumed_by_steps': [2],        # Steps that consumed from this
    'machine_type': 'kabatel_cekme', # Source machine
    'properties': { ... }            # Machine-specific data
}

Key rules:

• Session always starts with one item: RAW_COPPER_8MM (8mm filmaşin, qty 1)
• When a step consumes items, their quantity decreases. At 0, status becomes inactive.
• When a step produces items, new ProgressionItems are created and added.
• Each machine type has its own process_* method that handles consumption/production logic.
• Same-code items are combined (quantity added) unless they’re parallel process outputs.

Quantity Tracking Example — 6mm² Cable

Atomic Transactions with Checkpoint/Restore

Every configuration attempt is wrapped in an atomic transaction:

The StateSnapshot captures the complete session state (steps + progression items + consumption log + step counter). On failure, the session is restored to exactly its previous state.

6.5.3 API Endpoints — 30+ Endpoints

Session Management

Step Management

Form Data (per machine type)

Machine Configuration (per type)

Capability Intersection

Undo/Redo & Autosave

Validation & Finalization

6.5.4 Machine Configuration Schemas

Each machine type has a Pydantic schema defining its exact form fields in order:

6.5.5 Capability Intersection — Multi-Machine Flexibility

When a user selects multiple alternative machines for a step, the system computes the intersection of their capability ranges. Only values that all selected machines can produce appear in the dropdowns.

# Machine A speed options: [5, 10, 15, 20, 25]
# Machine B speed options: [10, 15, 20, 25, 30]
# Intersection: [10, 15, 20, 25]
# This means any value from the intersection can be
# produced on ANY selected machine → production flexibility

This is called dynamically via POST /calculate-intersection/{machine_type} every time the user checks or unchecks a machine checkbox in the configuration drawer.

6.5.6 Deterministic Code Generation

The CableCodeGenerator ensures that identical products always get the same code, critical for stock management:

A SHA256 spec_hash is computed from the full specifications (product_type + machine_type + inputs + outputs + parameters) with sort_keys=True for determinism. If a product with the same hash already exists in product_codes, its existing system_code is returned. Otherwise, a new code is generated with collision-handling (sequence suffix _001, _002, etc.).

6.5.7 Special Cable Types

Twin Cables (Extruder)

Extruder supports multiple inputs for twin/triple cables. Structure uses || separator: (cable1 || cable2)+SHT_0.8mm. Frontend detects twin count from || and generates Turkish names: İkiz, Üçüz, Dördüz, Beşiz.

Multi-Core Cables (Extruder → Buncher → Extruder)

For multi-damar (multi-core) cables, the flow loops: Extruder applies insulation to individual cores, Buncher groups the insulated cores together, then Extruder applies the outer sheath. The system detects this via INS_ patterns in the structure formula.

E-beam Cables (No Catalyst)

E-beam cross-linking replaces chemical catalyst. The form integration completely hides cables with catalyst from the E-beam input dropdown — they are not shown at all, preventing invalid combinations.

6.5.8 Frontend — Playground Page

Main file: src/pages/Teknik/CablePlayground/index.tsx (947 lines) with 7 component files and 1 custom hook.

Session Start Flow

Machine Configuration Flow

CRUD Flow

The Playground is not a traditional CRUD page. It is a session-based production simulation engine. The “Create” is a multi-step design process, not a single form submit.

Create (Design a Cable):

1. Click “Oturum Başlat” (Start Session) → Modal asks for standard (EN/UL/SLN) and cross-section
2. POST /playground/start → In-memory session created with 8mm filmaşin as initial input in the progression panel
3. Drag machine from library to canvas → POST /playground/steps/add → step added to session
4. Click machine node → GET /playground/form-data/{type} → ConfigurationDrawer opens (1,215-line component)
5. Select real machines (checkboxes) → POST /playground/calculate-intersection → dropdowns update with only values all selected machines can produce
6. Fill configuration form → POST /playground/configure/{type}/{step} → progression panel updates with new outputs + quantities
7. Repeat steps 3–6 for each production machine (KC → KL → IC → BN → EX → optional E-beam)
8. System auto-saves via POST /playground/autosave (every change creates a checkpoint for undo/redo)
9. Click “Finalize” → POST /playground/finalize → atomic database transaction writes to cable_designs, design_steps, and cable_database tables simultaneously. Deterministic SHA-256 code generated. Session destroyed.

Read (Resume a Session):

1. Existing sessions persist in memory. Reload the page → GET /playground/status checks for active session
2. If session exists: canvas restores from last checkpoint with full progression state

Undo / Redo (In-Session):

1. Click Undo → POST /playground/undo → session restores to previous checkpoint
2. Click Redo → POST /playground/redo → session advances to next checkpoint
3. Each configure/add/remove action pushes an atomic checkpoint. Undo stack is unlimited within the session.

Delete (Remove a Step):

1. Right-click machine node on canvas → “Kaldır” (Remove)
2. POST /playground/steps/remove → step removed from session, progression recalculated, checkpoint created
3. Removing a step that has downstream dependents triggers cascading removal of those steps

6.6 Kablo Veritabanı (Cable Database)

6.6.1 What Gets Saved — The Finalization Process

When the user clicks “Finalize” in the Playground, the system saves three things in one database transaction:

6.6.2 Database Schema — 4 Tables

cable_designs (375 lines model)

design_steps

Unique constraint: (design_id, step_number, parallel_group)

cable_database — The Core Record

product_codes — Stock Management Bridge

6.6.3 Cable Database API — 15+ Endpoints

6.6.4 Frontend — Cable Database Page

Single file: src/pages/Teknik/CableDatabase/index.tsx (691 lines). Route: /teknik/kablo-veritabani.

CRUD Flow

Cable Database is primarily a read-heavy, write-once store. Cables enter it exclusively via Playground finalization — there is no manual “create cable” form.

Create (via Playground Finalization):

1. User finalizes a design in Playground → POST /playground/finalize
2. Backend generates deterministic cable code via SHA-256 hash of physical specifications
3. If code already exists: finalization is rejected (identical cable already registered)
4. If code is new: atomic transaction writes cable_designs + design_steps + cable_database rows in one shot
5. WebSocket broadcast to teknik room → Cable Database table refreshes for all connected users

Read:

1. Open /teknik/kablo-veritabani → GET /cable-database → ProTable lists all cables with display_name, cable_code, standard, cross_section, status
2. Client-side search filters by cable code, type, or cross-section
3. Click a cable row → Detail Drawer opens with three tabs:
   • Production Flow: GET /cable-database/{code}/production-flow → Ant Design Timeline visualization of each production step
   • Half Products: GET /cable-database/{code}/half-products → all intermediate products with properties
   • Requirements: GET /cable-database/{code}/requirements → raw materials (copper, tin, plastic, catalyst, dye) + test requirements
4. Other modules read cable data via specialized endpoints: /full (material calculator), /parsed-structure (order forms)

Soft Delete (Deactivate):

1. Click deactivate icon in the table row (requires super_admin or production_manager permission)
2. Popconfirm warning
3. PUT /cable-database/{code}/deactivate → sets is_active = false
4. Cable disappears from default list views (still accessible via active_only=false filter). Downstream modules that reference this cable code still function — deactivation prevents new orders from using it.

Hard Delete (Permanent):

1. Click permanent delete icon (requires super_admin permission only)
2. Popconfirm with strong warning text
3. DELETE /cable-database/{code}/permanent
4. Backend deletes the cable_database record + related cable_designs + design_steps (cascade)
5. WebSocket broadcast → table refreshes for all connected users
6. Danger: This is a destructive operation. If active orders or work cards reference this cable code, those references become orphaned.

Update (Stock Level — Product Codes):

1. Navigate to product codes view → GET /products/codes
2. Click stock edit on a product → PUT /products/{code}/stock (requires super_admin, production_manager, or operator)
3. Updates the stock_level field for that half/final product
4. No WebSocket broadcast for stock updates — polling-based

6.6.5 How Cable Database Feeds the Rest of the System

7. CONCLUSION

7.1 What This Document Covered

This deep dive analyzed the Teknik module across six submodules, from high-level architecture down to individual lines of code:

7.2 Architectural Principles

Several design principles recur throughout the Teknik module and define its character:

7.3 The Numbers

7.4 How Teknik Feeds the Factory

Every cable order references a cable_code from Cable Database. Every work card is generated from the production_flow JSON. Every material calculation reads half_products properties. Every quality test is assigned from the standard hierarchy defined in Teknik. The marking printed on the cable comes from the Markalama submodule. The machines that produce it are validated against capabilities stored in Machine Management.

In short: if Teknik is wrong, everything downstream is wrong. This is why the Playground uses atomic transactions, capability validation, and deterministic code generation — to guarantee that what enters the Cable Database is production-ready and correct.

7.5 Final Word