CosNFX iOS Health: Needs data

Generated 2026-06-22T21:24:40Z. Scenario .

Latest Baseline none Projects 1 Data beta-2026-06-22t21-24... AI not run
Current Project1This page is scoped to this project only.
cosnfx-ios CosNFX iOS software | 0 files | 1 inputs | 0 open todos
BETA Action Output
Ready.
Data Authenticity Real data needed

No accepted real proof reports are driving the project metrics yet. Only accepted real reports are used for metrics, graphs, claims, progress, and AI analysis. Synthetic/demo/local proof reports are quarantined.

Real Used0drives charts
Quarantined0excluded
Discovered0total reports
Next command .\dev.ps1 evidence-template -ProjectKey cosnfx-ios -ScenarioId bench-validation .\dev.ps1 record-evidence -ProjectKey cosnfx-ios -ScenarioId bench-validation -CollectionType bench -RequiredPassed -ObservationsAccepted 100
  • No quarantine reasonsNo demo/synthetic markers were found.
needs-real-data
real-data-needed

No real proof data is driving this project yet.

0 discovered report(s) are quarantined as demo/synthetic/local proof data. Charts and claims will stay empty until real evidence is imported.

Data quality 0% needs-real-data

Focus Metrics

  • No metric regressionsKeep collecting repeated runs and broader scenarios.

Next Moves

  • Software Test Pass Rate P1 | Software QA
  • Dashboard Render Smoke P1 | Frontend QA
  • Project Control Coverage P1 | Product/project manager
  • AI Recommendation Follow-Through P1 | AI/project manager

Missing Inputs

  • Repeatability Run the same scenario several times before treating a change as proven.
  • Scenario Diversity Add at least one scale or field-like scenario beside the current coastal proof.
  • Sample Scale Run proof scenarios at 100, 500, and 1000+ observations and compare the curves.
  • Source Connection Plan Register planned sources, then connect real files or folders as they become available.

Real Evidence Capture Kit

CosNFX iOS needs its first accepted real report before metrics can prove progress.

needs-real-data

Starter Scenarios

benchP0
Bench Validation Baseline

Creates the first accepted real baseline so charts and claims stop being empty.

.\dev.ps1 evidence-template -ProjectKey cosnfx-ios -ScenarioId bench-validation -CollectionType bench .\dev.ps1 record-evidence -ProjectKey cosnfx-ios -ScenarioId bench-validation -CollectionType bench -RequiredPassed -AdvisoryPassed -ObservationsAccepted 100 One measured report imports as real, required gates pass, and the dashboard shows one real run.
fieldP1
Field-Link Load Check

Connects portal/API responsiveness to real network conditions instead of local-only timing.

.\dev.ps1 evidence-template -ProjectKey cosnfx-ios -ScenarioId field-link-load -CollectionType field .\dev.ps1 record-evidence -ProjectKey cosnfx-ios -ScenarioId field-link-load -CollectionType field -RequiredPassed -ObservationsAccepted 100 -PortalHtmlBytes 1 -QueryP95Ms 1 Portal payload and query p95 are recorded from a constrained or remote path.
ciP1
CI Regression Evidence

Adds build/test pass history so project progress is not inferred only from proof runs.

.\dev.ps1 evidence-template -ProjectKey cosnfx-ios -ScenarioId ci-regression -CollectionType ci .\dev.ps1 record-evidence -ProjectKey cosnfx-ios -ScenarioId ci-regression -CollectionType ci -RequiredPassed -ObservationsAccepted 1 CI result evidence is attached and repeat failures trend down over time.

Required Report Fields

  • metadata.data_authenticityrealLets BETA accept the report as usable evidence instead of quarantining it.
  • metadata.collection_typebench | field | ci | firmware | hardware | operator | measuredTells BETA what kind of real-world source produced the measurement.
  • scenario.scenario_idstable scenario idMatching scenario ids allow before/after comparisons over time.
  • overall.required_passedtrue/falseCorrectness gates are the minimum proof before performance claims matter.
  • metrics.ingest.counts.observations.acceptedintegerSample size affects confidence in throughput, storage, and latency claims.
  • analysis.evidence[].summaryshort measured source noteKeeps the metric tied to the actual test, bench note, CI run, or field observation.
  • analysis.evidence[].sourcelog/photo/serial/CI/bench source referenceLets a reviewer trace the metric back to the file, capture, or note that produced it.

Metric Field Map

MeasurementReport FieldPriority
Software Test Pass Rateunit_test_pass_rate metrics.custom.unit_test_pass_rate P1
Code Coveragecode_coverage_percent metrics.custom.code_coverage_percent P2
Open Test Failurestest_failure_count metrics.custom.test_failure_count P2
Dashboard Render Smokedashboard_render_success metrics.custom.dashboard_render_success P1
Project Control Coverageproject_control_coverage metrics.custom.project_control_coverage P1
Blocker And Todo Flowopen_blocker_count metrics.custom.open_blocker_count P2
AI Recommendation Follow-Throughai_recommendation_follow_through metrics.custom.ai_recommendation_follow_through P1
Issue And CI Historyci_failure_rate metrics.custom.ci_failure_rate P2
Overall Health0%

Needs data. Weighted from proof, coverage, backlog, and regressions.

Needs real data
Proof Score0%

Correctness, effectiveness, and efficiency score.

Evidence Coverage0%

0 of 5 evidence signals present.

Data Quality0%

needs-real-data. Baselines, repeatability, sample size, and AI review.

Backlog Health0%

Falls as high-priority findings and open work increase.

What This Is Tracking

BETA compares the latest accepted real proof report against the previous real run with the same scenario. Quarantined demo data is listed for audit but never drives health, progress, claims, or AI analysis.

Project Progress Trends No runs 0
Latest Run Comparison No baseline 1

Progress Over Time

No progress diagnostics available.

Run Timeline No runs 0

Metric Drilldowns

No metric history has been calculated yet.

Run Timeline

No run timeline available.

Metrics Used

These are the current gauges. Each one has a direction, a latest value, and, when possible, a baseline value from a comparable run.

No active metric rows yet. Collect a real report or use the metric strategy below to decide what to measure first.

Metric Strategy

BETA uses metrics for three jobs: prove the project works, prove it is improving, and decide what work deserves attention next.

needs-real-baseline
metric family4
Proof Quality

Separates real evidence from templates, demos, and unsupported claims.

Planning use: Do this first when real_count is zero or reports are quarantined. Examples: real_report_available, required_passed, repeatability, scenario_diversity
metric family4
Effectiveness

Shows whether the build does the thing it claims to do.

Planning use: Use this when deciding whether the core workflow is ready for broader testing. Examples: observations_accepted, station_features, mesh_routes, firmware_identity_fields_present
metric family4
Efficiency

Shows whether the build does the work fast enough and cheaply enough.

Planning use: Use this after correctness is credible, or when field constraints are tight. Examples: observation_throughput_per_s, query_p95_ms, db_bytes_per_observation, portal_html_bytes
metric family4
Reliability

Shows whether good results repeat instead of appearing once.

Planning use: Use this before calling an improvement durable or release-ready. Examples: failure_rate, test_pass_rate, firmware_boot_success_rate, repeat_depth
metric family4
Project Management

Shows whether the work loop is producing useful evidence or wasting time.

Planning use: Use this to decide what to focus on, stop doing, connect, or delegate. Examples: work evidence percent, blocked/rework time, connected sources, planned measurements

Metric Purpose Map

Use this table to understand what each metric proves and what project decision it should drive.

