BranchesTags

Repository files navigation

PinPointCapture — documentation

Three folders, one question each.

FolderQuestion it answers
design/What should the product be?
implementation/What is built, and what is left?
conformance/Does it actually do what the protocol says?

design/ — what the product should be

FileWhat it is
capture-companion-requirements.mdThe PRD. 173 numbered requirements, the scope line, the use cases, the open decisions. The primary artefact — everything else refers back to it
capability-spike.mdWhat the hardware and iOS will actually do, and the parameter set the build is driven from. Every figure carries its provenance, and most are assumed rather than measured
mockup v1/README.mdThe design handoff. 17 screens, design tokens, copy treated as decisions, and the state semantics each screen encodes
mockup v1/design/The design reference as HTML — a prototype of look, copy and behaviour. Not production code; none of it is to be ported
mockup v1/screens/1× board captures of the screens, in flow order

implementation/ — what is built and what is left

FileWhat it is
delivery-scope.mdThe scope document. An audit of the current build by architectural layer, then sixteen epics cut into fifty-two capability levels. This is what seeds the GitHub Project board
traceability.mdThe traceability matrix. Every PRD requirement to its status, owning epic and level, and the evidence — plus a reverse index from level to the requirements it closes
mvp-online.mdThe delivery plan. ⚠ The only document that answers what is being built next, and in what order — the scope document is organised by capability level, which is the wrong axis for that question. Carries the online MVP's four requirements, the RV-6 work that gates them across three repositories, and the demo that says it is done
backlog.pyThe board's source. Generates the issue manifest behind the GitHub project — 91 issues and 16 labels. Edit it when a capability level changes in delivery-scope.md, so the board and the document cannot drift

conformance/ — whether it does what the protocol says

FileWhat it is
ppcp-conformance.mdThe conformance claim against PPCP-CONF. 47 rows, the findings raised against the specification, the interoperability runs, and an explicit list of what is deferred and on what
ppcp-conform.{json,md}The conformance tool's own output, regenerated by make conform. Generated — do not hand-edit
interop-*.jsonRun summaries from make interop and make conform-iop. Generated
bundles/Session bundles written by this implementation and by others, checked in as interoperability evidence

Reading order

New to the project: the PRD's §1–§4, then the design handoff, then delivery-scope.md §1.

Picking up work:mvp-online.md for what is next and why, then delivery-scope.md §3 for the epic, traceability.md for the requirements it closes, then the PRD for what those requirements actually say.

Wondering whether something is done:traceability.md. It is the only document that answers that question row by row, and its statuses are checked against the tree rather than against intent.

Keeping these honest

delivery-scope.md and traceability.md are audits, not plans — they go stale the moment code lands. mvp-online.mdis a plan and goes stale differently: it is wrong when the order changes, not when code lands. Re-check them when a capability level closes. The PRD's §18 summarises their position and should be re-checked at the same time.

When a capability level is added, split or reworded, change delivery-scope.mdandbacklog.py together. The script asserts its own counts, which is what caught a fifty-one-versus-fifty-two disagreement between them the first time round.

The conformance folder is different: ppcp-conformance.md is hand-written and ppcp-conform.* are generated, so a disagreement between them is a real signal rather than drift to be tidied away.

About

Mobile app companion for PinPointStudio

Resources

Readme
MIT license
Activity
Custom properties

Stars

0 stars

Watchers

0 watching

Forks

0 forks
Report repository

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
BranchesTags
Repository files navigation
PinPointCapture — documentation
Three folders, one question each.
FolderQuestion it answers
design/What should the product be?
implementation/What is built, and what is left?
conformance/Does it actually do what the protocol says?
design/ — what the product should be
FileWhat it is
capture-companion-requirements.mdThe PRD. 173 numbered requirements, the scope line, the use cases, the open decisions. The primary artefact — everything else refers back to it
capability-spike.mdWhat the hardware and iOS will actually do, and the parameter set the build is driven from. Every figure carries its provenance, and most are assumed rather than measured
mockup v1/README.mdThe design handoff. 17 screens, design tokens, copy treated as decisions, and the state semantics each screen encodes
mockup v1/design/The design reference as HTML — a prototype of look, copy and behaviour. Not production code; none of it is to be ported
mockup v1/screens/1× board captures of the screens, in flow order
implementation/ — what is built and what is left
FileWhat it is
delivery-scope.mdThe scope document. An audit of the current build by architectural layer, then sixteen epics cut into fifty-two capability levels. This is what seeds the GitHub Project board
traceability.mdThe traceability matrix. Every PRD requirement to its status, owning epic and level, and the evidence — plus a reverse index from level to the requirements it closes
mvp-online.mdThe delivery plan. ⚠ The only document that answers what is being built next, and in what order — the scope document is organised by capability level, which is the wrong axis for that question. Carries the online MVP's four requirements, the RV-6 work that gates them across three repositories, and the demo that says it is done
backlog.pyThe board's source. Generates the issue manifest behind the GitHub project — 91 issues and 16 labels. Edit it when a capability level changes in delivery-scope.md, so the board and the document cannot drift
conformance/ — whether it does what the protocol says
FileWhat it is
ppcp-conformance.mdThe conformance claim against PPCP-CONF. 47 rows, the findings raised against the specification, the interoperability runs, and an explicit list of what is deferred and on what
ppcp-conform.{json,md}The conformance tool's own output, regenerated by make conform. Generated — do not hand-edit
interop-*.jsonRun summaries from make interop and make conform-iop. Generated
bundles/Session bundles written by this implementation and by others, checked in as interoperability evidence
Reading order
New to the project: the PRD's §1–§4, then the design handoff, then delivery-scope.md §1.
Picking up work:mvp-online.md for what is next and why, then delivery-scope.md §3 for the epic, traceability.md for the requirements it closes, then the PRD for what those requirements actually say.
Wondering whether something is done:traceability.md. It is the only document that answers that question row by row, and its statuses are checked against the tree rather than against intent.
Keeping these honest
delivery-scope.md and traceability.md are audits, not plans — they go stale the moment code lands. mvp-online.mdis a plan and goes stale differently: it is wrong when the order changes, not when code lands. Re-check them when a capability level closes. The PRD's §18 summarises their position and should be re-checked at the same time.
When a capability level is added, split or reworded, change delivery-scope.mdandbacklog.py together. The script asserts its own counts, which is what caught a fifty-one-versus-fifty-two disagreement between them the first time round.
The conformance folder is different: ppcp-conformance.md is hand-written and ppcp-conform.* are generated, so a disagreement between them is a real signal rather than drift to be tidied away.
About
Mobile app companion for PinPointStudio
Resources
Readme
MIT license
Activity
Custom properties
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Repository files navigation
PinPointCapture — documentation
Three folders, one question each.
FolderQuestion it answers
design/What should the product be?
implementation/What is built, and what is left?
conformance/Does it actually do what the protocol says?
design/ — what the product should be
FileWhat it is
capture-companion-requirements.mdThe PRD. 173 numbered requirements, the scope line, the use cases, the open decisions. The primary artefact — everything else refers back to it
capability-spike.mdWhat the hardware and iOS will actually do, and the parameter set the build is driven from. Every figure carries its provenance, and most are assumed rather than measured
mockup v1/README.mdThe design handoff. 17 screens, design tokens, copy treated as decisions, and the state semantics each screen encodes
mockup v1/design/The design reference as HTML — a prototype of look, copy and behaviour. Not production code; none of it is to be ported
mockup v1/screens/1× board captures of the screens, in flow order
implementation/ — what is built and what is left
FileWhat it is
delivery-scope.mdThe scope document. An audit of the current build by architectural layer, then sixteen epics cut into fifty-two capability levels. This is what seeds the GitHub Project board
traceability.mdThe traceability matrix. Every PRD requirement to its status, owning epic and level, and the evidence — plus a reverse index from level to the requirements it closes
mvp-online.mdThe delivery plan. ⚠ The only document that answers what is being built next, and in what order — the scope document is organised by capability level, which is the wrong axis for that question. Carries the online MVP's four requirements, the RV-6 work that gates them across three repositories, and the demo that says it is done
backlog.pyThe board's source. Generates the issue manifest behind the GitHub project — 91 issues and 16 labels. Edit it when a capability level changes in delivery-scope.md, so the board and the document cannot drift
conformance/ — whether it does what the protocol says
FileWhat it is
ppcp-conformance.mdThe conformance claim against PPCP-CONF. 47 rows, the findings raised against the specification, the interoperability runs, and an explicit list of what is deferred and on what
ppcp-conform.{json,md}The conformance tool's own output, regenerated by make conform. Generated — do not hand-edit
interop-*.jsonRun summaries from make interop and make conform-iop. Generated
bundles/Session bundles written by this implementation and by others, checked in as interoperability evidence
Reading order
New to the project: the PRD's §1–§4, then the design handoff, then delivery-scope.md §1.
Picking up work:mvp-online.md for what is next and why, then delivery-scope.md §3 for the epic, traceability.md for the requirements it closes, then the PRD for what those requirements actually say.
Wondering whether something is done:traceability.md. It is the only document that answers that question row by row, and its statuses are checked against the tree rather than against intent.
Keeping these honest
delivery-scope.md and traceability.md are audits, not plans — they go stale the moment code lands. mvp-online.mdis a plan and goes stale differently: it is wrong when the order changes, not when code lands. Re-check them when a capability level closes. The PRD's §18 summarises their position and should be re-checked at the same time.
When a capability level is added, split or reworded, change delivery-scope.mdandbacklog.py together. The script asserts its own counts, which is what caught a fifty-one-versus-fifty-two disagreement between them the first time round.
The conformance folder is different: ppcp-conformance.md is hand-written and ppcp-conform.* are generated, so a disagreement between them is a real signal rather than drift to be tidied away.
About
Mobile app companion for PinPointStudio
Resources
Readme
MIT license
Activity
Custom properties
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Repository files navigation
PinPointCapture — documentation
Three folders, one question each.
FolderQuestion it answers
design/What should the product be?
implementation/What is built, and what is left?
conformance/Does it actually do what the protocol says?
design/ — what the product should be
FileWhat it is
capture-companion-requirements.mdThe PRD. 173 numbered requirements, the scope line, the use cases, the open decisions. The primary artefact — everything else refers back to it
capability-spike.mdWhat the hardware and iOS will actually do, and the parameter set the build is driven from. Every figure carries its provenance, and most are assumed rather than measured
mockup v1/README.mdThe design handoff. 17 screens, design tokens, copy treated as decisions, and the state semantics each screen encodes
mockup v1/design/The design reference as HTML — a prototype of look, copy and behaviour. Not production code; none of it is to be ported
mockup v1/screens/1× board captures of the screens, in flow order
implementation/ — what is built and what is left
FileWhat it is
delivery-scope.mdThe scope document. An audit of the current build by architectural layer, then sixteen epics cut into fifty-two capability levels. This is what seeds the GitHub Project board
traceability.mdThe traceability matrix. Every PRD requirement to its status, owning epic and level, and the evidence — plus a reverse index from level to the requirements it closes
mvp-online.mdThe delivery plan. ⚠ The only document that answers what is being built next, and in what order — the scope document is organised by capability level, which is the wrong axis for that question. Carries the online MVP's four requirements, the RV-6 work that gates them across three repositories, and the demo that says it is done
backlog.pyThe board's source. Generates the issue manifest behind the GitHub project — 91 issues and 16 labels. Edit it when a capability level changes in delivery-scope.md, so the board and the document cannot drift
conformance/ — whether it does what the protocol says
FileWhat it is
ppcp-conformance.mdThe conformance claim against PPCP-CONF. 47 rows, the findings raised against the specification, the interoperability runs, and an explicit list of what is deferred and on what
ppcp-conform.{json,md}The conformance tool's own output, regenerated by make conform. Generated — do not hand-edit
interop-*.jsonRun summaries from make interop and make conform-iop. Generated
bundles/Session bundles written by this implementation and by others, checked in as interoperability evidence
Reading order
New to the project: the PRD's §1–§4, then the design handoff, then delivery-scope.md §1.
Picking up work:mvp-online.md for what is next and why, then delivery-scope.md §3 for the epic, traceability.md for the requirements it closes, then the PRD for what those requirements actually say.
Wondering whether something is done:traceability.md. It is the only document that answers that question row by row, and its statuses are checked against the tree rather than against intent.
Keeping these honest
delivery-scope.md and traceability.md are audits, not plans — they go stale the moment code lands. mvp-online.mdis a plan and goes stale differently: it is wrong when the order changes, not when code lands. Re-check them when a capability level closes. The PRD's §18 summarises their position and should be re-checked at the same time.
When a capability level is added, split or reworded, change delivery-scope.mdandbacklog.py together. The script asserts its own counts, which is what caught a fifty-one-versus-fifty-two disagreement between them the first time round.
The conformance folder is different: ppcp-conformance.md is hand-written and ppcp-conform.* are generated, so a disagreement between them is a real signal rather than drift to be tidied away.
About
Mobile app companion for PinPointStudio
Resources
Readme
MIT license
Activity
Custom properties
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
BranchesTags
Repository files navigation
PinPointCapture — documentation
Three folders, one question each.
FolderQuestion it answers
design/What should the product be?
implementation/What is built, and what is left?
conformance/Does it actually do what the protocol says?
design/ — what the product should be
FileWhat it is
capture-companion-requirements.mdThe PRD. 173 numbered requirements, the scope line, the use cases, the open decisions. The primary artefact — everything else refers back to it
capability-spike.mdWhat the hardware and iOS will actually do, and the parameter set the build is driven from. Every figure carries its provenance, and most are assumed rather than measured
mockup v1/README.mdThe design handoff. 17 screens, design tokens, copy treated as decisions, and the state semantics each screen encodes
mockup v1/design/The design reference as HTML — a prototype of look, copy and behaviour. Not production code; none of it is to be ported
mockup v1/screens/1× board captures of the screens, in flow order
implementation/ — what is built and what is left
FileWhat it is
delivery-scope.mdThe scope document. An audit of the current build by architectural layer, then sixteen epics cut into fifty-two capability levels. This is what seeds the GitHub Project board
traceability.mdThe traceability matrix. Every PRD requirement to its status, owning epic and level, and the evidence — plus a reverse index from level to the requirements it closes
mvp-online.mdThe delivery plan. ⚠ The only document that answers what is being built next, and in what order — the scope document is organised by capability level, which is the wrong axis for that question. Carries the online MVP's four requirements, the RV-6 work that gates them across three repositories, and the demo that says it is done
backlog.pyThe board's source. Generates the issue manifest behind the GitHub project — 91 issues and 16 labels. Edit it when a capability level changes in delivery-scope.md, so the board and the document cannot drift
conformance/ — whether it does what the protocol says
FileWhat it is
ppcp-conformance.mdThe conformance claim against PPCP-CONF. 47 rows, the findings raised against the specification, the interoperability runs, and an explicit list of what is deferred and on what
ppcp-conform.{json,md}The conformance tool's own output, regenerated by make conform. Generated — do not hand-edit
interop-*.jsonRun summaries from make interop and make conform-iop. Generated
bundles/Session bundles written by this implementation and by others, checked in as interoperability evidence
Reading order
New to the project: the PRD's §1–§4, then the design handoff, then delivery-scope.md §1.
Picking up work:mvp-online.md for what is next and why, then delivery-scope.md §3 for the epic, traceability.md for the requirements it closes, then the PRD for what those requirements actually say.
Wondering whether something is done:traceability.md. It is the only document that answers that question row by row, and its statuses are checked against the tree rather than against intent.
Keeping these honest
delivery-scope.md and traceability.md are audits, not plans — they go stale the moment code lands. mvp-online.mdis a plan and goes stale differently: it is wrong when the order changes, not when code lands. Re-check them when a capability level closes. The PRD's §18 summarises their position and should be re-checked at the same time.
When a capability level is added, split or reworded, change delivery-scope.mdandbacklog.py together. The script asserts its own counts, which is what caught a fifty-one-versus-fifty-two disagreement between them the first time round.
The conformance folder is different: ppcp-conformance.md is hand-written and ppcp-conform.* are generated, so a disagreement between them is a real signal rather than drift to be tidied away.
About
Mobile app companion for PinPointStudio
Resources
Readme
MIT license
Activity
Custom properties
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Repository files navigation
PinPointCapture — documentation
Three folders, one question each.
FolderQuestion it answers
design/What should the product be?
implementation/What is built, and what is left?
conformance/Does it actually do what the protocol says?
design/ — what the product should be
FileWhat it is
capture-companion-requirements.mdThe PRD. 173 numbered requirements, the scope line, the use cases, the open decisions. The primary artefact — everything else refers back to it
capability-spike.mdWhat the hardware and iOS will actually do, and the parameter set the build is driven from. Every figure carries its provenance, and most are assumed rather than measured
mockup v1/README.mdThe design handoff. 17 screens, design tokens, copy treated as decisions, and the state semantics each screen encodes
mockup v1/design/The design reference as HTML — a prototype of look, copy and behaviour. Not production code; none of it is to be ported
mockup v1/screens/1× board captures of the screens, in flow order
implementation/ — what is built and what is left
FileWhat it is
delivery-scope.mdThe scope document. An audit of the current build by architectural layer, then sixteen epics cut into fifty-two capability levels. This is what seeds the GitHub Project board
traceability.mdThe traceability matrix. Every PRD requirement to its status, owning epic and level, and the evidence — plus a reverse index from level to the requirements it closes
mvp-online.mdThe delivery plan. ⚠ The only document that answers what is being built next, and in what order — the scope document is organised by capability level, which is the wrong axis for that question. Carries the online MVP's four requirements, the RV-6 work that gates them across three repositories, and the demo that says it is done
backlog.pyThe board's source. Generates the issue manifest behind the GitHub project — 91 issues and 16 labels. Edit it when a capability level changes in delivery-scope.md, so the board and the document cannot drift
conformance/ — whether it does what the protocol says
FileWhat it is
ppcp-conformance.mdThe conformance claim against PPCP-CONF. 47 rows, the findings raised against the specification, the interoperability runs, and an explicit list of what is deferred and on what
ppcp-conform.{json,md}The conformance tool's own output, regenerated by make conform. Generated — do not hand-edit
interop-*.jsonRun summaries from make interop and make conform-iop. Generated
bundles/Session bundles written by this implementation and by others, checked in as interoperability evidence
Reading order
New to the project: the PRD's §1–§4, then the design handoff, then delivery-scope.md §1.
Picking up work:mvp-online.md for what is next and why, then delivery-scope.md §3 for the epic, traceability.md for the requirements it closes, then the PRD for what those requirements actually say.
Wondering whether something is done:traceability.md. It is the only document that answers that question row by row, and its statuses are checked against the tree rather than against intent.
Keeping these honest
delivery-scope.md and traceability.md are audits, not plans — they go stale the moment code lands. mvp-online.mdis a plan and goes stale differently: it is wrong when the order changes, not when code lands. Re-check them when a capability level closes. The PRD's §18 summarises their position and should be re-checked at the same time.
When a capability level is added, split or reworded, change delivery-scope.mdandbacklog.py together. The script asserts its own counts, which is what caught a fifty-one-versus-fifty-two disagreement between them the first time round.
The conformance folder is different: ppcp-conformance.md is hand-written and ppcp-conform.* are generated, so a disagreement between them is a real signal rather than drift to be tidied away.
About
Mobile app companion for PinPointStudio
Resources
Readme
MIT license
Activity
Custom properties
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Repository files navigation
PinPointCapture — documentation
Three folders, one question each.
FolderQuestion it answers
design/What should the product be?
implementation/What is built, and what is left?
conformance/Does it actually do what the protocol says?
design/ — what the product should be
FileWhat it is
capture-companion-requirements.mdThe PRD. 173 numbered requirements, the scope line, the use cases, the open decisions. The primary artefact — everything else refers back to it
capability-spike.mdWhat the hardware and iOS will actually do, and the parameter set the build is driven from. Every figure carries its provenance, and most are assumed rather than measured
mockup v1/README.mdThe design handoff. 17 screens, design tokens, copy treated as decisions, and the state semantics each screen encodes
mockup v1/design/The design reference as HTML — a prototype of look, copy and behaviour. Not production code; none of it is to be ported
mockup v1/screens/1× board captures of the screens, in flow order
implementation/ — what is built and what is left
FileWhat it is
delivery-scope.mdThe scope document. An audit of the current build by architectural layer, then sixteen epics cut into fifty-two capability levels. This is what seeds the GitHub Project board
traceability.mdThe traceability matrix. Every PRD requirement to its status, owning epic and level, and the evidence — plus a reverse index from level to the requirements it closes
mvp-online.mdThe delivery plan. ⚠ The only document that answers what is being built next, and in what order — the scope document is organised by capability level, which is the wrong axis for that question. Carries the online MVP's four requirements, the RV-6 work that gates them across three repositories, and the demo that says it is done
backlog.pyThe board's source. Generates the issue manifest behind the GitHub project — 91 issues and 16 labels. Edit it when a capability level changes in delivery-scope.md, so the board and the document cannot drift
conformance/ — whether it does what the protocol says
FileWhat it is
ppcp-conformance.mdThe conformance claim against PPCP-CONF. 47 rows, the findings raised against the specification, the interoperability runs, and an explicit list of what is deferred and on what
ppcp-conform.{json,md}The conformance tool's own output, regenerated by make conform. Generated — do not hand-edit
interop-*.jsonRun summaries from make interop and make conform-iop. Generated
bundles/Session bundles written by this implementation and by others, checked in as interoperability evidence
Reading order
New to the project: the PRD's §1–§4, then the design handoff, then delivery-scope.md §1.
Picking up work:mvp-online.md for what is next and why, then delivery-scope.md §3 for the epic, traceability.md for the requirements it closes, then the PRD for what those requirements actually say.
Wondering whether something is done:traceability.md. It is the only document that answers that question row by row, and its statuses are checked against the tree rather than against intent.
Keeping these honest
delivery-scope.md and traceability.md are audits, not plans — they go stale the moment code lands. mvp-online.mdis a plan and goes stale differently: it is wrong when the order changes, not when code lands. Re-check them when a capability level closes. The PRD's §18 summarises their position and should be re-checked at the same time.
When a capability level is added, split or reworded, change delivery-scope.mdandbacklog.py together. The script asserts its own counts, which is what caught a fifty-one-versus-fifty-two disagreement between them the first time round.
The conformance folder is different: ppcp-conformance.md is hand-written and ppcp-conform.* are generated, so a disagreement between them is a real signal rather than drift to be tidied away.
About
Mobile app companion for PinPointStudio
Resources
Readme
MIT license
Activity
Custom properties
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
BranchesTags
Repository files navigation
PinPointCapture — documentation
Three folders, one question each.
FolderQuestion it answers
design/What should the product be?
implementation/What is built, and what is left?
conformance/Does it actually do what the protocol says?
design/ — what the product should be
FileWhat it is
capture-companion-requirements.mdThe PRD. 173 numbered requirements, the scope line, the use cases, the open decisions. The primary artefact — everything else refers back to it
capability-spike.mdWhat the hardware and iOS will actually do, and the parameter set the build is driven from. Every figure carries its provenance, and most are assumed rather than measured
mockup v1/README.mdThe design handoff. 17 screens, design tokens, copy treated as decisions, and the state semantics each screen encodes
mockup v1/design/The design reference as HTML — a prototype of look, copy and behaviour. Not production code; none of it is to be ported
mockup v1/screens/1× board captures of the screens, in flow order
implementation/ — what is built and what is left
FileWhat it is
delivery-scope.mdThe scope document. An audit of the current build by architectural layer, then sixteen epics cut into fifty-two capability levels. This is what seeds the GitHub Project board
traceability.mdThe traceability matrix. Every PRD requirement to its status, owning epic and level, and the evidence — plus a reverse index from level to the requirements it closes
mvp-online.mdThe delivery plan. ⚠ The only document that answers what is being built next, and in what order — the scope document is organised by capability level, which is the wrong axis for that question. Carries the online MVP's four requirements, the RV-6 work that gates them across three repositories, and the demo that says it is done
backlog.pyThe board's source. Generates the issue manifest behind the GitHub project — 91 issues and 16 labels. Edit it when a capability level changes in delivery-scope.md, so the board and the document cannot drift
conformance/ — whether it does what the protocol says
FileWhat it is
ppcp-conformance.mdThe conformance claim against PPCP-CONF. 47 rows, the findings raised against the specification, the interoperability runs, and an explicit list of what is deferred and on what
ppcp-conform.{json,md}The conformance tool's own output, regenerated by make conform. Generated — do not hand-edit
interop-*.jsonRun summaries from make interop and make conform-iop. Generated
bundles/Session bundles written by this implementation and by others, checked in as interoperability evidence
Reading order
New to the project: the PRD's §1–§4, then the design handoff, then delivery-scope.md §1.
Picking up work:mvp-online.md for what is next and why, then delivery-scope.md §3 for the epic, traceability.md for the requirements it closes, then the PRD for what those requirements actually say.
Wondering whether something is done:traceability.md. It is the only document that answers that question row by row, and its statuses are checked against the tree rather than against intent.
Keeping these honest
delivery-scope.md and traceability.md are audits, not plans — they go stale the moment code lands. mvp-online.mdis a plan and goes stale differently: it is wrong when the order changes, not when code lands. Re-check them when a capability level closes. The PRD's §18 summarises their position and should be re-checked at the same time.
When a capability level is added, split or reworded, change delivery-scope.mdandbacklog.py together. The script asserts its own counts, which is what caught a fifty-one-versus-fifty-two disagreement between them the first time round.
The conformance folder is different: ppcp-conformance.md is hand-written and ppcp-conform.* are generated, so a disagreement between them is a real signal rather than drift to be tidied away.
About
Mobile app companion for PinPointStudio
Resources
Readme
MIT license
Activity
Custom properties
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages