Restructure plan.md: function signatures, resource links, dependency diagram, and project scaffolding tasks

[Copilot]

Incorporates @olivia-banks's suggestions and @gvegayon's feedback to evolve plan.md from a loose task list into a structured specification with typed function contracts, resource references, a dependency diagram, and explicit project-level tasks.

Function summary table

Added a quick-reference table (placed before the detailed task entries) summarising each function's signature and input/output contract:

Function	Input → Output
validate_yaml(yaml_content: str)	raw YAML string → validated dict
build_menu(model_dict: dict)	model dict → Streamlit widgets (side-effects)
watch_parameters(model_dict, current_values)	model dict + user values → validated dict + warnings
run_model(model_dict, parameters)	model dict + params → list[dict] (per-scenario results)
generate_report(model_dict, results)	model dict + results → HTML string
save_as_pdf(html_content: str)	HTML string → PDF bytes
store_model_state(model_dict, parameters)	model + params → persisted state (side-effects)
save_current_model(model_dict, current_parameters)	model + params → YAML string on disk

Task dependency diagram

Added a Mermaid flowchart TD diagram showing the full dependency graph. The infrastructure block (Branch protection rules, AGENTS.md, Devcontainer, both GitHub Actions workflows) is shown as a mandatory prerequisite for all function implementation, with Devcontainer feeding the two Actions workflows. Inside the function block, solid arrows show data dependencies and dashed arrows show the user-interaction trigger (build_menu → watch_parameters).

Function contracts

Each task is expressed as a named function with typed Input, Output, and Steps.

Resource links added

• Code validation: CPython ast.walk for whitelisting safe AST node types in embedded Python snippets; SO YAML validation reference for schema approaches.
• Figures: prefer Streamlit's built-in charting API over raw matplotlib to reduce WASM dependency surface.
• PDF generation: WASM constraints rule out most native-binary approaches; candidates are a REST API, TeX intermediate, or browser-native window.print(). ReportLab licensing flagged for evaluation.
• Model state persistence: localStorage/sessionStorage via Streamlit's JS component API identified as the likely WASM-compatible path.

YAML schema section

Added an explicit description of all required/optional top-level sections (metadata, parameters, equations, tables, figures, current_parameters) with an annotated report template example.

New project-level tasks

Added an "Other tasks (non-function)" section covering:

• Branch protection rules (PRs only, no direct pushes)
• AGENTS.md — agent roles and conventions
• GitHub Actions workflow — agent environment setup
• GitHub Actions workflow — CI testing via uv
• .devcontainer configuration for reproducible dev environments

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[gvegayon]

Thanks for the updates, @copilot. It would be great if you can take it a step further and create a mermaid diagram showing the dependencies between tasks. The final set of tasks is rather fundamental, so, although we can start programming without having the branch protection rules and others, I think we need to finalize those first.

[Copilot]

Thanks for the updates, @copilot. It would be great if you can take it a step further and create a mermaid diagram showing the dependencies between tasks. The final set of tasks is rather fundamental,...

Done in commit 4e48f2e. Added two things to plan.md:

1. Mermaid dependency diagram (under a new "Task dependency diagram" section) — the infrastructure block (Branch protection rules, AGENTS.md, Devcontainer, both GitHub Actions workflows) is shown as a prerequisite for all function implementation, with Devcontainer feeding the two Actions workflows. Inside the function block, solid arrows show data dependencies and dashed arrows show the user-interaction trigger (build_menu → watch_parameters).

2. Function summary table (under a new "Function summary" section, placed just before the detailed ## Tasks section) — this is the same quick-reference table from the PR description, listing each function's signature alongside its input/output summary.

[gvegayon]

LGTM, thanks!