View source for Micro/Daily Scheduler

{{DISPLAYTITLE:Micro/Daily Scheduler}}

The '''Micro/Daily Scheduler''' is the detailed operational scheduling page for a multi-day meet.

The [[Macro Scheduler]] establishes the large-scale structure of the meet:

* Which day an event occurs
* Which facility it uses
* Its general order
* Its scheduled starting position

The Micro/Daily Scheduler takes those scheduled blocks and exposes the detailed operation inside them.

It is where the Meet Director can examine and refine:

* Divisions within a block
* Individual heats
* Heat capacity
* Heat duration
* Time between heats
* Transitions
* Hurdle changes
* Field flights
* Facility assignments
* Combined-event sequences
* Detailed start times

== Who should use this page? ==

Use the Micro/Daily Scheduler for a multi-day meet after the major schedule structure has been established on the [[Macro Scheduler]].

A normal one-day meet should generally use [[Schedule]] instead.

Micro/Daily is particularly useful for meets where the Meet Director needs detailed control over the way each competition block actually operates.

== Macro and Micro are one schedule ==

Macro and Micro are not separate schedules.

Both are views of the same operational schedule.

A block moved or edited in Micro remains the same competition block that appears on Macro.

Likewise, a block placed on Macro becomes available for detailed operation in Micro.

The purpose of the two pages is different:

'''Macro Scheduler'''
: Places the large pieces.

'''Micro/Daily Scheduler'''
: Controls the detail inside those pieces.

A human decision made on either page should remain authoritative.

Automation may recalculate dependent information, but it should not silently replace a Meet Director's deliberate order, placement, capacity, or timing decision.

== Day navigation ==

Each competition day has its own tab.

Examples:

* Day 1 · Fri Jun 12
* Day 2 · Sat Jun 13
* Day 3 · Sun Jun 14

Select a day to display its detailed schedule.

Only one day's Micro schedule is displayed at a time.

== Overview ==

The '''Overview''' view divides the day's schedule into:

* Track
* Field

This is the easiest way to see the day's overall operating sequence.

Each event appears as a schedule block containing its important competition information.

== Facilities ==

Select:

'''⊞ Facilities'''

to view field events according to the individual physical facilities where they are conducted.

Instead of one general Field column, this view may show facilities such as:

* Long Jump North
* Long Jump South
* High Jump
* Pole Vault
* Shot Put North
* Shot Put South
* Cage
* Javelin

The available facilities originate from [[Venue]].

This view is useful for determining whether each pit, ring, runway, or cage has a physically workable schedule.

== Return to Macro ==

Select:

'''Macro →'''

to return to the [[Macro Scheduler]].

Use Macro when the problem concerns:

* Day
* Broad event order
* Major placement
* Facility
* Large schedule structure

Use Micro/Daily when the problem concerns:

* Heat detail
* Division detail
* Exact timing
* Internal transitions
* Facility operation

== LIVE and LOCKED ==

A day may display one of two states:

* '''● LIVE'''
* '''● LOCKED'''

A LIVE day remains part of the active derived schedule.

A LOCKED day is intended to preserve detailed authored information rather than freely rebuilding that day's schedule from upstream changes.

The locking feature should be used when a day's detailed schedule has reached a point where the Meet Director does not want routine regeneration to replace those decisions.

'''Current implementation note:''' The exact normal-user lock/unlock workflow should be verified before this section is treated as final.

== Meet-level settings ==

Several controls near the top of Micro/Daily apply to the meet rather than only to the currently displayed day.

These settings are shared with other scheduling pages rather than being separate Micro copies.

== Heat gap ==

Sets the standard time between track heats.

The Heat gap is the same underlying value used on [[Rounds]].

Changing it on either page changes the same meet setting.

The value may use quarter-minute increments.

Examples:

* <code>4</code> = 4 minutes
* <code>1.5</code> = 1 minute 30 seconds
* <code>0.75</code> = 45 seconds
* <code>0.25</code> = 15 seconds

A change to Heat gap may require Torunit to regenerate calculated schedule information.

== Hurdle transition ==

Sets the normal amount of time allocated for changing a hurdle configuration.

A hurdle transition may involve:

* Changing hurdle height
* Moving hurdles
* Changing spacing
* Changing the race configuration
* Preparing the next hurdle group

Torunit may use actual hurdle-format information in addition to this meet-level setting.

== Recall warm-up ==

Sets the warm-up period given to field-event competitors who must be recalled from an earlier flight for additional attempts.

For example, if the athletes advancing to the final three attempts come from more than one flight, athletes from an earlier flight may need time to warm up again.

If the final competitors all come from the final flight, no recall may be required.

== Field flights ==

Controls the general field-event seeding policy.

Current choices are:

* '''Balanced'''
* '''Stacked'''

=== Balanced ===

Strong marks are distributed through the available flights.

This provides a more even distribution of competitive ability.

=== Stacked ===

Stronger marks are concentrated toward the final flight.

This can be useful where the Meet Director wants the strongest athletes competing late and wants the final-attempt cut to emerge primarily from the final flight.

== Auto-ripple ==

Controls whether later dependent schedule items automatically move after an earlier change.

When Auto-ripple is on:

* A delay can move later events later.
* Gaining time can allow later events to move earlier.
* An explicit anchor remains fixed.
* Dependent events are recalculated from that anchor.

Ripple should follow human decisions rather than replace them.

== Heat sizing ==

The Heat sizing control selects which participant counts are used to determine heat structure.

Current choices are:

* '''ANTICIPATED'''
* '''REAL'''

=== ANTICIPATED ===

Uses the planning figures entered before registration is complete.

This allows the schedule to remain stable while registrations are still arriving.

=== REAL ===

Uses actual registered participant counts.

Switch to REAL when registration is complete enough that the Meet Director wants the operating schedule based on the athletes who are actually entered.

Actual counts may still be displayed while ANTICIPATED remains the sizing authority.

== Per-day timing settings ==

Each day also has settings that apply specifically to that day's operation.

These include:

* First track event
* First field event
* Fixed
* First call
* Check-in
* Warmup

== First track event ==

Displays the currently scheduled first Track competition of the day.

This is derived from the operational schedule.

== First field event ==

Displays the currently scheduled first Field competition of the day.

== Fixed ==

Indicates that the day's detailed timing contains explicit time anchors that should be preserved.

A fixed time represents a Meet Director decision.

If earlier activity makes that time impossible, Torunit should identify the conflict rather than silently changing the fixed time.

== First call ==

Sets how many minutes before competition the first call should occur.

Example:

<code>30</code>

means the first call occurs 30 minutes before the applicable competition time.

== Check-in ==

Sets the normal advance time associated with athlete check-in.

The exact check-in sequence may vary according to the event and Clerk of Course operation.

== Warmup ==

Sets the normal field-event warm-up allowance for the day.

This affects the amount of operating room required between field competitions using the same facility.

== Understanding a schedule block ==

Each competition appears as a schedule block.

A block represents an operational portion of the schedule rather than merely the name of an event.

A block may contain:

* Event
* Round
* Gender
* Division
* Athlete count
* Heat or flight count
* Start time
* Duration
* Facility
* Combined-event relationship
* Hurdle requirements
* Implement information
* Internal heat timing
* Warnings
* Detailed settings

== Event name ==

The event name is the primary heading of the block.

Internal Torunit event-family codes are converted to their public event names for display.

== Round ==

Where applicable, the competition round is included with the event name.

Examples:

* 100 Prelims
* 200 Semifinals
* 800 Final

Round identity matters because different rounds may have different:

* Participant counts
* Lane capacities
* Advancement structures
* Scheduling requirements

== Combined-event parent ==

A combined-event component may identify its parent combined event.

Examples:

* DEC · 100
* HEP · HJ
* PENT · SP

The component is still scheduled on its actual physical facility.

For example:

* A Decathlon Shot Put component uses a Shot Put ring.
* A Heptathlon High Jump component uses a High Jump facility.
* A Decathlon 100 uses the Track.

See [[Combined Events]].

== Facility ==

The block may display the physical facility where it is assigned.

Facility assignment should correspond to the facilities established on [[Venue]].

== START HERE ==

A linked sequence may identify the first operational stage with:

'''▶ START HERE'''

This helps identify the entry point into a chain of dependent events.

== Division and gender composition ==

A block may contain several Gender/Division groups.

Examples:

* G 9–10
* B 9–10
* G 11–12
* B 11–12

For each group, Micro may show:

* Anticipated athletes
* Real athletes
* Number of heats
* Effective capacity

These values explain how Torunit arrived at the block's heat structure.

== Anticipated versus real counts ==

Where both values are available, the block may show the planned and actual entry counts together.

This allows the Meet Director to see whether reality is significantly different from the schedule assumption.

A large difference may justify changing Heat sizing from ANTICIPATED to REAL.

== Combining divisions ==

Where permitted, two or more divisions may be combined operationally into the same race.

Combining divisions does not necessarily combine their:

* Results
* Scoring
* Records
* Qualification status

It means they compete together operationally.

The Meet Director's explicit decision to combine divisions should remain authoritative.

== Unganging divisions ==

A previously combined race may be separated back into its individual divisions.

Changing the combination may alter:

* Heat count
* Athlete distribution
* Block duration
* Later schedule times

Dependent calculations should be rebuilt while preserving unrelated human decisions.

== Borderline heat decisions ==

Torunit may identify a division whose athlete count lies just beyond the normal preferred heat size.

The Meet Director may be offered a choice such as:

* '''Combine into one'''
* '''Split into two'''

This is intentionally a human decision rather than an arbitrary automatic choice.

Once made, the choice should remain stored until the Meet Director changes it.

== Heat breakdown ==

A schedule block can be expanded to show its detailed internal sequence.

Track blocks may display individual heats.

The detailed rows may include:

* Heat number
* Gender/division
* Athlete count
* Start time
* Estimated duration
* Setup or transition rows

This detailed sequence is the Micro portion of the schedule.

== Editing a heat time ==

Individual heat start times may be edited.

An edited heat time is an explicit Meet Director decision.

Later dependent heats should ripple from the change.

The system should not silently restore the previous automatically generated time.

== Block Settings ==

Select the '''⚙''' in the event block header to open:

'''Block settings'''

The Block Settings dialog allows detailed schedule preferences to be established at three levels:

* Block
* Division
* Heat

This provides progressively more specific control without requiring every value to be manually entered for every heat.

== The inheritance system ==

Micro/Daily uses inheritance.

A more specific setting inherits from its parent unless the Meet Director provides an explicit override.

The hierarchy is:

'''Calculated or meet default → Block → Division → Heat'''

For example:

* Meet heat gap = 4 minutes
* Block gap = blank → inherits 4 minutes
* Division gap = 5 minutes → that division uses 5
* Heat 3 gap = 7 minutes → Heat 3 uses 7

Blank does not mean zero.

Blank means:

'''Use the inherited value.'''

The settings dialog displays the inherited value so the Meet Director can see what will actually be used.

== Block-level settings ==

Block-level settings apply to every appropriate division and heat in the block unless overridden at a lower level.

Available block preferences currently include:

* Division order
* Capacity
* Heat duration
* Gap after
* Transition before
* Transition after

== Division order ==

Controls the order in which the divisions inside the block compete.

A Meet Director may deliberately move divisions into the desired operating order.

The saved human order overrides the automatic order.

Divisions that are newly added or not explicitly listed should remain present rather than being discarded.

They follow the explicitly ordered divisions until the Meet Director places them.

== Reordering divisions ==

The Block Settings dialog allows the division order to be changed.

The current interface supports:

* Moving a division earlier
* Moving a division later
* Dragging divisions
* Reversing the order

After saving, the block should use that order when constructing its detailed heat sequence.

== Capacity ==

Capacity determines the maximum number of athletes assigned to a heat for the applicable scope.

A block-level capacity applies to each division unless that division has its own capacity override.

The number of heats is then calculated separately for each division.

Example:

Suppose a block contains:

* Girls 11–12 — 41 athletes
* Boys 11–12 — 55 athletes

with an effective capacity of 9.

Torunit should calculate each division independently:

* Girls: <code>ceil(41 / 9)</code>
* Boys: <code>ceil(55 / 9)</code>

and then combine the resulting heat counts into the block.

The athlete totals should not be combined first and divided afterward.

== Division-level capacity ==

A division may have its own capacity.

Example:

Block capacity:

<code>9</code>

Girls 11–12 capacity:

<code>8</code>

Boys 11–12 capacity:

blank

The Girls division uses 8.

The Boys division inherits 9.

== Heat-level capacity ==

An individual heat may also have its own capacity.

This allows unusual operational circumstances to be represented without changing every heat in the division.

For example:

* Heat 1 capacity — 9
* Heat 2 capacity — 9
* Heat 3 capacity — 8

If the explicit capacities are insufficient to hold all athletes, Torunit should create another inherited-capacity heat rather than silently exceeding a Meet Director's stated limit.

== Heat duration ==

Controls the expected competition duration of the applicable heat.

The value is entered in minutes and may use quarter-minute increments.

Example:

<code>1.25</code>

represents 1 minute 15 seconds.

A blank value inherits the duration from the parent level.

== Gap after ==

Controls additional time following the heat before the next dependent heat begins.

This can represent the normal operating interval between heats.

A blank value inherits the parent gap.

== Transition before ==

Adds explicit operational time before the applicable heat.

Possible uses include:

* Hurdle adjustment
* Equipment setup
* Start-line change
* Crew movement
* Other required preparation

Transition time becomes part of the real schedule sequence rather than merely an informational note.

== Transition after ==

Adds explicit operational time after the heat.

Possible uses include:

* Equipment clearing
* Hurdle reset
* Moving starting equipment
* Facility conversion
* Other required work

== Division-level settings ==

Each division represented in the block may have its own settings.

A division-level setting overrides the corresponding block-level value only for that division.

Other divisions continue to inherit the block value.

== Heat-level settings ==

Each individual heat may have its own settings.

Heat settings are the most specific level.

An explicit heat value overrides both:

* Block setting
* Division setting

for that heat only.

== Understanding inherited values ==

Each field in the settings dialog displays its inherited value.

For example:

'''Capacity'''

<code>Inherited: 9 athletes per heat</code>

'''Heat duration'''

<code>Inherited: 1.25 minutes</code>

'''Gap after'''

<code>Inherited: 4 minutes</code>

If the Meet Director is satisfied with that value, leave the override blank.

Enter a value only when the selected block, division, or heat should behave differently.

== Saving Block Settings ==

Select:

'''Save settings'''

to save the current Block, Division, and Heat preferences.

The settings are associated with the block's permanent Block UID rather than its temporary position in the schedule.

This means moving the block should not create a new block or lose its detailed settings.

After saving, the current implementation reloads the page so the detailed schedule can be recalculated from the new values.

== Cancel ==

Select:

'''Cancel'''

to close the Block Settings dialog without saving the current edits.

== Heat distribution ==

When heat capacities are known, Torunit distributes the division's athletes across the required heats.

The current detailed heat system attempts to balance athletes among the heats without exceeding each heat's effective capacity.

An explicit capacity should therefore be treated as a limit, not merely a suggestion.

== Detailed timing calculation ==

The detailed heat timeline incorporates:

* Transition before
* Competition duration
* Gap after
* Transition after

These pieces are inserted into the timeline in sequence.

For example:

<code>
Transition before
Heat
Gap after
Transition after
Next heat
</code>

Changing one element affects the start of the dependent elements that follow.

== Hurdle events ==

Hurdle events may require substantially more internal scheduling detail than ordinary flat races.

Different divisions may require different:

* Race distances
* Hurdle heights
* Hurdle spacing
* Number of hurdles
* Setup configuration

Micro/Daily displays the resolved configurations represented within the block.

== Hurdle configuration groups ==

Where different participating divisions require different hurdle formats, the block may show each applicable configuration.

The information may include:

* Distance
* Hurdle specification
* Divisions
* Number of athletes

== Hurdle resets ==

If the block contains more than one hurdle configuration, Torunit may insert hurdle reset time between the affected groups.

These transitions are operational time.

They must affect the schedule that follows rather than being displayed merely as a warning.

== Unresolved hurdle formats ==

If Torunit cannot match an athlete group to a known hurdle format, the block may display a warning.

Examples include:

'''⚠ distance TBD'''

or an unmapped-format warning.

An unresolved hurdle format should be corrected before the schedule is treated as operationally complete.

== Human hurdle order ==

When no human division order has been entered, Torunit may use the operational order provided by the hurdle/barrier data.

Once the Meet Director explicitly changes the division order, that saved order becomes authoritative.

The hurdle transitions must then be recalculated around the human-selected order.

== Throwing implements ==

Throwing-event blocks may display the implement specifications required by the divisions in that block.

This may include events such as:

* Shot Put
* Discus
* Hammer
* Weight Throw
* Super Weight
* Javelin

Different divisions may require different implement weights.

Displaying those requirements in the operating schedule helps officials prepare the next competition correctly.

== Javelin implements ==

Javelin blocks may display the applicable implement weight and the divisions using it.

This information is derived from the meet's actual division/event requirements rather than being merely a generic event label.

== Field events and flights ==

Field-event blocks may contain one or more flights.

A flight is an operational subdivision of the field competition.

The detailed schedule may include:

* Flight number
* Number of athletes
* Check-in
* Warm-up
* Competition start
* Competition duration
* Seed range

== Authoritative field-flight plan ==

The field-flight plan is generated by the server.

Micro/Daily should display that plan rather than independently inventing a different flight structure in the browser.

This prevents the Overview and Facilities views from disagreeing about when a flight actually competes.

== Final-attempt cut ==

Where the field-event format includes a cut to additional attempts, the flight plan may also include the timing of that cut.

The number of athletes receiving additional attempts is determined by the meet's competition format.

== Recall from an earlier flight ==

If finalists come from an earlier flight, the schedule may include recall warm-up time before those athletes resume competition.

The Recall warm-up meet setting controls that allowance.

== Facilities view ==

Facilities view shows each physical field facility as its own operating timeline.

Each facility may display:

* Its scheduled events
* Event start times
* Duration
* Flights
* Collision status

== clear ==

A facility marked:

'''clear'''

does not currently contain a detected time collision.

== empty ==

A facility marked:

'''empty'''

has no competition assigned in the current view.

== Collision warning ==

A red collision warning means two events overlap on the same physical facility.

That conflict must be resolved before both events can operate as scheduled.

== Moving an event between facilities ==

A field-event row may be dragged from one compatible facility to another.

The change updates the block's facility assignment.

The corresponding Overview block should remain synchronized with the same operational block.

== Editing a facility start ==

The start time shown beside a facility event may be edited directly.

That block becomes the anchor for the facility sequence.

Dependent later blocks can then ripple from it.

== Facility ripple ==

Facility ripple reflects the way a real field venue operates.

If a competition ends late:

* Later events move later.

If the facility becomes available early:

* Later events may move earlier.

The Meet Director's edited event remains the anchor.

The dependent schedule follows it.

== Five-minute operating boundary ==

Facility ripple currently places dependent blocks on the next available five-minute boundary.

This provides practical operating times while still allowing significantly finer control than the coarse Macro layout.

== Warm-up protection ==

Torunit checks whether a field event has enough preparation and warm-up time after the preceding event using the same facility.

A warning may appear if the next competition starts too early.

Combined-event components may require additional handling time.

== Focus on group ==

For linked sequences, particularly combined events, Facilities view may provide:

'''Focus on group'''

Select a group to show the facilities relevant to that chain.

This can make it easier to follow one traveling group through a complicated multi-facility day.

== Combined-event chains ==

Combined-event athletes move through a sequence of component events.

The Micro/Daily Scheduler preserves that chain identity.

A combined-event component is displayed at the real facility where it occurs while remaining connected to its parent combined event and traveling group.

== Chain navigation ==

Linked stages may contain controls allowing the Meet Director to jump directly to another component of the same sequence.

This is useful when the stages of a chain are separated by time, facility, or day.

== Holding ==

Blocks that do not yet have a valid place in the operational schedule remain visible in '''Holding'''.

Holding is not deletion.

It means:

'''This block still needs a path into the schedule.'''

Nothing should silently disappear because it has not yet been placed.

== Every GDE needs a path ==

The Holding section follows an important rule:

'''Every Gender/Division/Event combination must have an operational path.'''

If Torunit cannot place one, the block should remain visible for the Meet Director to resolve.

== First legs ==

Combined-event and linked-event chains identify the first actionable leg separately.

The Holding area presents:

'''▶ Place these first'''

These are the entry points from which the dependent sequence can be established.

== Later train legs ==

Dependent later legs are grouped separately.

Because they normally follow from the first leg, they are collapsed by default to reduce clutter.

Select:

'''Show later train legs'''

to inspect them.

== Standalone blocks ==

An ordinary unlinked event may also appear in Holding.

It remains visible as a standalone block until it receives a valid schedule placement.

== Schedule items ==

The Meet Director may insert non-competition items into the Track or Field sequence.

Examples:

* Opening Ceremony
* Awards
* Lunch
* Officials Break
* Track Maintenance
* Presentation
* National Anthem

A schedule item has:

* Name
* Duration
* Optional fixed start

== Fixed custom item ==

If a custom schedule item is given a specific start time, it becomes a fixed schedule anchor.

If the fixed time is cleared, the item may once again flow with the dependent schedule.

== Saving ==

Micro/Daily saves detailed edits to the operational schedule.

Different types of edits may save immediately or cause the page to regenerate.

Changes that affect derived heat or flight structure may cause a page reload.

== Permanent block identity ==

Detailed preferences are stored against the permanent Block UID.

They are not supposed to depend on the block's current position.

This is important because:

* A block can move.
* Its time can change.
* Its facility can change.
* Earlier blocks can ripple it.

None of those actions should turn it into a different competition block.

== Inheritance and NULL values ==

An unset preference is intentionally stored as no override.

This allows Torunit to distinguish:

'''Use the inherited value'''

from:

'''The Meet Director explicitly entered a value.'''

That distinction is essential to the Block → Division → Heat model.

== Current implementation notes ==

The following items should be reviewed as Torunit development continues:

* Verify that every Block, Division, and Heat setting displays the actual value that the calculation engine will use, not merely a display approximation.
* Verify that block capacity is applied separately to each division before the heat totals are added together.
* Verify division-level capacity overrides only the selected division.
* Verify individual heat capacities remain hard limits and that overflow creates another heat rather than exceeding the override.
* Verify all Block, Division, and Heat settings survive save, reload, Macro movement, and schedule regeneration.
* Verify manual division ordering always remains authoritative.
* Verify hurdle setup and transition calculations are recalculated from the real human-selected division order.
* Verify hurdle transitions continue to use actual hurdle-format data.
* Verify individual heat-time edits ripple only the dependent rows that follow.
* Verify ANTICIPATED → REAL switching changes derived heat math without destroying explicit human placement, order, capacity, or timing decisions.
* Verify Facilities and Overview always show the same operational start and facility after an edit.
* Verify facility ripple never moves the Meet Director's explicit anchor.
* Verify field flights always use the server-authored flight plan.
* Verify field-flight recall and final-attempt timing remain correct after flight changes.
* Verify Holding continues to expose every unplaced GDE and no regeneration path silently discards one.
* Verify combined-event first-leg and later-leg classification remains correct when a component is moved back to Holding.
* Verify the LIVE / LOCKED state has a clear normal-user workflow if locking is intended to be exposed to Meet Directors.
* The detailed settings code contains fallback race-duration estimates based mainly on event distance when no stored duration is available. Confirm that these fallback estimates can never override better authoritative event or Meet Director data.
* Continue treating <code>schedule_blocks</code> and permanent Block UID as the authoritative operational identity rather than introducing another parallel schedule representation.

== See also ==

* [[Macro Scheduler]]
* [[Rounds]]
* [[Venue]]
* [[Combined Events]]
* [[Schedule]]
* [[Live Meet]]

[[Category:Meet Director]]
[[Category:Schedule]]
[[Category:Multi-day meet]]
[[Category:Meet operations]]