MetricQuestionWhy ImportantPlanning DecisionDone When
Software Test Pass Rateunit_test_pass_rate What does Software Test Pass Rate prove for this project? Proves BETA is still correct while project-management and AI features are added. Use it to decide whether the next step is testing, fixing, scaling, or stopping. Pass rate holds at the project target and regressions are linked to specific work.
Code Coveragecode_coverage_percent What does Code Coverage prove for this project? Coverage shows how much of the code the passing tests actually exercise, so a green build is not hiding untested paths. Use it to decide whether the next step is testing, fixing, scaling, or stopping. Coverage holds above the project floor and does not regress against the last import.
Open Test Failurestest_failure_count What does Open Test Failures prove for this project? Failing tests point directly at what is broken right now and block any honest claim of done. Use it to decide whether the next step is testing, fixing, scaling, or stopping. Test failures reach zero and any new failure is linked to a specific change.
Dashboard Render Smokedashboard_render_success What does Dashboard Render Smoke prove for this project? The app has to rebuild and load project pages after evidence changes. Use it to decide whether the next step is testing, fixing, scaling, or stopping. Dashboard rebuild succeeds and the project page opens with the expected scoped data.
Project Control Coverageproject_control_coverage What does Project Control Coverage prove for this project? BETA needs no-command controls for setup, todos, work, evidence, reports, and AI management. Use it to decide whether the next step is testing, fixing, scaling, or stopping. Coverage rises when useful controls are added and browser-verified.
Blocker And Todo Flowopen_blocker_count What does Blocker And Todo Flow prove for this project? Open blockers explain what is behind schedule and what the project manager AI should focus on. Use it to decide whether the next step is testing, fixing, scaling, or stopping. Open blocker count trends down or each blocker has a named next action.
AI Recommendation Follow-Throughai_recommendation_follow_through What does AI Recommendation Follow-Through prove for this project? AI advice should become tracked actions whose impact can be measured later. Use it to decide whether the next step is testing, fixing, scaling, or stopping. High-value AI recommendations have a decision, owner, and result metric.
Issue And CI Historyci_failure_rate What does Issue And CI History prove for this project? Build failures, flaky tests, and unresolved issues are real workflow health signals. Use it to decide whether the next step is testing, fixing, scaling, or stopping. Failure rate and stale issue load trend down over repeated project cycles.

How To Use Metrics For Planning

  • SignalStart by collecting one accepted real report; until then BETA is planning from project context, not proving improvement.
  • SignalPick one project goal or claim.
  • SignalChoose the metric that would prove movement toward that goal.
  • SignalCollect one real baseline report or source input.
  • SignalMake one focused change or run one focused bench/field/test cycle.
  • SignalRepeat the same scenario and compare the metric to the baseline.
  • SignalUse the Manager screen to turn the result into the next priority, risk, or stop-doing item.

Project Goals Driving Metrics

  • No goals configuredUse configure-project or init-project -Goal to add goals that metrics should support.

Data Version & Model Provenance

This records exactly what generated this page, what schemas were used, and whether an Ollama model contributed advisory analysis.

beta-2026-06-22t21-...
Data version beta-2026-06-22t21-24-40z-eb2404ebe0 eb2404ebe0e2135e9197624d40fa8d633b0e6e8b0a03df367353085a7bdae33b
BETA app 0.2.0 Build Environment for Testing & Analytics
Analysis schema beta.analysis.v1 BETA deterministic engine
Generated 2026-06-22T21:24:40Z C:\Users\jdcap\Documents\Projects\BETA\.beta
AI model none AI not used; ollama model none; available=False; usable=False; source=none
Data policy deterministic source of truth Only accepted real reports are used for metrics, graphs, claims, progress, and AI analysis. Synthetic/demo/local proof reports are quarantined.
Real reports 0 Accepted reports used for metrics, graphs, claims, and progress.
Quarantined reports 0 Visible for audit but excluded from proof calculations.

Project Version Records

  • CosNFX iOS Config: v1 (explicit) | Schema: beta.project.v1 Project AI plan: not run | Profile: none | Plan: none

Data Used

This is the exact source trail behind the evidence screen. Scores are computed only from accepted real proof reports, then enriched with project plans when available.

Real reports used 0 Only accepted real reports are used for metrics, graphs, claims, progress, and AI analysis. Synthetic/demo/local proof reports are quarantined.
Quarantined reports 0 Excluded before metrics, graphs, claims, and AI analysis.
Latest report none
Latest generated none
Baseline report none No matching scenario baseline yet.
Comparison key none The latest proof report is compared with the previous proof report that has the same scenario id, duration, and step size.

Quarantined Inputs

  • No quarantined reportsNo synthetic/demo proof reports were excluded from this page.

Project Planning Inputs

  • CosNFX iOS Profile: none Plan: none AI plan: none

Claims And Evidence

This is the relevance check: every tracked metric should support a claim that matters to the system being built.

No claim coverage has been calculated yet.

Claim Evidence Reasoning

Each claim below shows the deterministic reasoning chain: source report, signal evidence, metric deltas, and caveats.

No claim reasoning has been calculated yet.

Data-Quality Checks

  • GAP Real proof report is available Accepted real reports: 0; quarantined demo/synthetic reports: 0.
  • OK Synthetic/demo reports are quarantined 0 report(s) were excluded from metrics before scoring.

QA Matrix

Claims are turned into QA targets with priorities, current evidence strength, regressions, and the next test to run.

No QA matrix has been calculated yet.

Time And Effort Focus

No effort-focus analysis has been calculated yet.

Operating Plan

Use the current proof data to choose the next narrow improvement loop.

  • P0
    Collect real evidence before optimizing The current imported reports are not accepted as real proof data, so progress and improvement claims would be misleading. Owner: Engineering | Impact: high | Confidence: thin Success: accepted real report count Evidence: A fresh matching proof report plus before/after metric comparison. Run the same scenario used by the comparable baseline. Capture report.json and import it into BETA. Check whether the target metric improved, stabilized, or regressed again. If it regresses again, profile the owning code path before adding new features.
  • P1
    Software Test Pass Rate Proves BETA is still correct while project-management and AI features are added. Owner: Engineering | Impact: high | Confidence: thin Success: Pass rate holds at the project target and regressions are linked to specific work. Evidence: A fresh matching proof report plus before/after metric comparison. Run the same scenario used by the comparable baseline. Capture report.json and import it into BETA. Check whether the target metric improved, stabilized, or regressed again. If it regresses again, profile the owning code path before adding new features.
  • P1
    Dashboard Render Smoke The app has to rebuild and load project pages after evidence changes. Owner: Engineering | Impact: high | Confidence: thin Success: Dashboard rebuild succeeds and the project page opens with the expected scoped data. Evidence: A fresh matching proof report plus before/after metric comparison. Run the same scenario used by the comparable baseline. Capture report.json and import it into BETA. Check whether the target metric improved, stabilized, or regressed again. If it regresses again, profile the owning code path before adding new features.
  • P1
    Project Control Coverage BETA needs no-command controls for setup, todos, work, evidence, reports, and AI management. Owner: Engineering | Impact: high | Confidence: thin Success: Coverage rises when useful controls are added and browser-verified. Evidence: A fresh matching proof report plus before/after metric comparison. Run the same scenario used by the comparable baseline. Capture report.json and import it into BETA. Check whether the target metric improved, stabilized, or regressed again. If it regresses again, profile the owning code path before adding new features.

Action Tracker

Actions are built from deterministic BETA guidance, manager risks, measurement gaps, and advisory AI output. Statuses are gated by real evidence availability.

beta.action_tracker.v1
Actions 49

tracked recommendations

Active 37

ready to work

Blocked 1

need real data first

Risks 7

manager risks

Avoid 4

guardrails

AI 0

advisory actions

Showing top 12 of 49 tracked actions for this scope.

StatusActionSourceMetricNext StepEvidence Needed
activeP0 Collect real evidence before optimizingThe current imported reports are not accepted as real proof data, so progress and improvement claims would be misleading. Deterministic operating plandeterministic real_report_availableaccepted real report count Run the same scenario used by the comparable baseline. Capture report.json and import it into BETA. Check whether the target metric improved, stabilized, or regressed again. If it regresses again, profile the owning code path before adding new features. A fresh matching proof report plus before/after metric comparison.
activeP0 Collect real evidence before optimizingThe current imported reports are not accepted as real proof data, so progress and improvement claims would be misleading. Deterministic work guidancedeterministic real_report_availableaccepted real report count Run a real bench, field, CI, or hardware validation and import its report.json into this project. accepted real report count
activeP1 AI Recommendation Follow-ThroughAI advice should become tracked actions whose impact can be measured later. Deterministic operating plandeterministic ai_recommendation_follow_throughHigh-value AI recommendations have a decision, owner, and result metric. Run the same scenario used by the comparable baseline. Capture report.json and import it into BETA. Check whether the target metric improved, stabilized, or regressed again. If it regresses again, profile the owning code path before adding new features. A fresh matching proof report plus before/after metric comparison.
activeP1 AI Recommendation Follow-ThroughAI advice should become tracked actions whose impact can be measured later. Deterministic work guidancedeterministic ai_recommendation_follow_throughHigh-value AI recommendations have a decision, owner, and result metric. Record AI recommendations, mark which ones were tried, and connect them to metric movement. High-value AI recommendations have a decision, owner, and result metric.
activeP1 AI Recommendation Follow-ThroughAI advice should become tracked actions whose impact can be measured later. Measurement plandeterministic ai_recommendation_follow_throughHigh-value AI recommendations have a decision, owner, and result metric. Record AI recommendations, mark which ones were tried, and connect them to metric movement. High-value AI recommendations have a decision, owner, and result metric.
activeP1 AI Recommendation Follow-ThroughThis planned metric is not active yet. Manager metric backlogdeterministic ai_recommendation_follow_throughHigh-value AI recommendations have a decision, owner, and result metric. Add this metric to a real report, CI import, bench log, field note, or manual evidence record. High-value AI recommendations have a decision, owner, and result metric.
activeP1 Connect Comparable BaselineA matching prior scenario separates real progress from one-off numbers. Missing data sourcedeterministic evidencesource connected Repeat the same scenario after changes so every metric has a before/after comparison. Repeat the same scenario after changes so every metric has a before/after comparison.
activeP1 Connect Quarantined Demo ReportsSynthetic, demo, smoke, fixture, and local proof reports stay visible for audit but are excluded from metrics. Missing data sourcedeterministic evidencesource connected Replace quarantined reports with real evidence or mark real reports explicitly with metadata.data_authenticity=real. Replace quarantined reports with real evidence or mark real reports explicitly with metadata.data_authenticity=real.
activeP1 Connect Real Proof ReportsOnly accepted real run reports drive charts, regressions, findings, claims, and AI analysis. Missing data sourcedeterministic evidencesource connected Import real bench, field, CI, hardware, or project proof reports with no demo/synthetic/local-proof markers. Import real bench, field, CI, hardware, or project proof reports with no demo/synthetic/local-proof markers.
activeP1 Connect RepeatabilityMultiple runs expose noise, flaky behavior, and repeated regressions. Missing data sourcedeterministic evidencesource connected Run the same scenario several times before treating a change as proven. Run the same scenario several times before treating a change as proven.
activeP1 Connect Sample ScaleLarger samples make performance, storage, and reliability claims harder to fake. Missing data sourcedeterministic evidencesource connected Run proof scenarios at 100, 500, and 1000+ observations and compare the curves. Run proof scenarios at 100, 500, and 1000+ observations and compare the curves.
activeP1 Connect Scenario DiversityMore scenarios reduce the risk of proving only one narrow demo path. Missing data sourcedeterministic evidencesource connected Add at least one scale or field-like scenario beside the current coastal proof. Add at least one scale or field-like scenario beside the current coastal proof.

AI can suggest actions, but BETA only treats metrics, imported inputs, proof reports, and work logs as evidence.

Metric Intelligence

Each metric now has risk, confidence, volatility, streaks, and a recommended action.

No metric intelligence yet.

Project Manager

Use the current proof data to choose the next narrow improvement loop.

Posture build

manager mode

Readiness 0 %

needs setup

Source Coverage 13.30 %

connected sources

Projects 1

tracked builds

Priorities 6

current actions

Risks 7

tracked manager risks

Data Gaps 8

sources to connect

Metrics Backlog 8

planned metrics

Inputs 1

project evidence files

Open Todos 0

committed work

Blocked Todos 0

plan blockers

Todo Progress 0 %

done excluding dropped

Work Logs 0

effort records

Workflow thin

health label

Project Todo Ledger

No project todos are recorded yet, so BETA cannot track planned work, blockers, or completion from direct data.

Todos 0

tracked commitments

Open 0

todo, doing, blocked

Doing 0

current focus

Blocked 0

needs decision

Overdue 0

past due

Done 0

completed

Progress 0 %

done excluding dropped

Active Todo Board

  • No todosAdd todos or move one item to todo/doing/blocked.

Recent Todo Changes

  • No todosTodo updates will appear here after you add or update project todos.

Action Tracker

Actions are built from deterministic BETA guidance, manager risks, measurement gaps, and advisory AI output. Statuses are gated by real evidence availability.

beta.action_tracker.v1
Actions 49

tracked recommendations

Active 37

ready to work

Blocked 1

need real data first

Risks 7

manager risks

Avoid 4

guardrails

AI 0

advisory actions

Showing top 12 of 49 tracked actions for this scope.

StatusActionSourceMetricNext StepEvidence Needed
activeP0 Collect real evidence before optimizingThe current imported reports are not accepted as real proof data, so progress and improvement claims would be misleading. Deterministic operating plandeterministic real_report_availableaccepted real report count Run the same scenario used by the comparable baseline. Capture report.json and import it into BETA. Check whether the target metric improved, stabilized, or regressed again. If it regresses again, profile the owning code path before adding new features. A fresh matching proof report plus before/after metric comparison.
activeP0 Collect real evidence before optimizingThe current imported reports are not accepted as real proof data, so progress and improvement claims would be misleading. Deterministic work guidancedeterministic real_report_availableaccepted real report count Run a real bench, field, CI, or hardware validation and import its report.json into this project. accepted real report count
activeP1 AI Recommendation Follow-ThroughAI advice should become tracked actions whose impact can be measured later. Deterministic operating plandeterministic ai_recommendation_follow_throughHigh-value AI recommendations have a decision, owner, and result metric. Run the same scenario used by the comparable baseline. Capture report.json and import it into BETA. Check whether the target metric improved, stabilized, or regressed again. If it regresses again, profile the owning code path before adding new features. A fresh matching proof report plus before/after metric comparison.
activeP1 AI Recommendation Follow-ThroughAI advice should become tracked actions whose impact can be measured later. Deterministic work guidancedeterministic ai_recommendation_follow_throughHigh-value AI recommendations have a decision, owner, and result metric. Record AI recommendations, mark which ones were tried, and connect them to metric movement. High-value AI recommendations have a decision, owner, and result metric.
activeP1 AI Recommendation Follow-ThroughAI advice should become tracked actions whose impact can be measured later. Measurement plandeterministic ai_recommendation_follow_throughHigh-value AI recommendations have a decision, owner, and result metric. Record AI recommendations, mark which ones were tried, and connect them to metric movement. High-value AI recommendations have a decision, owner, and result metric.
activeP1 AI Recommendation Follow-ThroughThis planned metric is not active yet. Manager metric backlogdeterministic ai_recommendation_follow_throughHigh-value AI recommendations have a decision, owner, and result metric. Add this metric to a real report, CI import, bench log, field note, or manual evidence record. High-value AI recommendations have a decision, owner, and result metric.
activeP1 Connect Comparable BaselineA matching prior scenario separates real progress from one-off numbers. Missing data sourcedeterministic evidencesource connected Repeat the same scenario after changes so every metric has a before/after comparison. Repeat the same scenario after changes so every metric has a before/after comparison.
activeP1 Connect Quarantined Demo ReportsSynthetic, demo, smoke, fixture, and local proof reports stay visible for audit but are excluded from metrics. Missing data sourcedeterministic evidencesource connected Replace quarantined reports with real evidence or mark real reports explicitly with metadata.data_authenticity=real. Replace quarantined reports with real evidence or mark real reports explicitly with metadata.data_authenticity=real.
activeP1 Connect Real Proof ReportsOnly accepted real run reports drive charts, regressions, findings, claims, and AI analysis. Missing data sourcedeterministic evidencesource connected Import real bench, field, CI, hardware, or project proof reports with no demo/synthetic/local-proof markers. Import real bench, field, CI, hardware, or project proof reports with no demo/synthetic/local-proof markers.
activeP1 Connect RepeatabilityMultiple runs expose noise, flaky behavior, and repeated regressions. Missing data sourcedeterministic evidencesource connected Run the same scenario several times before treating a change as proven. Run the same scenario several times before treating a change as proven.
activeP1 Connect Sample ScaleLarger samples make performance, storage, and reliability claims harder to fake. Missing data sourcedeterministic evidencesource connected Run proof scenarios at 100, 500, and 1000+ observations and compare the curves. Run proof scenarios at 100, 500, and 1000+ observations and compare the curves.
activeP1 Connect Scenario DiversityMore scenarios reduce the risk of proving only one narrow demo path. Missing data sourcedeterministic evidencesource connected Add at least one scale or field-like scenario beside the current coastal proof. Add at least one scale or field-like scenario beside the current coastal proof.

AI can suggest actions, but BETA only treats metrics, imported inputs, proof reports, and work logs as evidence.

Operating Metrics

  • Project profiles: 1 Each tracked build needs a setup profile, goals, source paths, and project type.
  • Project goals: 0 Goals tell BETA what outcomes the metrics are supposed to support.
  • Connected data sources: 2 / 15 Connected sources make the manager brief factual instead of guessy.
  • Project inputs: 1 Issues, CI, AI sessions, docs, bench logs, and field logs explain why metrics moved.
  • Local repo snapshots: 1 Snapshots show Git state, source/test/doc balance, CI presence, and project structure.
  • Snapshot source files: 36 Source volume helps size the project and compare testing/documentation balance.
  • Snapshot test files: 1 Test volume is an early signal for regression protection and QA maturity.
  • Dirty repos: 0 Dirty worktrees can make evidence hard to reproduce unless changes are explained.

Tracked Projects

Current Manager Priorities

  • P0
    Collect real evidence before optimizing The current imported reports are not accepted as real proof data, so progress and improvement claims would be misleading. Owner: Engineering | Impact: high | Confidence: thin Success: accepted real report count Evidence: A fresh matching proof report plus before/after metric comparison. Run the same scenario used by the comparable baseline. Capture report.json and import it into BETA. Check whether the target metric improved, stabilized, or regressed again. If it regresses again, profile the owning code path before adding new features.
  • P1
    Software Test Pass Rate Proves BETA is still correct while project-management and AI features are added. Owner: Engineering | Impact: high | Confidence: thin Success: Pass rate holds at the project target and regressions are linked to specific work. Evidence: A fresh matching proof report plus before/after metric comparison. Run the same scenario used by the comparable baseline. Capture report.json and import it into BETA. Check whether the target metric improved, stabilized, or regressed again. If it regresses again, profile the owning code path before adding new features.
  • P1
    Dashboard Render Smoke The app has to rebuild and load project pages after evidence changes. Owner: Engineering | Impact: high | Confidence: thin Success: Dashboard rebuild succeeds and the project page opens with the expected scoped data. Evidence: A fresh matching proof report plus before/after metric comparison. Run the same scenario used by the comparable baseline. Capture report.json and import it into BETA. Check whether the target metric improved, stabilized, or regressed again. If it regresses again, profile the owning code path before adding new features.
  • P1
    Project Control Coverage BETA needs no-command controls for setup, todos, work, evidence, reports, and AI management. Owner: Engineering | Impact: high | Confidence: thin Success: Coverage rises when useful controls are added and browser-verified. Evidence: A fresh matching proof report plus before/after metric comparison. Run the same scenario used by the comparable baseline. Capture report.json and import it into BETA. Check whether the target metric improved, stabilized, or regressed again. If it regresses again, profile the owning code path before adding new features.
  • P2
    Owner: Project manager | Impact: | Confidence: Success: Evidence:
  • P1
    Owner: Project manager | Impact: | Confidence: Success: Evidence:

Manager Risks

  • Missing AI Analyst Ollama reviews weak evidence, missing measurements, experiment ideas, and next actions. Mitigation: Use auto-strong for serious reviews; keep deterministic metrics as the source of truth. Owner: Project manager
  • Missing Field And Bench Logs Power, thermal, calibration, endurance, and human acceptance data prove real-world readiness. Mitigation: Create a simple CSV or report.json path for bench and field validation evidence. Owner: Project manager
  • Missing Project Todo Ledger Project todos show planned work, active focus, blockers, due dates, and completion evidence. Mitigation: Add todos for the next project-management cycle, then mark work doing, blocked, done, or dropped as reality changes. Owner: Project manager
  • Missing Work Session Ledger Structured work sessions explain where time went, what produced evidence, and which blockers or rework consumed effort. Mitigation: Record work sessions after meaningful project work with category, minutes, outcome, evidence, blockers, and next step. Owner: Project manager
  • Missing Issue And CI History Project-management evidence needs defects, milestones, build pass rate, coverage, and flaky-test history. Mitigation: Add a connector/importer for issues, milestones, CI status, coverage, and release notes. Owner: Project manager
  • Missing AI Work Sessions AI session summaries show what an AI helped change, suggested, tested, or left uncertain. Mitigation: Import Codex/ChatGPT/session summaries as source_type=ai-session after meaningful project work. Owner: Project manager
  • CosNFX iOS: Increase test coverage for source-heavy areas The snapshot found 1 test file(s) for 36 source file(s). Mitigation: Add tests around the riskiest project-management and data-ingestion workflows first. Owner: Project manager

Project Controls

  • Project intake active 1 project profile(s) Keep project goals, paths, type, and claim list current.
  • Evidence intake active 1 ingested project input(s) Import the source that explains the latest work or blocker.
  • Measurement backlog active 8 planned measurement(s) Attach every major claim to a repeatable metric and test method.
  • Snapshot intelligence active 1 snapshot(s), 36 source file(s), 1 test file(s) Collect snapshots after meaningful repo changes and review dirty repo, CI, test, and doc signals.
  • Todo ledger missing 0 todo item(s), 0 open, 0 blocked Keep active todos current and close done work with evidence.
  • Work ledger missing 0 logged work session(s) Record minutes, category, outcome, evidence, blocker, and next step after meaningful work.
  • AI collaboration planned 0 AI session input(s) Capture AI decisions, discarded ideas, and tested recommendations.

Project Setup Wizard

Make the project measurable by defining goals, claims, metrics, source inputs, and the evidence packet BETA should expect.

cosnfx-ios

Collect Project Snapshot

Reads configured paths and captures Git state, file mix, test, docs, config, and CI signals.

Run Tests

Runs the project's configured test command and records pass rate, coverage, and failures as real CI evidence.

Connect A Source

Create Evidence Template

Source Connection Plan

Connected 1

source connectors

Planned 5

still needs data

Coverage 16.70 %

source plan

repoconnected
Local Project Snapshot

Tracks repository state, file mix, test/doc/config signals, CI hints, and dirty worktree risk.

Metric: source_file_count, test_file_count, doc_file_count, dirty_repo_count C:\Users\jdcap\Documents\Projects\CosNFX_IOS Next: Use Collect Project Snapshot after important work so BETA can compare source, test, docs, and Git-state changes.
ai-sessionplanned
AI Work Sessions

Tracks what AI suggested, what was tried, and whether later metrics improved.

Metric: ai_recommendation_follow_through, accepted_ai_actions No path connected yet. Next: Save useful AI summaries with recommendation, action, evidence, and result fields.
benchplanned
Bench Evidence

Tracks measured setup, hardware, performance, calibration, and validation runs.

Metric: bench_pass_rate, measured_failure_count, setup_time_minutes No path connected yet. Next: Attach bench CSVs, checklists, calibration logs, photos, or measured report.json files.
ciplanned
CI And Test History

Tracks build health, test pass rate, coverage, and failed checks.

Metric: unit_test_pass_rate, code_coverage_percent, test_failure_count No path connected yet. Next: Use Import Test Results (beta import-tests) on a JUnit XML, pytest JSON, coverage report, or CI log after each meaningful build.
docsplanned
Requirements And Design Docs

Connects project goals, claims, acceptance criteria, and design decisions to evidence.

Metric: claim_coverage, acceptance_criteria_coverage No path connected yet. Next: Attach requirements, design notes, test matrices, decision logs, and acceptance criteria.
issuesplanned
Issue And Milestone History

Tracks planned work, stale work, blockers, cycle time, and release scope.

Metric: open_issue_count, blocked_issue_count, cycle_time_days No path connected yet. Next: Export GitHub/Jira issues or keep a simple CSV of issue status and milestone dates.

Project Goals & Setup

Use this setup guide to turn BETA from a dashboard into a project manager: goals define intent, metrics define proof, and evidence changes the plan.

software
Project CosNFX iOS cosnfx-ios
Project file C:\Users\jdcap\Documents\Projects\BETA\.beta\projects\cosnfx-ios\project.json Customize goals, claims, metrics, paths, and evidence sources here.

Setup And Customization Commands

  • 1
    Create a separated project Creates a project page, project.json, scan profile, verification plan, and project-scoped dashboard data. .\dev.ps1 init-project -ProjectPath C:\path\to\build -ProjectName "Bench Prototype" -ProjectType hardware -Goal "Prove stable bench operation"
  • 2
    Add goals, claims, or custom metrics Custom goals and metrics become planning inputs, manager context, and measurement backlog. .\dev.ps1 configure-project -ProjectKey cosnfx-ios -Goal "Make field setup repeatable" -Metric "setup_success_rate|%|Tracks whether setup succeeds without manual rescue" -Claim "Operators can identify a node and trust its status"
  • 3
    Connect real project context Issues, CI, bench logs, field notes, docs, and AI sessions explain why a metric moved. .\dev.ps1 ingest-info -ProjectKey cosnfx-ios -InfoPath C:\path\to\issues-or-notes.csv -SourceType issues -Note "current backlog"
  • 4
    Record work and evidence Work logs tell the manager where time is productive, blocked, rework, or evidence-producing. .\dev.ps1 record-work -ProjectKey cosnfx-ios -WorkTitle "Validation pass" -WorkMinutes 45 -WorkStatus tested -WorkEvidence "report.json"
  • 5
    Run the manager loop Refreshes deterministic analysis, then asks the local AI to turn it into actionable project guidance. .\dev.ps1 refresh; .\dev.ps1 manage-ai -Model gemma4:latest

What You Can Customize

  • goals: 0 What the project is trying to improve or prove.
  • custom_claims: 0 Statements BETA should try to connect to evidence.
  • custom_metrics: 0 Project-specific measurements that should appear in the planning backlog.
  • evidence_sources: 6 Where useful proof can come from: CI, bench, field, docs, issues, AI sessions.
  • test_tools: 5 Tools or workflows that can produce proof.
  • paths: 1 Repo, hardware folder, docs folder, or build path BETA should scan.

Planning Loop

  • SignalGoal: decide what outcome matters.
  • SignalClaim: write the thing you want to be able to say is true.
  • SignalMetric: define the number, pass/fail, or evidence signal that would prove it.
  • SignalScenario: run the same test or validation path repeatedly.
  • SignalEvidence: import the report, CI result, bench log, field note, or operator signoff.
  • SignalManager decision: focus, stop, protect, or connect a missing source.

Configured Goals

  • No goals configuredAdd goals so the manager can rank work against project intent.

Custom Claims

  • No custom claimsAdd claims you want BETA to prove with metrics and evidence.

Custom Metrics

  • No custom metricsUse configure-project -Metric to add project-specific measurements.

Starter Todo Cycle

Use this to create the first measurable planning loop: real proof, connected project history, and field or bench validation.

missing
P0Import one accepted real proof report

Run or import one real bench, field, CI, hardware, or project proof report with no demo, synthetic, or local-proof markers.

Done when: Accepted real report count is greater than zero and appears in the project evidence page.
P1Connect issue and CI history

Import issues, milestones, build status, test pass rate, coverage, flaky-test notes, and release notes.

Done when: Issue and CI sources are connected and visible in source coverage.
P1Capture field and bench logs

Add bench or field CSV, log, checklist, or report paths for power, thermal, calibration, endurance, and operator notes.

Done when: Field and bench sources are connected with at least one evidence-backed work or proof record.

Todo And Work Control

Add committed work, update blockers, and log how time was spent so the manager view can explain progress and waste.

cosnfx-ios

Add Todo

Update Todo

Record Work Session

Project Todo Ledger

No project todos are recorded yet, so BETA cannot track planned work, blockers, or completion from direct data.

Todos 0

tracked commitments

Open 0

todo, doing, blocked

Doing 0

current focus

Blocked 0

needs decision

Overdue 0

past due

Done 0

completed

Progress 0 %

done excluding dropped

Active Todo Board

  • No todosAdd todos or move one item to todo/doing/blocked.

Recent Todo Changes

  • No todosTodo updates will appear here after you add or update project todos.

Work Session Ledger

No structured work sessions are logged yet, so BETA cannot judge time use from direct evidence.

Sessions 0

logged work blocks

Tracked Time 0.0 h

total effort

Productive 0 %

completed, shipped, tested, evidence, decided

Evidence Work 0 %

tied to proof

Blocked/Rework 0 %

friction signal

AI-Assisted 0.0 h

tracked AI use

Where Time Is Going

No category allocation yet.

Recent Work Sessions

  • No work sessions loggedUse record-work after meaningful project work so BETA can analyze effort quality.

Deterministic Findings

  • No open findingsThe latest run has no deterministic findings.

Improvement Backlog

  • ClearNo generated actions for the latest run.

Data Version & Model Provenance

This records exactly what generated this page, what schemas were used, and whether an Ollama model contributed advisory analysis.

beta-2026-06-22t21-...
Data version beta-2026-06-22t21-24-40z-eb2404ebe0 eb2404ebe0e2135e9197624d40fa8d633b0e6e8b0a03df367353085a7bdae33b
BETA app 0.2.0 Build Environment for Testing & Analytics
Analysis schema beta.analysis.v1 BETA deterministic engine
Generated 2026-06-22T21:24:40Z C:\Users\jdcap\Documents\Projects\BETA\.beta
AI model none AI not used; ollama model none; available=False; usable=False; source=none
Data policy deterministic source of truth Only accepted real reports are used for metrics, graphs, claims, progress, and AI analysis. Synthetic/demo/local proof reports are quarantined.
Real reports 0 Accepted reports used for metrics, graphs, claims, and progress.
Quarantined reports 0 Visible for audit but excluded from proof calculations.

Project Version Records

  • CosNFX iOS Config: v1 (explicit) | Schema: beta.project.v1 Project AI plan: not run | Profile: none | Plan: none

Version Change Since Previous Snapshot

A new data version was generated, but tracked evidence/model/project-config fields did not materially change.

snapshot-only
Current data version beta-2026-06-22t21-24-40z-eb2404ebe0 2026-06-22T21:24:40Z
Previous data version beta-2026-06-22t20-02-03z-9c2c4e1540 2026-06-22T20:02:03Z
  • No material tracked changesThis snapshot did not change the tracked evidence/model/project-config posture.

Data Version History

Each row is a generated dashboard/report snapshot for this scope. Use it to see which BETA version, model, and project config produced past data.

5 shown
Data VersionRecordedBETAAI ModelRealQuarantinedProject Configs
beta-2026-06-22t21-24-4...project:cosnfx-ios 2026-06-22T21:24:40Z 0.2.0 none 0 0 cosnfx-ios v1 (explicit)
beta-2026-06-22t20-02-0...project:cosnfx-ios 2026-06-22T20:02:03Z 0.2.0 none 0 0 cosnfx-ios v1 (explicit)
beta-2026-06-22t19-52-5...project:cosnfx-ios 2026-06-22T19:52:58Z 0.2.0 none 0 0 cosnfx-ios v1 (explicit)
beta-2026-06-22t19-51-1...project:cosnfx-ios 2026-06-22T19:51:17Z 0.2.0 none 0 0 cosnfx-ios v1 (explicit)
beta-2026-06-22t19-51-1...project:cosnfx-ios 2026-06-22T19:51:16Z 0.2.0 none 0 0 cosnfx-ios v1 (explicit)
real-data-needed

No real proof data is driving this project yet.

0 discovered report(s) are quarantined as demo/synthetic/local proof data. Charts and claims will stay empty until real evidence is imported.

Data quality 0% needs-real-data

Focus Metrics

  • No metric regressionsKeep collecting repeated runs and broader scenarios.

Next Moves

  • Software Test Pass Rate P1 | Software QA
  • Dashboard Render Smoke P1 | Frontend QA
  • Project Control Coverage P1 | Product/project manager
  • AI Recommendation Follow-Through P1 | AI/project manager

Missing Inputs

  • Repeatability Run the same scenario several times before treating a change as proven.
  • Scenario Diversity Add at least one scale or field-like scenario beside the current coastal proof.
  • Sample Scale Run proof scenarios at 100, 500, and 1000+ observations and compare the curves.
  • Source Connection Plan Register planned sources, then connect real files or folders as they become available.
Connected 2

evidence inputs

Partial 4

needs stronger proof

Missing 8

not imported yet

Active 0

tracked measurements

Snapshot Intelligence

Local project-state data from the configured path. This supports planning and QA; it does not replace proof reports.

usable
Snapshot Score 65.00 %

2026-06-22T19:51:16Z

Source Files 36

scanned source

Test Files 1

ratio 0.028

Docs 7

ratio 0.194

CI Workflows 0

detected

Dirty Repos 0

needs explanation

Trends Over Time

Collect at least two snapshots to chart source-tree and Git-state trends.

PathFilesSource/Test/DocsGitDirty
C:\Users\jdcap\Documents\Projects\CosNFX_IOSexists 60 36/1/7 main cebd79b 0

Recommended Improvements

  • Connect CI or repeatable test historyNo CI workflow files were detected, so BETA cannot tell whether checks stay green over time. Next: Add a CI workflow, import CI logs, or record repeatable local test evidence after each major change.
  • Increase test coverage for source-heavy areasThe snapshot found 1 test file(s) for 36 source file(s). Next: Add tests around the riskiest project-management and data-ingestion workflows first.

What BETA Noticed

  • Snapshot noteNo CI workflow files were detected in the scanned path.
  • Snapshot noteTests are thin compared with source file count.

Real Evidence Capture Kit

CosNFX iOS needs its first accepted real report before metrics can prove progress.

needs-real-data

Starter Scenarios

benchP0
Bench Validation Baseline

Creates the first accepted real baseline so charts and claims stop being empty.

.\dev.ps1 evidence-template -ProjectKey cosnfx-ios -ScenarioId bench-validation -CollectionType bench .\dev.ps1 record-evidence -ProjectKey cosnfx-ios -ScenarioId bench-validation -CollectionType bench -RequiredPassed -AdvisoryPassed -ObservationsAccepted 100 One measured report imports as real, required gates pass, and the dashboard shows one real run.
fieldP1
Field-Link Load Check

Connects portal/API responsiveness to real network conditions instead of local-only timing.

.\dev.ps1 evidence-template -ProjectKey cosnfx-ios -ScenarioId field-link-load -CollectionType field .\dev.ps1 record-evidence -ProjectKey cosnfx-ios -ScenarioId field-link-load -CollectionType field -RequiredPassed -ObservationsAccepted 100 -PortalHtmlBytes 1 -QueryP95Ms 1 Portal payload and query p95 are recorded from a constrained or remote path.
ciP1
CI Regression Evidence

Adds build/test pass history so project progress is not inferred only from proof runs.

.\dev.ps1 evidence-template -ProjectKey cosnfx-ios -ScenarioId ci-regression -CollectionType ci .\dev.ps1 record-evidence -ProjectKey cosnfx-ios -ScenarioId ci-regression -CollectionType ci -RequiredPassed -ObservationsAccepted 1 CI result evidence is attached and repeat failures trend down over time.

Required Report Fields

  • metadata.data_authenticityrealLets BETA accept the report as usable evidence instead of quarantining it.
  • metadata.collection_typebench | field | ci | firmware | hardware | operator | measuredTells BETA what kind of real-world source produced the measurement.
  • scenario.scenario_idstable scenario idMatching scenario ids allow before/after comparisons over time.
  • overall.required_passedtrue/falseCorrectness gates are the minimum proof before performance claims matter.
  • metrics.ingest.counts.observations.acceptedintegerSample size affects confidence in throughput, storage, and latency claims.
  • analysis.evidence[].summaryshort measured source noteKeeps the metric tied to the actual test, bench note, CI run, or field observation.
  • analysis.evidence[].sourcelog/photo/serial/CI/bench source referenceLets a reviewer trace the metric back to the file, capture, or note that produced it.

Metric Field Map

MeasurementReport FieldPriority
Software Test Pass Rateunit_test_pass_rate metrics.custom.unit_test_pass_rate P1
Code Coveragecode_coverage_percent metrics.custom.code_coverage_percent P2
Open Test Failurestest_failure_count metrics.custom.test_failure_count P2
Dashboard Render Smokedashboard_render_success metrics.custom.dashboard_render_success P1
Project Control Coverageproject_control_coverage metrics.custom.project_control_coverage P1
Blocker And Todo Flowopen_blocker_count metrics.custom.open_blocker_count P2
AI Recommendation Follow-Throughai_recommendation_follow_through metrics.custom.ai_recommendation_follow_through P1
Issue And CI Historyci_failure_rate metrics.custom.ci_failure_rate P2

Data Sources

These inputs determine whether the evidence is real, repeatable, and useful for project decisions.

evidencemissing
Real Proof Reports

Only accepted real run reports drive charts, regressions, findings, claims, and AI analysis.

Signal: 0 Next: Import real bench, field, CI, hardware, or project proof reports with no demo/synthetic/local-proof markers.
evidenceclear
Quarantined Demo Reports

Synthetic, demo, smoke, fixture, and local proof reports stay visible for audit but are excluded from metrics.

Signal: 0 Next: Replace quarantined reports with real evidence or mark real reports explicitly with metadata.data_authenticity=real.
evidencemissing
Comparable Baseline

A matching prior scenario separates real progress from one-off numbers.

Signal: none Next: Repeat the same scenario after changes so every metric has a before/after comparison.
evidencepartial
Repeatability

Multiple runs expose noise, flaky behavior, and repeated regressions.

