Rjg intro updates

.github/pull_request_template.md

@@ -1,3 +1,7 @@
+This pull request template is part of the technical assessment. It is used to evaluate both the quality of the solution and how you approached the work.
+
+Do not reveal your identity in this PR. Candidates must use an anonymous GitHub account for the exercise.
+
 ## Acceptance Criteria Coverage
 Describe which issue acceptance criteria you believe are:
 
@@ -45,6 +49,8 @@ Example:
 
 Include prompts that helped you understand the problem space, shape the implementation, or validate the result. This can include exploratory questions such as terminology, architecture, or workflow clarification.
 
+Prefer the prompts that materially changed your understanding, plan, implementation, or validation strategy.
+
 Do not include assistant responses in this section. If an assistant response was wrong in an important way, describe it in `AI Mistakes And Corrections` instead.
 
 Do not include secrets, tokens, or irrelevant prompts that had no bearing on your final work.
@@ -73,10 +79,19 @@ Example:
 
     I started from a UI issue but found that the graph API schema was missing the fields required to render the new state reliably. I chose to fix the API contract first because it unblocked both the web client and the SDK and produced a cleaner validation path.
 
+## Limitations And Deferred Work
+Document any important limitations, edge cases, tradeoffs, follow-up ideas, or improvements you noticed but did not address.
+
+Example:
+
+    The happy path is covered by tests, but I did not add concurrency coverage for overlapping sync operations.
+    The UI now supports manual reconnect, but error copy and recovery states could still be improved.
+
 ## Candidate Checklist
 - [ ] I explained which issue acceptance criteria were completed, partially completed, or not completed.
 - [ ] I validated the change with tests and/or manual checks.
 - [ ] I included the key prompts and exploratory questions that materially influenced the work.
 - [ ] I documented any important assistant mistakes and how I corrected them.
 - [ ] If I changed direction, I explained why.
 - [ ] I documented any limitations, deferred work, edge cases, or improvements I noticed but did not address.
+- [ ] I did not reveal my identity in this PR.

README.md

@@ -1,8 +1,26 @@
 # Move37
 
+## Technical Assessment
+
+This repository is used as an AI-augmented technical assessment for software engineers.
+
+The goal is not to measure who can hand-code the fastest. The goal is to understand how a candidate approaches a real engineering problem in a realistic environment: how they break down the task, how they use coding agents, how they evaluate AI output, how they validate the result, and how they communicate tradeoffs and decisions.
+
+Candidates are expected to work on a bounded GitHub issue, use AI assistance as part of their workflow, and submit a pull request that shows both the outcome and the thinking behind it. We are looking for strong systems thinking, sound engineering judgment, and the ability to partner effectively with modern tools.
+
+This assessment is intentionally run in a public GitHub repository because it better reflects day-to-day software engineering than a puzzle or whiteboard exercise. It lets candidates work in a native environment with real issues, real constraints, and real review artifacts.
+
+**If you are completing this exercise, create an anonymous GitHub account and fork this repository before you start work. Do not use your normal GitHub identity or begin work from a non-anonymous clone. Revealing your identity to reviewers will automatically disqualify the submission.**
+
+Start by reading the section called `The Exercise` below. If you want to understand the product and the technical landscape first, the rest of this README introduces Move37 and its current state.
+
+## About Move37
+
 **Move37 is a personal planning system built around self-knowledge.**
 
-We are not always the best at estimating how long things take to be completed — this is not only due to unforeseen circumstances, but also because we do not know our own behaviour well enough: what drains us, what motivates us, what our real pace is versus our optimistic one.
+The name Move37 is a reference to AlphaGo's famous move 37, an unexpected decision that changed how people thought about what AI could do.
+
+In the same way, we are not always the best at judging our own plans. This is not only due to unforeseen circumstances, but also because we do not know our own behaviour well enough: what drains us, what motivates us, and what our real pace is versus our optimistic one.
 
 Move37 brings together personal notes and reflections, calendar commitments, a history of calendar behaviour, and financial behaviour to help us understand our own patterns. Over time, it learns what "I'll finish this by Friday" actually means for each of us individually — and helps us plan accordingly. Used in a team, it turns that self-knowledge into better coordination and productivity.
 
@@ -19,35 +37,51 @@ The system is AI-native: every piece of information becomes something an agent c
 
 ## Current State
 
-The web UI is in good shape. The backend is partially wired. Several core capabilities are still under active development:
+Move37 already has a meaningful system shape. The repository contains a React web app, a FastAPI backend, a JavaScript SDK, an internal AI service for semantic search and grounded chat, a notes worker, and deployment scaffolding. If you want the technical overview, see the [architecture guide](./contributing-docs/docs/architecture.md).
+
+Several important capabilities are present in early form and are still being hardened end to end:
 
