client: surface ALL observation fields (was dropping deltas, anomalies, last_action, step_history)

Pre-fix, an external user calling the deployed HF Space via this client got
a strictly worse view than the server returned: per-meter deltas, anomalies,
last_action, and the full step_history were silently dropped during JSON
parsing. This violated the 'client/server separation done right' criterion
in the hackathon rubric (training/WhatMakesAGoodSubmission.md): the client
was pretending fields didn't exist.

Fix: _parse_result now reconstructs the full RhythmObservation including
all 5 *_delta fields, last_action, and step_history with full StepRecord
fidelity (including the new vitality/cognition/progress/serenity/connection
anomaly fields added in iter 4 commit).

Also adds the hackathon submission criteria doc to the repo for reference.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

client.py

@@ -18,9 +18,9 @@ from openenv.core.client_types import StepResult
 from openenv.core.env_client import EnvClient
 
 try:
-    from .models import RhythmAction, RhythmObservation, RhythmState
+    from .models import RhythmAction, RhythmObservation, RhythmState, StepRecord
 except ImportError:
-    from models import RhythmAction, RhythmObservation, RhythmState
+    from models import RhythmAction, RhythmObservation, RhythmState, StepRecord
 
 
 class RhythmEnv(EnvClient[RhythmAction, RhythmObservation, RhythmState]):
@@ -38,9 +38,36 @@ class RhythmEnv(EnvClient[RhythmAction, RhythmObservation, RhythmState]):
         return {"action_type": action.action_type.value}
 
     def _parse_result(self, payload: Dict[str, Any]) -> StepResult[RhythmObservation]:
-        """Parse server response into StepResult[RhythmObservation]."""
+        """Parse server response into StepResult[RhythmObservation].
+
+        Surfaces ALL observation fields the server returns, including the
+        per-meter deltas, anomalies (in step_history), last_action, and the
+        full step history. Without these, an external agent connecting to the
+        server can't see the meta-RL signals it needs to infer the profile.
+        """
         obs_data = payload.get("observation", {})
 
+        # Reconstruct step_history with full StepRecord fidelity
+        step_history_raw = obs_data.get("step_history", []) or []
+        step_history = [
+            StepRecord(
+                step=h.get("step", 0),
+                action=h.get("action", ""),
+                reward=h.get("reward", 0.0),
+                vitality_delta=h.get("vitality_delta", 0.0),
+                cognition_delta=h.get("cognition_delta", 0.0),
+                progress_delta=h.get("progress_delta", 0.0),
+                serenity_delta=h.get("serenity_delta", 0.0),
+                connection_delta=h.get("connection_delta", 0.0),
+                vitality_anomaly=h.get("vitality_anomaly", 0.0),
+                cognition_anomaly=h.get("cognition_anomaly", 0.0),
+                progress_anomaly=h.get("progress_anomaly", 0.0),
+                serenity_anomaly=h.get("serenity_anomaly", 0.0),
+                connection_anomaly=h.get("connection_anomaly", 0.0),
+            )
+            for h in step_history_raw
+        ]
+
         observation = RhythmObservation(
             timestep=obs_data.get("timestep", 0),
             day=obs_data.get("day", 0),
@@ -56,6 +83,15 @@ class RhythmEnv(EnvClient[RhythmAction, RhythmObservation, RhythmState]):
             done=payload.get("done", False),
             reward=payload.get("reward", 0.0),
             metadata=obs_data.get("metadata", {}),
+            # Per-meter deltas from THIS step (was being silently dropped)
+            vitality_delta=obs_data.get("vitality_delta", 0.0),
+            cognition_delta=obs_data.get("cognition_delta", 0.0),
+            progress_delta=obs_data.get("progress_delta", 0.0),
+            serenity_delta=obs_data.get("serenity_delta", 0.0),
+            connection_delta=obs_data.get("connection_delta", 0.0),
+            last_action=obs_data.get("last_action"),
+            # Rolling history with anomalies (the meta-RL signal)
+            step_history=step_history,
         )
 
         return StepResult(

training/WhatMakesAGoodSubmission.md

@@ -0,0 +1,57 @@
+# What makes a submission stand out: 
+Pick an ambitious, original problem
+The themes (problems) are deliberately open. Use them as launching pads, not boxes. Judges have seen a lot of chess, snake, tic-tac-toe, and grid-world clones. To score well on innovation,
+you need a genuinely fresh angle. Some questions to ask yourself:
+Does this environment exist to teach an LLM something it currently can’t do well?
+Is the domain underexplored in RL/LLM training?
+Could a researcher write a paper about training on this?
+
+Design a reward signal that actually teaches
+A great environment has a reward function that:
+Provides a rich, informative signal (not just 0/1 at the end)
+Captures something hard to measure in a clever way
+Uses OpenEnv’s Rubric system thoughtfully (composable rubrics > monolithic scoring)
+Is hard to game; an agent that exploits the reward without solving the task should not get high scores
+
+Show real training, end to end
+The bar isn’t “training script exists.” The bar is “training script runs against the environment, the
+agent learns, and you can show it.” Concretely:
+Your training loop should connect to your environment (not a static dataset)
+Train long enough that the curves mean something
+Compare a trained agent vs. a random/untrained baseline; quantitative and/or qualitative
+Include the plots and numbers in your README and writeup
+
+Make your plots readable
+Reviewers spend seconds, not minutes, on each plot. Help them out:
+Label both axes (e.g. “training step” / “episode” on x, “reward” / “loss” on y) and include units where they apply
+Save plots as .png or .jpg and commit them to the repo (don’t leave them only in a Colab cell or a deleted Wandb run) (if you ran via WANBD, please include the link to that specific run of your plots)
+Embed the key plots in your README with a one-line caption explaining what each one shows If you have multiple runs (baseline vs. trained, ablations, etc.), put them on the same axes so the comparison is obvious
+
+
+Tell a story, not an API doc
+Your README, blog, and pitch should answer:
+Problem) what capability gap or interesting domain are you targeting?
+Environment) what does the agent see, do, and get rewarded for?
+Results) what changed after training? Show it.
+Why does it matter) who would care, and why?
+
+A reviewer should be able to read your README in 3~5 minutes and want to try your
+environment.
+
+NOTE: If you have a video, HF post, or anything else interesting, please make sure that it’s linked
+  from your README.
+
+
+Engineer it cleanly (table stakes)
+Engineering quality matters less than ambition, but sloppy work hurts. Make sure you:
+Use OpenEnv’s Environment / MCPEnvironment base classes properly
+Respect the client / server separation (clients should never import server internals)
+Follow the standard Gym-style API (reset, step, state)
+Have a valid openenv.yaml manifest
+Don’t use reserved tool names (reset, step, state, close) for MCP tools
+
+Final Note
+Judges are looking for environments that push the frontier of what we can train LLMs to do. Be
+ambitious. Pick a problem you find genuinely interesting; that almost always produces better
+work than chasing what you think judges want. Good luck.
+