Signal: 0 Next: Run the same scenario several times before treating a change as proven.
evidencepartial
Scenario Diversity

More scenarios reduce the risk of proving only one narrow demo path.

Signal: 0 Next: Add at least one scale or field-like scenario beside the current coastal proof.
evidencepartial
Sample Scale

Larger samples make performance, storage, and reliability claims harder to fake.

Signal: 0 Next: Run proof scenarios at 100, 500, and 1000+ observations and compare the curves.
aimissing
AI Analyst

Ollama reviews weak evidence, missing measurements, experiment ideas, and next actions.

Signal: not run Next: Use auto-strong for serious reviews; keep deterministic metrics as the source of truth.
planningconnected
Project Scan

Project profiles connect source, docs, tests, firmware, evidence, and planned metrics.

Signal: 1 Next: Run plan-ai after major repo or hardware-documentation changes.
planningconnected
Local Repo Snapshots

Repo snapshots capture Git state, file mix, test/doc/config signals, and local structure for project planning.

Signal: 1 Next: Use Collect Project Snapshot on each project after important work or before a planning review.
planningpartial
Source Connection Plan

Source connectors define which project inputs BETA should expect for issues, CI, docs, bench, field, metrics, and AI sessions.

Signal: 1/6 Next: Register planned sources, then connect real files or folders as they become available.
fieldmissing
Field And Bench Logs

Power, thermal, calibration, endurance, and human acceptance data prove real-world readiness.

Signal: not imported Next: Create a simple CSV or report.json path for bench and field validation evidence.
managementmissing
Project Todo Ledger

Project todos show planned work, active focus, blockers, due dates, and completion evidence.

Signal: not logged Next: Add todos for the next project-management cycle, then mark work doing, blocked, done, or dropped as reality changes.
managementmissing
Work Session Ledger

Structured work sessions explain where time went, what produced evidence, and which blockers or rework consumed effort.

Signal: not logged Next: Record work sessions after meaningful project work with category, minutes, outcome, evidence, blockers, and next step.
managementmissing
Issue And CI History

Project-management evidence needs defects, milestones, build pass rate, coverage, and flaky-test history.

Signal: not imported Next: Add a connector/importer for issues, milestones, CI status, coverage, and release notes.
aimissing
AI Work Sessions

AI session summaries show what an AI helped change, suggested, tested, or left uncertain.

Signal: not imported Next: Import Codex/ChatGPT/session summaries as source_type=ai-session after meaningful project work.

Measurement Plan

  • P1 Software Test Pass Rate Proves BETA is still correct while project-management and AI features are added. Metric: unit_test_pass_rate Collect: Run python -m unittest discover -s tests and record the pass percentage in a real project report. Done when: Pass rate holds at the project target and regressions are linked to specific work.
  • P2 Code Coverage Coverage shows how much of the code the passing tests actually exercise, so a green build is not hiding untested paths. Metric: code_coverage_percent Collect: Import a coverage report (Cobertura XML or coverage.py JSON) with python -m beta import-tests and set a coverage floor. Done when: Coverage holds above the project floor and does not regress against the last import.
  • P2 Open Test Failures Failing tests point directly at what is broken right now and block any honest claim of done. Metric: test_failure_count Collect: Import the JUnit/pytest report with python -m beta import-tests and drive failures to zero before shipping. Done when: Test failures reach zero and any new failure is linked to a specific change.
  • P1 Dashboard Render Smoke The app has to rebuild and load project pages after evidence changes. Metric: dashboard_render_success Collect: Run dashboard generation, open the BETA and OMEGA project pages, and record the render result. Done when: Dashboard rebuild succeeds and the project page opens with the expected scoped data.
  • P1 Project Control Coverage BETA needs no-command controls for setup, todos, work, evidence, reports, and AI management. Metric: project_control_coverage Collect: Review the project page controls and record how many intended project-management workflows are covered. Done when: Coverage rises when useful controls are added and browser-verified.
  • P2 Blocker And Todo Flow Open blockers explain what is behind schedule and what the project manager AI should focus on. Metric: open_blocker_count Collect: Keep todos current and record blocked items, owner, reason, and completion evidence. Done when: Open blocker count trends down or each blocker has a named next action.
  • P1 AI Recommendation Follow-Through AI advice should become tracked actions whose impact can be measured later. Metric: ai_recommendation_follow_through Collect: Record AI recommendations, mark which ones were tried, and connect them to metric movement. Done when: High-value AI recommendations have a decision, owner, and result metric.
  • P2 Issue And CI History Build failures, flaky tests, and unresolved issues are real workflow health signals. Metric: ci_failure_rate Collect: Import CI runs, test results, issue status, and repeated failure reasons. Done when: Failure rate and stale issue load trend down over repeated project cycles.

Version Change Since Previous Snapshot

A new data version was generated, but tracked evidence/model/project-config fields did not materially change.

snapshot-only
Current data version beta-2026-06-22t21-24-40z-eb2404ebe0 2026-06-22T21:24:40Z
Previous data version beta-2026-06-22t20-02-03z-9c2c4e1540 2026-06-22T20:02:03Z
  • No material tracked changesThis snapshot did not change the tracked evidence/model/project-config posture.

Data Version History

Each row is a generated dashboard/report snapshot for this scope. Use it to see which BETA version, model, and project config produced past data.

5 shown
Data VersionRecordedBETAAI ModelRealQuarantinedProject Configs
beta-2026-06-22t21-24-4...project:cosnfx-ios 2026-06-22T21:24:40Z 0.2.0 none 0 0 cosnfx-ios v1 (explicit)
beta-2026-06-22t20-02-0...project:cosnfx-ios 2026-06-22T20:02:03Z 0.2.0 none 0 0 cosnfx-ios v1 (explicit)
beta-2026-06-22t19-52-5...project:cosnfx-ios 2026-06-22T19:52:58Z 0.2.0 none 0 0 cosnfx-ios v1 (explicit)
beta-2026-06-22t19-51-1...project:cosnfx-ios 2026-06-22T19:51:17Z 0.2.0 none 0 0 cosnfx-ios v1 (explicit)
beta-2026-06-22t19-51-1...project:cosnfx-ios 2026-06-22T19:51:16Z 0.2.0 none 0 0 cosnfx-ios v1 (explicit)

Run History

RunScenarioGeneratedScoreThroughputQuery p95

AI Analyst

AI analysis has not been run for the latest dashboard data.

Data Quality Assessment

Run AI analysis to review data quality.

Actionable Operating Plan

  • P0
    Collect real evidence before optimizing The current imported reports are not accepted as real proof data, so progress and improvement claims would be misleading. Owner: Engineering | Impact: high | Confidence: thin Success: accepted real report count Evidence: A fresh matching proof report plus before/after metric comparison. Run the same scenario used by the comparable baseline. Capture report.json and import it into BETA. Check whether the target metric improved, stabilized, or regressed again. If it regresses again, profile the owning code path before adding new features.
  • P1
    Software Test Pass Rate Proves BETA is still correct while project-management and AI features are added. Owner: Engineering | Impact: high | Confidence: thin Success: Pass rate holds at the project target and regressions are linked to specific work. Evidence: A fresh matching proof report plus before/after metric comparison. Run the same scenario used by the comparable baseline. Capture report.json and import it into BETA. Check whether the target metric improved, stabilized, or regressed again. If it regresses again, profile the owning code path before adding new features.
  • P1
    Dashboard Render Smoke The app has to rebuild and load project pages after evidence changes. Owner: Engineering | Impact: high | Confidence: thin Success: Dashboard rebuild succeeds and the project page opens with the expected scoped data. Evidence: A fresh matching proof report plus before/after metric comparison. Run the same scenario used by the comparable baseline. Capture report.json and import it into BETA. Check whether the target metric improved, stabilized, or regressed again. If it regresses again, profile the owning code path before adding new features.
  • P1
    Project Control Coverage BETA needs no-command controls for setup, todos, work, evidence, reports, and AI management. Owner: Engineering | Impact: high | Confidence: thin Success: Coverage rises when useful controls are added and browser-verified. Evidence: A fresh matching proof report plus before/after metric comparison. Run the same scenario used by the comparable baseline. Capture report.json and import it into BETA. Check whether the target metric improved, stabilized, or regressed again. If it regresses again, profile the owning code path before adding new features.

