Skip to content

[P30] [Team Management] Build dynamic training profile benchmarks from league data #30

Description

@MostDef2000

Problem

On https://slf.fm/train.php, SLF currently shows a static reference table SLF Training Profiles v1 with skill benchmarks for training profiles.

User wants this table to be generated dynamically from real league/player data instead of being hardcoded.

Desired behavior

Build the training benchmark table dynamically for https://slf.fm/train.php.

The table should continue to show training profile benchmarks, but the values should be calculated from source pages/data.

Benchmark logic idea

Top profile values

For the top column:

  • calculate based on Top 5 players by average skill level from championship/player data;
  • primary source idea:
    • https://slf.fm/additional.php?action=talent2

Normal / average profile values

For the normal / average column:

  • calculate based on development/training growth level from Top 6-10 leagues;
  • use previous season data, not current season data;
  • reason: current season growth values are based on about 50% of current playing time and become reliable/available only later in the active season.

Example source page for previous season championship stats:

  • https://slf.fm/champ.stat.php?id=53597

Growth/change indicators

In the training profile benchmark table, also show which skills increased.

Suggested visual principle:

  • reuse the existing arrow concept from player skill growth indicators;
  • green arrow = increased / stronger growth signal;
  • white/neutral arrow = unchanged or neutral;
  • red arrow = decreased / weaker signal.

Exact indicator semantics must be defined during implementation discovery.

Manual source configuration idea

Because parsing previous seasons may require knowing championship IDs, support a manual configuration mechanism.

Possible UX options:

  • user manually enters one championship ID for the growth segment;
  • user manually enters several championship IDs;
  • SLF generates full URLs from those IDs, for example:
    • https://slf.fm/champ.stat.php?id=53597
  • user can separately define IDs for:
    • top benchmark source;
    • normal/average growth benchmark source;
    • Top 6-10 league growth data.

The first implementation may be manual-ID based if automatic previous-season discovery is too risky.

Scope

Responsible agent: Team Management Agent
Branch: team-management
Page: https://slf.fm/train.php
Area: training profile benchmark table / SLF Training Profiles v1

Allowed source area:

  • src/modules/team-management/**
  • training reference guide / training profiles modules
  • storage/cache helper only if required
  • bundle-order/module-registry only if new runtime files are required

Required discovery before implementation

Team Management Agent must investigate before writing code:

  • How current SLF Training Profiles v1 values are stored and rendered.
  • Whether additional.php?action=talent2 can be parsed reliably from the userscript context.
  • What data exists on champ.stat.php?id=<id> and whether it contains the needed previous-season growth information.
  • Whether cross-page fetching is allowed from the userscript on the same domain.
  • Whether this requires caching due to slow page fetches.
  • Whether role mapping is available or must be inferred from player positions.
  • How to handle unavailable/partial data.

Suggested staged implementation

This is likely too large for one blind implementation. Prefer staged work:

Stage 1 — Research / parser prototype

  • Inspect current pages and DOM structures.
  • Define source data model.
  • Decide whether manual championship IDs are required.
  • Return implementation plan and risks.

Stage 2 — Manual-ID dynamic table

  • Add configuration UI for championship IDs.
  • Fetch/parse source pages.
  • Build calculated profile table.
  • Cache parsed values if needed.

Stage 3 — Growth indicators

  • Add skill growth indicators based on previous-season/current benchmark deltas.
  • Reuse existing arrow-style visual language where possible.

Stage 4 — Automation refinement

  • Investigate automatic previous-season championship discovery.
  • Reduce manual ID entry if safe.

Out of scope

  • Do not remove the existing static preset table until dynamic data is verified.
  • Do not change training application logic from issue [P29] [Team Management] Apply training preset to selected players #29 unless explicitly included.
  • Do not change Transfer Analyzer.
  • Do not change Strategy Data.
  • Do not change release artifacts manually.
  • Do not bump version from the module branch.
  • Do not commit tokens/secrets.

Acceptance criteria

Initial acceptable version:

  • On /train.php, user can configure one or more championship IDs for benchmark parsing.
  • SLF forms valid source URLs from the IDs, e.g. https://slf.fm/champ.stat.php?id=53597.
  • SLF can generate or preview a dynamic benchmark table from parsed data.
  • Static hardcoded table remains available as fallback if parsing fails.
  • Errors are shown as clear non-blocking messages.
  • Data source season/currentness is visible to the user.
  • No release files are changed by the module branch.

Final target version:

  • top values are based on Top 5 by average skill level.
  • normal values are based on Top 6-10 league previous-season growth/progression data.
  • Skills with growth changes are visually marked using arrow-style indicators.

PM planning

Complexity: XL
Risk: high
Recommended order: later / after issue #29 and after parser discovery
Type: Feature / Research / Data parsing
Reason:

  • Requires parsing external SLF pages and previous-season championship data.
  • Data availability and DOM shape are unknown.
  • Needs caching/fallback design to avoid making /train.php slow or fragile.
  • Should be staged as research first, then implementation.

Required agent flow

  1. Work by contracts/branches/team-management.md.
  2. Perform Branch Freshness Check before implementation.
  3. Start with research/discovery unless the user explicitly approves implementation.
  4. Return a parser/data model plan before code changes.
  5. After implementation, return COPY-READY MESSAGE FOR CORE RELEASE AGENT.

Metadata

Metadata

Assignees

No one assigned

    Projects

    Status
    Inbox

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions