Reiseplan-Zeitbudget

Spielraum, Überlauf, Auslastung und ein fits-Kennzeichen kommen mit den empfohlenen Stunden je Zeile zurück, damit ein menschlicher Planer und ein API-Client dieselbe Arithmetik teilen. Null- oder negative Budgets, negativer Transit oder Pause und ein reserviertes Paar, das den Tag bereits übersteigt, scheitern mit invalid_input, statt einen Zeitplan zu erfinden.

Wie reservierter Transit und Pause die Aktivitäts-Hülle verkleinern

Ein Reiseplan-Zeitbudget behandelt das Wachfenster als harte Hülle, nicht als Wunschzettel. Transit und Pause werden zuerst abgezogen, weil sie an einem realistischen Tag nicht optional sind. Jede Aktivität behält einen Namen und eine geplante Stundenzahl, damit ein Louvre-Block, ein Markt und ein Flussufer-Spaziergang getrennt bleiben. Gleiche geplante Stunden bleiben nach der Skalierung gleich; eine vierstündige Kathedrale neben einem zweistündigen Museum behält das Verhältnis zwei zu eins. Gleitkomma-Staub wird in die letzte positive geplante Aktivität absorbiert, sodass die empfohlenen Stunden an einem Überlauftag genau den restlichen Pool ergeben. Das Feld available_hours ist diese Hülle: vierzehn Stunden vom Frühstück zum Hotel oder zehn Stunden zwischen einem späten Start und einer Abendessenreservierung. Gehen zwischen Museen, ein U-Bahn-Sprung, ein Taxi zum Aussichtspunkt und die Minuten an der Kasse leben in transit_hours. Mahlzeiten, ein sitzender Kaffee, der Hotel-Check-in und die Pause, die ein Reisender wirklich braucht, leben in rest_hours. Ihre Summe ist reserved_hours. Was bleibt, ist remaining_for_activities, der einzige Pool, den geplante Stopps ausgeben dürfen. Liegt die geplante Summe höchstens im restlichen Pool, gleichen die empfohlenen Stunden den geplanten und slack_hours ist der ungenutzte Rest. Ist die geplante Summe größer, wird jede Aktivität mit remaining_for_activities geteilt durch die geplante Summe skaliert, damit der empfohlene Tag noch schließt. Die Auslastung kann einhundert Prozent übersteigen, wenn committed_hours laut Plan das Budget überschießt; das ist das Signal zum Streichen, nicht die Uhr zu dehnen.

Eingabevertrag, Antwortform und Fehlerverhalten

Verdrahten Sie das kostenlose Browserformular für die menschliche Planung und rufen Sie denselben Vertrag aus einem Reisebauer auf, wenn die Automatisierung identische Zahlen braucht. Senden Sie per POST einen JSON-Körper mit vier Pflichtfeldern. Das Feld available_hours ist eine endliche Zahl streng größer als null und höchstens einhundertachtundsechzig, genug für einen langen Tag oder eine kurze mehrtägige Hülle. Die Felder transit_hours und rest_hours sind endlich und nichtnegativ, jedes ebenfalls auf einhundertachtundsechzig begrenzt. Ihre Summe darf available_hours nicht übersteigen; ein reserviertes Paar, das das ganze Budget und mehr bereits frisst, scheitert mit invalid_input, weil keine ehrliche Aktivitäts-Hülle mehr zu verteilen ist. Das Feld activities ist ein nichtleeres Array von Objekten, jedes mit einem nichtleeren name und einem endlichen nichtnegativen hours, höchstens fünfzig Zeilen auf diesem kostenlosen Parse-Pfad. Fehlende Felder, leere Listen, Nicht-Objekt-Zeilen, leere Namen, nichtendliche Zahlen, negative Stunden und ein verfügbares Budget von null oder darunter scheitern mit invalid_input und werden nicht berechnet. Bei Erfolg wiederholt der Körper die drei Stundeneingaben und liefert reserved_hours, remaining_for_activities, planned_activity_hours, recommended_activity_hours, committed_hours, slack_hours, overflow_hours, ein boolesches fits-Kennzeichen, einen status fits, tight oder overflow, utilization_percent, scale_factor und activity_count. Jede Aktivitätszeile trägt index, name, planned_hours, recommended_hours, share_of_activities und percent_of_day. Method ist reserve_then_scale. Formula bekräftigt, dass remaining gleich available minus transit minus rest ist und recommended_i gleich planned_i mal dem Minimum aus eins und remaining über der geplanten Summe. Ein tight-Tag ist ein passender Tag, dessen Spielraum höchstens zehn Prozent von available_hours beträgt. Erfolgreiche API-Aufrufe nutzen den veröffentlichten Grundpreis $0.002 je Element; Validierungsfehler verbrauchen kein vorausbezahltes Guthaben.

Wo ein tägliches Reiseplan-Zeitbudget seinen Nutzen hat

Reiseveranstalter nutzen einen Reiseplan-Zeitbudget-Rechner, damit eine Städtetrip-Vorlage ein kürzeres Winterlichtfenster übersteht: behalten Sie dieselben geplanten Stopps, erhöhen Sie transit_hours, wenn die Gruppe langsamer geht, und führen Sie erneut aus. Firmen-Offsite-Planer reservieren Mittagessen und Hotelsattel als rest und transit und sehen, ob drei Workshops noch in einen Zehn-Stunden-Tag passen. Weil die Umsetzung reines Parse der Stufe A ist, kostet jeder erfolgreiche Aufruf den veröffentlichten Grundpreis $0.002 ohne Modell-Tokens und ohne ausgehendes Netz.