-- **Apple Calendar sync** — the integration exists but is not yet fully connected end to end
-- **Scheduling engine** — the logic for reasoning about dependencies, timing, and estimated completion is not yet implemented
-- **OpenBanking** — financial behaviour data is not yet ingested or connected
-- **Note embeddings** — personal reflections are not yet embedded for semantic search
+- **Apple Calendar sync**: account management, sync, and reconciliation flows exist, but the full user journey still needs validation, polish, and stronger end to end coverage
+- **Scheduling engine**: there is a deterministic dependency-aware planning baseline today, but the richer scheduling logic is still to come
+- **OpenBanking**: financial behaviour data is not yet ingested or connected
+- **Notes, embeddings, and semantic retrieval**: notes CRUD, import, search, and grounded chat are wired, but the ingestion and retrieval path is still maturing operationally
 
-These are the areas where the product has the most ground to cover, and where the most interesting contributions live.
+Many features can be explored with the core web and API stack alone, but some paths, especially note retrieval and grounded chat, depend on the internal AI service, the notes worker, and supporting infrastructure being available locally.
+
+These are the areas where the product has the most ground to cover, and where many of the most interesting contributions live.
 
 ---
 
 ## The Exercise
 
-This repository is used as a hiring exercise for Roche gRED software engineers.
+This exercise is designed to reflect how software engineering is increasingly practiced in an AI-augmented environment.
+
+You are not being assessed on whether you hand-write every line of code yourself. You are being assessed on how you approach a bounded engineering problem in a real repository: how you understand the system, how you choose scope, how you work with coding agents, how you validate what they produce, and how you communicate the quality and limitations of the final result.
+
+In practical terms, the exercise is simple:
+
+1. Create an anonymous GitHub account and fork this repository before doing any work
+2. Choose an open GitHub issue that interests you
+3. Work it through end to end in your own fork
+4. Use coding agents as part of your workflow where helpful
+5. Submit a pull request that shows both the outcome and the reasoning behind it
+
+We are particularly interested in signals such as:
 
-Browse the [open issues](https://github.com/Genentech/Move37/issues) and pick one that interests you. There is no obligation to pick the smallest one — a more ambitious issue will make for a more interesting conversation.
+- how well you understand the architectural intent of an existing system
+- how effectively you break work into safe, testable steps
+- how thoughtfully you prompt, review, and correct AI-generated output
+- how well you validate behavior rather than assuming it is correct
+- how clearly you explain tradeoffs, limitations, and next steps
 
-**Steps:**
+This is why the exercise runs in a public GitHub repository rather than as a puzzle or whiteboard task. It gives you a native environment with realistic constraints, existing code, issue threads, and review artifacts. That setting gives us a better signal of engineering judgment than a synthetic interview problem.
 
-1. Fork this repository **anonymously** (disclosing your identity to the reviewers will automatically disqualify you)
-2. Pick a GitHub issue or several and work on them end to end
-3. Use coding agents as part of your workflow — this is expected and encouraged
-4. Open a pull request against this repository
-5. Follow the submission guide in `.github/pull_request_template.md`
+Anonymity is a hard requirement. Use an anonymous GitHub account for both the fork and the pull request, and set that up before you begin. Revealing your identity to reviewers will automatically disqualify the submission.
 
-Each issue is designed to be completable in roughly 1–2 hours. You can use the issue thread to ask questions or discuss your approach with the hiring team.
+The submission guide in `.github/pull_request_template.md` is part of the exercise. It asks you to document validation steps, prompt history, and important AI mistakes and corrections. Those are not extras. They are part of how we evaluate the work.
 
 ---
 
 ## Contributing
 
-See `contributing-docs/` for setup details, environment variables, and service configuration.
+See [`contributing-docs/`](./contributing-docs/) for setup details, environment variables, and service configuration. Start with `docs/intro.md`.

contributing-docs/docs/architecture.md

@@ -25,7 +25,9 @@ Move37 is not a single process. It is a small system with a few important bounda
 `src/move37/services/container.py` wires the main runtime:
 
 - SQLAlchemy session factory
+- `AppleCalendarSyncService`
 - `ActivityGraphService`
+- `SchedulingService`
 - `NoteService`
 - `ChatSessionService`
 - `Move37AiClient`
@@ -34,12 +36,19 @@ That last point matters: the main API does not answer note search or chat itself
 
 ## REST and MCP surfaces
 
-REST routes currently cover four broad areas:
+REST routes currently cover six broad areas:
 
 - auth
 - graph
 - notes
 - calendar
+- integrations
+- scheduling
+
+The calendar-related REST surface is split in two:
+
+- `/calendars/apple/*` covers event listing and reconciliation
+- `/integrations/apple/*` covers account connection, status, and preferences
 
 MCP routes are exposed separately, and chat now lives there rather than in the browser or REST surface. If you change a service contract or persistence rule, think about both transports.
 

contributing-docs/docs/testing-and-validation.md

@@ -105,5 +105,6 @@ The desired repository ruleset in `devtools/config/move37.repo.toml` currently l
 - `python`
 - `sdk`
 - `web`
+- `contributor-docs`
 
-That means the contributor-docs build exists in CI, but it is not yet declared as a required status check in the repo bootstrap config.
+That means contributor docs changes are part of the expected branch protection baseline, not just an optional CI signal.