smill/otko
Watch
1
0
Fork
You've already forked otko
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
otko/specifications
History
Exact
Repository files (latest commit first)
Filename Latest commit message Latest commit date
smill f361fee969 feat: named case-result load combinations with full GUI support 
Snapshots the current development tree, headlined by proper load
combinations (user request): a reusable LoadCombination entity of
weighted completed static-case results (e.g. 1.2xDead + 1.6xLive).

- core: LoadCombination/LoadCombinationItem entities, Project
  integration (lookup, unique ids, reference validation)
- services: combinations.py (linear superposition + envelope),
  exported via services __init__
- commands: undoable Add/Delete/Update for combinations
- GUI: Load Combinations manager dialog, Run-dialog evaluation,
  envelope display in Results panel, Combinations tab in Table dock
- tests: unit coverage (validation, math, error paths) + integration
  superposition check vs a single factored run
2026-09-11 13:19:59 -04:00
..
15-rebuild-adoption-plan.md feat: named case-result load combinations with full GUI support 2026-09-11 13:19:59 -04:00
README.md feat: named case-result load combinations with full GUI support 2026-09-11 13:19:59 -04:00

README.md

OTKO — specifications (this repo)

This folder holds OTKO's own planning documents. It is deliberately separate from the greenfield rebuild spec set at ~/Sync/otko-development/specifications (docs 00–14), which stays the reference for what a conformant rebuild looks like. Requirement IDs of the form [AREA-NNN] cited in this folder refer to that rebuild set.

Why this folder exists

~/Sync/otko (this repo) is the working, feature-rich app and is the primary deliverable. ~/Sync/otko-development is a greenfield rebuild that conforms closely to the rebuild specs but is less capable in several areas (transient/pushover/response-spectrum, richer element/material coverage, .osmodel corpus, HDF5). The goal of the plan below is to harvest the rebuild's good, spec-conformant capabilities into this app without breaking what already works — not to rewrite this app to the rebuild's architecture.

Documents

# Document Purpose
15 15-rebuild-adoption-plan.md Dependency-ordered plan for porting rebuild capabilities into this repo, with adoption matrix, phases, gates, risks and explicit skips.

Ground rules (summary — see doc 15 §3)

  • Additive, never replacement. This repo is a superset of the rebuild in the solver/runner/export surface; protect that.
  • Keep the working app working: .osmodel format, AGPL-3.0 license, Python 3.10–3.12 support, existing tests green.
  • Adapt, don't copy: re-type ported code to this repo's APIs (StaticResults/ModalResults, mutable Project, 4-value UnitSystem).
  • One phase = one branch = independently shippable, each with its own tests and gate.
  • License hygiene: the rebuild is MIT, this repo is AGPL-3.0; MIT→AGPL is compatible, but ported files need attribution (see doc 15 §7).