Smartphone Building

Research rules and goals

Draft contract for review • 8 October 2026 • Target v1

Continuation status: the user authorized coordinated discovery and research on 8 October 2026. The first-checkpoint descriptions below preserve the earlier recovery context; they no longer indicate a pending permission step. Target-level numerical acceptance requirements remain open.

Later user revision: any discovery agent may submit additions through the shared automated add operation in scripts/add_discovery.py. It normalizes compact inventories, checks the whole selected graph, saves valid additions atomically and refreshes the map; circular dependencies fail with the exact loop and no registry changes. This supersedes earlier wording that reserved every insertion for the coordinator. Manual edits that bypass the gate remain prohibited. The coordinator performs later spot checks, identity coordination and deeper research assignments. The current memory-first seven-step procedure is in discovery-agent-prompt.md.

The goal

A group of knowledgeable people arrives on an Earth on which humans have never lived. They have no manufactured equipment, stock materials, buildings, electronics or utilities. They follow this project's instructions to make the physical hardware of one modern handset with flagship-equivalent capabilities. Software development is an explicit black-box allowance: compatible software may be installed after the hardware enters the real world. The finished handset must charge from a standard real-world charger and function on real-world networks. Exact quantitative performance targets remain to be researched and frozen; the phrase "high-end" is not an acceptance specification.

Cell towers, household outlets, standard external chargers and operating networks are external interfaces. They need not be manufactured in this project. The phone's charging connector and circuitry, battery management hardware, radio hardware, antennas, processor, memory and software-loading interface remain in scope. The operating system, firmware, applications, protocol software, development tools and control programs are black boxes; do not research source code, compiler creation or a software bootstrap chain. Still specify compatible hardware, the physical programming connection and the required software functions. Carrier subscription, SIM provisioning or network permissions are explicit external service conditions. These allowances never count as natural endpoints and do not supply physical workshop equipment or power.

For manufacturing equipment, list any required control software in a separate black-box requirements section with its function, host hardware and when it must be available. Do not assume software installed on the finished phone after import can control an earlier manufacturing step. The software itself needs no making page. Its computer, storage, controller, programmer, cables and electrical supply are physical requirements wherever needed. Final software and network compatibility tests may occur after import. Research closure refers to physical paths under these stated allowances, not a wholly self-contained recreation of software and external services.

Public designs or different materials may replace proprietary implementations if they meet the target capability. A simpler demonstration is a separate earlier tier, not a silent downgrade of the final phone. The project optimizes credible total setup and work for one successful phone, including necessary trial pieces and losses; it does not reproduce commercial throughput by default or promise a proven globally shortest route.

What every making page must contain

Use a simple title and the visible role Part or Tool. Materials and consumed inputs are Parts; power supplies and facility equipment are Tools. A process is a bounded making method inside a page. Software black boxes are boundary records outside manufacturing research; the hardware and tools that run or install them remain explicit.

The first paragraph states what the output does, which consumer needs it and the research status. A collapsible specification block holds the required capability: size and quantity; purity; dimensional precision and surface condition; mechanical, electrical, thermal or optical performance; compatible interfaces; environment; and acceptance tests. Unknown values say “not yet specified.” Do not invent tolerances or put technical strings in item names.

The page's mandatory core is an inventory of every known physical requirement. Record structural parts, feedstocks, consumables, fabrication tools, fixtures, work surfaces, containers, handling and transport equipment, lubricants, joining materials, water, heat, electrical supply, gases, vacuum, cooling, environmental controls, necessary protection and waste handling, measuring equipment, calibration references, and control hardware/software. Make explicit which are reused, incorporated, consumed or required for verification. An external article can carry detailed process data; it cannot replace this inventory.

Making steps show where those items are used. A Tool page explains how to make that tool; instructions for using it belong in its caller's steps. Split large assemblies into independently understandable subassemblies or operations. Aim for a core explanation of roughly 600–1,000 words, with sources and technical detail expandable. This is a readability target, never a quota that hides requirements. A grouped item must expose its contents and link to further making pages once its dependencies pass the gate.

Every page also lists primary sources, the claims each source supports, provenance from earlier work, unresolved requirements, rejected or pending alternatives, and next research actions. Source URLs alone do not establish a complete recipe or target-level capability. Review dimensions, units, uncertainty, measurement range, calibration and compatibility against the caller's actual demand.

No manufacturing loops

Before inventing a new dependency, researchers must inspect the current shared registry, proposals and build/inventory ledger, searching by function and aliases as well as name. Reuse a canonical tool or material when its capability, cleanliness, calibration, quantity and availability meet the caller's demand. Existing research does not itself mean an item is physically built or qualified. Each new ID needs a reuse assessment explaining which existing candidates were checked and why they cannot serve. Multiple required copies normally share one design and making page; consumables still need quantities and replenishment. Reuse cannot create a manufacturing cycle or silently substitute an inadequate capability. The coordinator checks duplicate proposals and maintains shared platform records; every caller still lists its own complete required inventory.

A dependency means that an output or qualified capability must exist before this item can be made or accepted. The selected build scenario is an acyclic graph: output → selected making route → every required output. An assembly's containment, citations, navigation history and reverse “used by” links are different relationships. A return link does not make the earlier phone a manufacturing prerequisite of its tool.

Agents submit structured proposals; they cannot edit live dependency links. A central gate validates IDs, route selection and the complete selected graph. It rejects self-dependencies, missing targets, stale proposals and cycles, including cycles formed across independently submitted changes. Updates are committed atomically. The page renderer draws dependency links exclusively from the validated selection; candidate dependencies remain unlinked draft text.

Alternative recipes are OR choices, while all requirements inside the chosen recipe are AND obligations. Combining incompatible alternatives into one apparent recipe is prohibited. Repeated operation, adjustment, recycling and rework can be legitimate only with a real earlier starting inventory and temporal accounting; they cannot create the first object or reference out of itself. Co-products and shared tool capacity need explicit quantities and scheduling.

Separate a basic tool from an advanced tool only when its capability and actual construction route differ. An earlier source may power or help manufacture its later replacement. Renaming the same power source, controller or meter cannot conceal circular prerequisites. An uncalibrated instrument and a calibrated instrument can be different states, but an independent earlier reference must establish the claimed accuracy.

Automation checks the declared graph. It cannot prove that an inventory is complete, a tier is physically different, a source supports a claim, or a process is feasible. A technical reviewer audits those questions, and experimentally demonstrated performance is a separate status. A cycle-free graph is necessary but insufficient.

Endpoints and evidence

A natural endpoint requires an identified, naturally available resource or phenomenon, a supported availability/quantity assumption and reviewer approval. Finding, recognizing, collecting, preparing and transporting it must be represented where required. Refined copper, clean water, sorted mineral stock, a workbench, electricity and a finished plug are not natural endpoints. A node with no known making route is an unexpanded frontier, not a completed path.

Use two independent labels. Evidence status progresses through Discovered, Inherited notes, Research draft, Source-checked, Reviewed, and Experimentally demonstrated. A recovered note retains its provenance and does not become source-checked merely because it contains a URL. Closure status is Open, Blocked, Closed to nature, or External interface. Research closure requires the specification, complete inventory, selected route, compatible prerequisites and endpoint evidence to be reviewed. Physical acceptance remains a separate claim.

Publish counts for the current target and graph revision: discovered inventory; discovered-but-unresearched percentage; inherited/drafted/source-checked/reviewed pages; selected routes; unresolved frontiers; blocked candidate relationships; reviewed natural endpoints; and manufacturing paths closed to nature. State each denominator, and show growth between snapshots. No page-count ratio is a percentage of the unknowable total phone project.

Research and review sequence

The coordinator owns target definitions, canonical IDs, integration, graph changes and publication. Domain researchers own bounded proposals. A separate reviewer checks omitted prerequisites, evidence and capability matching. Bootstrap/metrology/software specialists challenge self-supporting assumptions and search for earlier routes. At most six assistants can run beside the coordinator in this environment; use available Sol agents at medium effort for ordinary research and high/xhigh effort for integration and difficult reviews. Terra is not exposed here, so do not claim it is running.

First checkpoint and known limits

This publication is the requested upfront review checkpoint: contract, example prompt, recovered research pages, an initial discovery map and automatic graph checks. Bulk new manufacturing research starts after the user has reviewed this contract. It is not a completed encyclopedia.

The original chat-history listing failed in this session. The recovery covers accessible saved files, original HTML, prototype technical catalogs and the project conversation excerpts supplied here. It cannot claim all original chat turns were searched. Old rejected navigation stories may supply technical citations but cannot become current design decisions.

The research record contains Markdown rules/research, JSON nodes/routes/proposals, a validator, and generated HTML pages. The user has authorized about 25 GB on this computer. The build and export check that budget for the project and recovery folders. A downloadable export preserves the snapshot independently of browsing. A private GitHub repository is the recommended off-computer home for text and code, but no user repository has been selected or synced. Keep source citations as links instead of copying large papers, videos or images. Larger attachments need a separately chosen archive; do not increase the user's paid Google Drive usage or assume Dropbox has more than its free allowance. Actual snapshot size is shown in progress. Local working files alone are not an off-computer backup.

Storage choices and verified service limits are recorded in storage-plan.md. Sites has separate plan-specific beta limits, and this session has no verified remaining account quota. Hosted publication is blocked by the required source-upload connection; the standalone checkpoint is available for review.