What To Focus On

  • P0 Collect real evidence before optimizing The current imported reports are not accepted as real proof data, so progress and improvement claims would be misleading. Next: Run a real bench, field, CI, or hardware validation and import its report.json into this project. Success: accepted real report count
  • P1 Software Test Pass Rate Proves BETA is still correct while project-management and AI features are added. Next: Run python -m unittest discover -s tests and record the pass percentage in a real project report. Success: Pass rate holds at the project target and regressions are linked to specific work.
  • P1 Dashboard Render Smoke The app has to rebuild and load project pages after evidence changes. Next: Run dashboard generation, open the BETA and OMEGA project pages, and record the render result. Success: Dashboard rebuild succeeds and the project page opens with the expected scoped data.
  • P1 Project Control Coverage BETA needs no-command controls for setup, todos, work, evidence, reports, and AI management. Next: Review the project page controls and record how many intended project-management workflows are covered. Success: Coverage rises when useful controls are added and browser-verified.
  • P1 AI Recommendation Follow-Through AI advice should become tracked actions whose impact can be measured later. Next: Record AI recommendations, mark which ones were tried, and connect them to metric movement. Success: High-value AI recommendations have a decision, owner, and result metric.
  • P1 Create a real project todo list 1 project(s) are tracked, but there are no persistent todos for planned work, blockers, or completion evidence. Next: Add the top three project todos: one current focus, one measurement/evidence item, and one blocker or risk item. Success: at least three project todos with priority and status

How To Work Better

  • Use a tight evidence loop This makes progress attributable instead of mixing several changes into one unclear result. Start: Plan one change, run one matching proof scenario, save the report, then review the regression and QA matrix.
  • Keep proof reports small but complete Structured data feeds charts, AI review, reports, and trend analysis automatically. Start: Add metrics as structured report fields instead of notes whenever possible.
  • Separate current-state proof from improvement proof This prevents the tool from overstating progress when it only has a snapshot. Start: Use current values to prove presence, but use matching baselines and repeated runs to prove improvement.
  • Close data-quality gaps before polishing Accepted real reports: 0; quarantined demo/synthetic reports: 0. Start: Start with: Real proof report is available.
  • Start logging effort evidence BETA cannot know where time is useful or wasted until effort data exists. Start: After meaningful work, run record-work with minutes, category, outcome, evidence, blocker, and next step.
  • Turn the plan into todos BETA needs a committed task ledger to track project progress and explain why work is ahead or behind. Start: Use Add Todo for the next focus item, blocker, evidence task, and planning task.

Improvement Opportunities

  • No AI opportunitiesRun AI analysis to generate model-assisted suggestions.

Claim Relevance Review

  • No items yetRun AI analysis to populate this section.

Action Tracker

Actions are built from deterministic BETA guidance, manager risks, measurement gaps, and advisory AI output. Statuses are gated by real evidence availability.

beta.action_tracker.v1
Actions 49

tracked recommendations

Active 37

ready to work

Blocked 1

need real data first

Risks 7

manager risks

Avoid 4

guardrails

AI 0

advisory actions

Showing top 12 of 49 tracked actions for this scope.

StatusActionSourceMetricNext StepEvidence Needed
activeP0 Collect real evidence before optimizingThe current imported reports are not accepted as real proof data, so progress and improvement claims would be misleading. Deterministic operating plandeterministic real_report_availableaccepted real report count Run the same scenario used by the comparable baseline. Capture report.json and import it into BETA. Check whether the target metric improved, stabilized, or regressed again. If it regresses again, profile the owning code path before adding new features. A fresh matching proof report plus before/after metric comparison.
activeP0 Collect real evidence before optimizingThe current imported reports are not accepted as real proof data, so progress and improvement claims would be misleading. Deterministic work guidancedeterministic real_report_availableaccepted real report count Run a real bench, field, CI, or hardware validation and import its report.json into this project. accepted real report count
activeP1 AI Recommendation Follow-ThroughAI advice should become tracked actions whose impact can be measured later. Deterministic operating plandeterministic ai_recommendation_follow_throughHigh-value AI recommendations have a decision, owner, and result metric. Run the same scenario used by the comparable baseline. Capture report.json and import it into BETA. Check whether the target metric improved, stabilized, or regressed again. If it regresses again, profile the owning code path before adding new features. A fresh matching proof report plus before/after metric comparison.
activeP1 AI Recommendation Follow-ThroughAI advice should become tracked actions whose impact can be measured later. Deterministic work guidancedeterministic ai_recommendation_follow_throughHigh-value AI recommendations have a decision, owner, and result metric. Record AI recommendations, mark which ones were tried, and connect them to metric movement. High-value AI recommendations have a decision, owner, and result metric.
activeP1 AI Recommendation Follow-ThroughAI advice should become tracked actions whose impact can be measured later. Measurement plandeterministic ai_recommendation_follow_throughHigh-value AI recommendations have a decision, owner, and result metric. Record AI recommendations, mark which ones were tried, and connect them to metric movement. High-value AI recommendations have a decision, owner, and result metric.
activeP1 AI Recommendation Follow-ThroughThis planned metric is not active yet. Manager metric backlogdeterministic ai_recommendation_follow_throughHigh-value AI recommendations have a decision, owner, and result metric. Add this metric to a real report, CI import, bench log, field note, or manual evidence record. High-value AI recommendations have a decision, owner, and result metric.
activeP1 Connect Comparable BaselineA matching prior scenario separates real progress from one-off numbers. Missing data sourcedeterministic evidencesource connected Repeat the same scenario after changes so every metric has a before/after comparison. Repeat the same scenario after changes so every metric has a before/after comparison.
activeP1 Connect Quarantined Demo ReportsSynthetic, demo, smoke, fixture, and local proof reports stay visible for audit but are excluded from metrics. Missing data sourcedeterministic evidencesource connected Replace quarantined reports with real evidence or mark real reports explicitly with metadata.data_authenticity=real. Replace quarantined reports with real evidence or mark real reports explicitly with metadata.data_authenticity=real.
activeP1 Connect Real Proof ReportsOnly accepted real run reports drive charts, regressions, findings, claims, and AI analysis. Missing data sourcedeterministic evidencesource connected Import real bench, field, CI, hardware, or project proof reports with no demo/synthetic/local-proof markers. Import real bench, field, CI, hardware, or project proof reports with no demo/synthetic/local-proof markers.
activeP1 Connect RepeatabilityMultiple runs expose noise, flaky behavior, and repeated regressions. Missing data sourcedeterministic evidencesource connected Run the same scenario several times before treating a change as proven. Run the same scenario several times before treating a change as proven.
activeP1 Connect Sample ScaleLarger samples make performance, storage, and reliability claims harder to fake. Missing data sourcedeterministic evidencesource connected Run proof scenarios at 100, 500, and 1000+ observations and compare the curves. Run proof scenarios at 100, 500, and 1000+ observations and compare the curves.
activeP1 Connect Scenario DiversityMore scenarios reduce the risk of proving only one narrow demo path. Missing data sourcedeterministic evidencesource connected Add at least one scale or field-like scenario beside the current coastal proof. Add at least one scale or field-like scenario beside the current coastal proof.

AI can suggest actions, but BETA only treats metrics, imported inputs, proof reports, and work logs as evidence.