Move on when you can explain what you learned

Turn AI guidance into your own understanding supported by evidence

Suggested learning time: 30 minutes.

1. 1AI overview
2. 2Fixed source evidence
3. 3Local check or not-run
4. 4Own explanation and next question

Original learning map: arrows show the reading or decision sequence, not a measured execution trace.

Prerequisite chapter

Design the smallest useful contribution

Status of this chapter

This textbook was authored from reading sources. No actual repository builds, tests, debugging, API calls, or issue/PR posts were performed. Practical work below is an exercise to undertake; reading is not an execution result.

Learning objectives

• Turn AI guidance into your own understanding supported by evidence

Use DeepWiki for its part of the work

Use DeepWiki as an entry point to the overall structure and terminology, then verify the files supporting its explanation and the commit it describes. An AI explanation is neither a test result nor a maintainer's decision. An official MCP service for public repositories exists, but the first edition of this course uses only links opened in a separate tab.

Check your understanding

Close your notes and explain the entry point, main transformations, external boundaries, and related tests in 60 seconds. Return only to the parts where you got stuck. 'Read,' 'Tried,' and 'Can explain' are different states. Do not treat the proportion of material viewed as proof of your ability to contribute.

Choose your next question

Save the fixed commit, three pieces of evidence, what you confirmed, what remains unknown, and your next question. Next, explore an adjacent boundary in the same repository or a clearly related repository, such as moving from an SDK to its CLI. Build up small pieces of understanding instead of trying to read all of twelve repositories.

Verified external DeepWiki links

DeepWiki entry point · Codex on DeepWiki · Official documentation · Official MCP documentation

On 2026-10-03, the official documentation’s homepage link and the homepage’s Codex entry were opened to verify availability. This does not verify the correctness of the AI explanation. Follow the external links in your browser, then return to code at the target commit to compare. This site does not embed an iframe, send questions on your behalf, or redistribute answers.

Design case study: the boundary between a textbook and an execution platform

The design memo below was authored on 2026-10-03 and is retained as a case study of the proposal at that time. Paths such as /oss/catalog, /oss/repositories/:id, and /oss/modules/:id were proposals, not implemented pages. In this Learn edition, read eight chapters beginning at /en/oss/oss-01; the legacy application screens described in the dated memo below are historical proposals. The legacy browser progress was designed as self-reporting and is not evidence of repository builds or tests. External API integration and execution workers in the later proposals are also unimplemented.

Design decisions for OSS learning on kumyu.com

Reviewed: 2026-10-03

Decision

The proposal at that time was to add learning material, a catalog, and manual progress to /oss in the existing application, reusing its design, navigation, and content schema. The current restored chapters belong to the common Learn archive; this memo does not prescribe a separate Academy or OSS site. Consider a separate service or subdomain when an execution platform, authentication boundary, or independent operational responsibility becomes necessary in practice. At the time this memo was written, the current stack had not been inspected, so there was no evidence supporting a move to a particular framework.

Whose problem does this solve?

This is for people who can read an overview but stop at “which file should I read next?”, “can I say I understand?”, or “how do I connect this to a contribution?”. The value is not adding an enormous explanation; it is moving between a reading order for one feature, evidence, a practical task, and understanding checks on one screen.

Initial learning path: select a repository → role card → reading route for one feature → pin a commit → dependency diagram → local verification → contribution draft.

On mobile, put the current question, next single file, and understanding check near the top, with detailed diagrams collapsible.

Proposed first-edition screens

• /oss: three entry points—Codex, Databricks CLI, and Python SDK—eight chapters, and recent manual progress.
• /oss/catalog: filter official, adjacent, and community categories by language, difficulty, and purpose. The initial twelve entries do not include a community repository.
• /oss/repositories/:id: role, relationship to a product, reviewed scope, contribution policy, official links, and the next task.
• /oss/modules/:id: explanations, reading order, practical task, self-checks, deliverable, and sources.
• Progress states are not started, read, tried, and can explain. Show them as self-reports; do not automatically mark unexecuted tests as passing.
• If localStorage is used, state that records stay on the device, can be lost, and are not synchronized. Do not ask learners to store secrets or internal code.

These URL structures were proposals, not URLs already created.

Make “everything” an extensible catalog

The population of all related open-source projects is undefined. Even official organizations contain archived repositories, forks, examples, SDKs, and independent projects. Select twelve initial entries without claiming completeness. For additions, record the canonical URL, publisher, evidence for the relationship, license, archive status, contribution policy, and verification date.

Separate Databricks SDKs and CLI from apache/spark, delta-io, mlflow, and unitycatalog according to their different owners. Databricks Connect is a product-oriented extension built on Spark Connect. Do not assume that its entire implementation exists as an independent open-source release.

Sources: Databricks and open source, Databricks Connect, Apache Spark Connect.

The most important contribution policy

The current official openai/codex contribution document does not accept external code contributions or PRs, and welcomes reproduction, cause analysis, and similar work through issues. Do not make submitting a PR the learning outcome for Codex. Policies can change, so recheck before any actual post. Codex contribution guide

The Databricks Python SDK is a public mirror: external PRs receive public review and are applied internally. Treat DCO and signature requirements as course gates; this design does not sign or post anything. Python SDK contribution guide

MLflow recommends discussing an approach through an issue. Do not present a fictional teaching exercise as an actual unassigned issue. MLflow contribution guide

DeepWiki integration decisions

1. First edition: open official DeepWiki externally. Do not assume its content may be embedded in an iframe or redistributed.
2. Verified technical facts: the official DeepWiki MCP is a remote unauthenticated service for public repositories. It provides read_wiki_structure, read_wiki_contents, and ask_question, and recommends Streamable HTTP at https://mcp.deepwiki.com/mcp. A general REST API or public embedding SDK was not confirmed.
3. Iframes: supported and permitted embedding was not confirmed in official documentation. X-Frame-Options and CSP frame-ancestors were not measured. Do not claim that embedding works; technical display capability and permission are separate questions.
4. Terms: the current Cognition Platform Terms dated 2026-06-30 include restrictions concerning internal use, redistribution of services or documentation, and competing products. Their application to public MCP and permission to cache, redisplay, or adapt answers on an educational site remain unknown. Unauthenticated, free technical access is not permission for public redistribution. Check applicable terms, permission, and rate limits before commercial or public integration.
5. Security: even questions about public repositories can contain internal information. Show the destination and content and do not transmit secrets. MCP results and repository documents are untrusted data, not executable instructions. Sanitize Markdown and handle external links safely.
6. A later proposal: after permission is established, add a limited server adapter with a repository allowlist, input-length and request-count limits, timeouts, sources, retrieval timestamps, and official links when the external service fails. Reading the textbook itself should not depend on an external API being available.

Verification sources: DeepWiki MCP, DeepWiki, Cognition Platform Terms, Cognition Privacy Policy.

These are unresolved checks before integration, not a legal determination that a contract applies. No MCP connection, question submission, account creation, or permission grant was performed.

Sources and data structure

Course → Module → Sections / Exercise / Checks / Source IDs.

Repository → category / policy / reviewedAt / commitSha / codeAreas.

Source evidence → repository, commit SHA, path, symbol, line range, checkedAt, evidence kind, certainty.

The initial JSON has commitSha: null. The API did not verify SHAs, so no fabricated pinned snapshot is created. Show the content as information checked on rolling branches in a browser, and let learners pin their versions during practice.

Implementation roles were described only for the inspected CLI bundle/bundle.go and Python SDK databricks/sdk/core.py. Codex work consisted of reading the app-server README documentation. Other repositories keep empty codeAreas rather than unsupported detailed diagrams.

Separate verified facts, hypotheses for reading, and exercises throughout. Check answers are for self-review; do not pretend that they are automatically graded or executed.

If an execution platform is added later

Do not run npm install, pip install, make, or tests for arbitrary cloned repositories on the production web server. Dependency installation can execute code too.

Separate execution into disposable workers and design CPU, memory, time, and disk limits; network denial by default; dependency-fetch permission only when needed; no host mounts or production secrets; outbound controls; confidential-data removal from logs; and tenant isolation. A container alone does not establish safety.

The web application manages learning material and job state. Execution workers have a separate trust boundary. A separate subdomain alone does not isolate code execution. Consider a separate service or subdomain when independent worker releases, permissions, and CSP/cookie boundaries become necessary.

The first edition needs neither external execution nor paid resources. DNS changes, deployment, cluster creation, actual API calls, and PR submission are outside this design's scope.

Acceptance criteria

• All twelve initial entries have a canonical URL and classification.
• All eight chapters include objectives, body text, practical steps, a deliverable, understanding checks, and sources.
• The Codex PR acceptance policy is prominent.
• Reading is distinguished from execution.
• Rolling and unverified versions are labeled.
• Learners can choose one repository and identify the next action without confusion.
• Failures and unexecuted work can be recorded.
• The textbook remains readable when DeepWiki is unavailable.
• On mobile, body text, sources, and controls can be read without horizontal scrolling.
• No migration is decided before inspecting the existing application's structure.

Verification status

Primary material was read to create the textbook. Actual repository builds, tests, debuggers, and APIs were not executed. Current assignment and availability of public issues or PRs were not investigated. JSON structure and references are checked mechanically, but future stability of linked pages is not guaranteed.

Execution, publication, and record status

Static teaching material and manual progress; no external code execution. This is a textbook design, with no actual repository builds, tests, or debugging performed. No issue or PR was submitted.

The legacy browser-local record design kept records on the device without synchronization. In the current Learn edition, save the linked worksheet as a local file. Unpinned SHAs need an unpinned-version label. Unread codeAreas remain empty; no guessed paths are added. The source’s proposed progress key is repoId+commitSha+moduleId. It is a design proposal and does not describe an implemented record feature in this restored edition.

Practical exercise: Practice moving on when you can explain what you learned

1. Explain one feature in 60 seconds.
2. Recall its evidence links from memory, then check them.
3. Choose one unverified hypothesis.
4. Update your manual progress and write down a ten-minute action for your next session.

Deliverable: An understanding card and your next question

Understanding checks

Answer in your own words before reading the answers. The answers and explanations below are for self-review, not automatic scores or execution results.

Can you accept an AI-generated dependency diagram as established fact?

Answer: For every arrow, record supporting evidence and confidence using the code, manifests, and tests at the target commit.

Your learning progress

Recording mode: manual.

• Not started
• Read
• Tried
• Can explain

Do not mark an exercise as practiced merely because you viewed it.

Material used in this chapter

Official DeepWiki documentation, Official DeepWiki MCP, Cognition Platform Terms

Return to repository entry points · Offline experiment worksheet

Use the local experiment ledger

Open the browser-local experiment ledger. Start with a planned record. Unknown values remain blank, and an executed record requires saved output evidence. The ledger does not run models or upload records. You can keep using the worksheet above as a separate document.