Program Yourself -- PERSONAL Knowledge Management (PKM)

PKM is about knowledge managed for a particular purpose, specifically for PRIORITIZATION or use of better intelligence gathering, to improve information and obtain better knowledge to drive improvements in optimized portfolios of time/resources.

Maybe you just want to start by reading some of the notes on our thinking captured in the daily journal of this PKM process. Or, maybe you'd find that a little unnerving or overwhelming ... or just plain useless.

We use information technology because the per dollar power of compute or all technologies available for knowledge processing multiplies by a factor of 10 every five years ... and has done so for some time. Given the social nature of shared knowledge, that might just be the defining character of the human intelligence explaining much of the dominance of our species relative to other species.

That same increase in information technology competence has been holding true for at least 150 years or much longer, with greater than tenfold growth [in terms of processing power per $] over the last 50 years ... whereas the overall economy, eg vehicles, equipment, buildings, houses, industrial systems, appliances, other durable products and services, basically struggle to double [every five years] in terms of real value or actual levels of productivity or value provided per dollar of purchasing power.

In the last decade or so, there has been a solid, sustained, continuing trend toward integrating AI tools into specialized workflows to enhance efficiency and decision-making -- AI tools for these things is not about the hype; it's all about the proven value for business value addition possible by mastering AI tools, toolchains, workflows. PKM is about doing that, in a verifiable way, for improving the productivity of one's personal knowledge management skillset.

The Process Of Managing Knowledge Is About Thinking About The Context of How We Think

As we attempt to go through the process of building out this Personal Knowledge Management (PKM) system, you might ask why would we be trying or how are we trying to improve our personal knowledge management toolchain or what's the big idea behind PKM ... or maybe you want to track the project details of our progress on the PKM build as we work through the phases in the 100-day process.

Personal Knowledge Management Is PERSONAL Context Engineering

Engineering context is about asking questions, sifting, organizing,understanding, organizing, re-organizing information ... in order to have better context, to become better at asking questions and understanding responses.

Developing a PKM system includes various structures of assuring context for coherent processing ... any sort of news, sports, weather data that is pushed at you by others who manage your information flow is going to be about somebody else's context -- thus, effectively managing one's personal knowledge is entirely about context engineering and developing the architecture of the toolchains that one uses to engineer context -- of course, AI has made it possible for mere mortals, not superprogrammers, to develop the tools that give us the KNOWLEDGE that we need to shape our lives.

It is up to each of us to DEVELOP our LIVES ... not to LIVE LARGE according to the larger purpose that we have discerned from our Creator -- not live small order to be someone's customer, employee, spectator, constituent or soldier. We are not to live in order to follow our neighbor's rules -- we are to LIVE to follow the purpose our Creator put us on Earth for. Others might have clues ... but no other human knows or should direct us!*

DEVELOPING our lives, DEVELOPING our knowledge must be done judiciously, with discernment ... but aggressively USING the talents, tools, technologies that we have been blessed with ... thus, programming ourselves is a matter of expressing gratitude -- we do it in order to continue to more fully develop the richness of our lives, to take responsiblity for programming ourselves, mastering and wielding information technology in order to understand its danger and misuse, as we INFORM ourselves. Many who just consume content or food are VERY EFFECTIVELY being weaponized to be weak, hyper-defensive, reactionary liabilities to their communities, their circles of friends or professional colleagues, their families, themselves.

Both the PKM and PKE systems are implementations based on the both best thinking in extending our intellectual capabilities, such as Building a Second Brain (BASB) or other thinking that drives some of the best personal knowledge notetaking digital tools. In other words, both the PKM and PKM curricula are therefore exercises in reinventing wheels to some degree, because they involve mastering and tweaking technologies and tool which already function plenty well without any further automation or AI/ML ops engineering heavy lifting.

The real point, is not so much about the tech-assisted development of these capablities, and really using all of the tools and technologies such as the free and open source distributed version control system, Git and various forms of Git workflows and improved approaches to Git branching. Using Git only scratches the surface of what kinds of features that a hub like GitHub provides such Actions, for automating workflows or Projects, Discussions, and Issues to drive development. Of course, using Git and GitHub typically involves using full-featured integrated development environments (IDEs) like Visual Studio Code well developed AI-assisted extensions for those IDEs such as Cline utilizing the best LLM models on OpenRouter ... but as a next step, we realize that development use cases must be able to accomplished with tools like code-in-browser tools like ONA which runs VS Code entirely on any device with sandboxed dev environments either in the Ona cloud or your VPC, to run full VS Code in the browser or also on a smartphone. ... moving to ONA for agentic multi-environment development, to allow for parallel-track AI-assisted work as development workflows evolve over time.

The real point or true objective of all this, is not so much about the tech-assisted development of these capablities, rather, it is a meta-objective, which is about stretching or extending human cognitive capabilities with these technologies for proficiencies necessary to pursue even more advanced levels of knowledge engineering.

The 100-Day Architect: A Blueprint for an AI-Augmented PKM System

You can, and probably should, use your own preferences and needs for a PKM to develop a better system for you for accomplishing this objective ... the important thing however, is to just get started with some sort of viable 100-day plan and then just steadily work at it. You can tear the plan up and start over after 30 days, but it's important to just get a plan to together that breaks down the work into manageable daily chunks and then get after it.

Introduction: The PKM as a Development Project

This report outlines a 100-day, 100-module plan for the systematic overhaul and AI-augmentation of a Personal Knowledge Management (PKM) system. The core philosophy of this endeavor is to treat the PKM not as a static repository of notes, but as a dynamic, evolving software project. This approach transforms the act of knowledge management from passive collection into an active process of system architecture, development, and continuous improvement. The 100-day journey is structured as a comprehensive development lifecycle, progressing from foundational infrastructure setup to the implementation of advanced, custom-built, AI-driven features.

The architecture of this system is organized into five distinct phases, each building upon the capabilities established in the previous one. This creates a layered "stack" of functionality, starting with a solid, version-controlled foundation and culminating in a highly intelligent, automated environment for learning and exploration.

A central architectural decision underpins this entire plan: the positioning of the GitHub ecosystem as the core operating system for the PKM. The user's goal to gain experience with GitHub Actions, Issues, Projects, and Discussions is not treated as a separate learning objective but as the strategic foundation for the entire system.1 This unified platform provides the necessary components to manage a complex, multi-tool environment. GitHub Issues will serve as the primary interface for managing the lifecycle of each knowledge topic, from initial idea to completed exploration.3 GitHub Projects will provide the high-level roadmaps and Kanban boards for tracking progress across all learning endeavors.5 Most critically, GitHub Actions will function as the system's central automation engine—its "kernel"—orchestrating every other component, from note processing and AI analysis to the final publication of the knowledge base.1 This integrated approach ensures that all disparate tools work in concert, managed by a single, powerful, and version-controlled platform.

Technology Stack and Phased Integration

The following table provides a strategic overview of the technologies to be integrated throughout this 100-day project. It outlines each component's primary role within the PKM ecosystem and the specific phases during which it will be introduced and mastered. This serves as a high-level roadmap, clarifying not only what will be learned, but when and why it is being introduced into the system architecture.

Phase I: The Developer's Knowledge Foundation (Modules 1-20)

Focus: Establishing a rock-solid, automated foundation for the PKM. This phase is about building the "scaffolding" and the core "DevOps" pipeline for your knowledge.

Modules 1-5: Project Scaffolding with GitHub

The initial modules focus on establishing the project's central repository, which will serve as the single source of truth for all knowledge, code, and configuration. This is the foundational step in treating the PKM as a formal development project.

1. Repository Creation and Initialization: A new private repository will be created on GitHub. This repository will house the entire PKM system, including Markdown notes, automation scripts, configuration files, and the mdBook source. Initializing the repository with a README.md file, a .gitignore file (configured for Python, Node.js, and Rust build artifacts), and a clear directory structure (/notes, /scripts, /book_src) is the first task.
2. GitHub Projects for Meta-Tracking: Before managing knowledge topics, the system must manage itself. A GitHub Project will be created to track the progress of this 100-day plan.5 This project will be configured with a Kanban board layout, with columns such as "To Do," "In Progress," and "Done".2 This provides immediate, practical experience with the project management tools that will later be applied to learning topics.
3. Structuring the 100-Day Plan as GitHub Issues: Each of the 100 modules in this plan will be created as a distinct GitHub Issue.3 This modularizes the work and allows for detailed tracking. Using GitHub's issue creation features, each module can be documented, discussed, and managed individually.2
4. Custom Fields and Project Views: The GitHub Project will be enhanced with custom fields to add rich metadata to each module's Issue. Fields such as "Phase" (e.g., "I: Foundation"), "Status" (e.g., "Not Started"), and "Technology" (e.g., "GitHub Actions") will be created.3 This allows for the creation of powerful, filtered views, such as a roadmap layout to visualize the timeline or a table view to group modules by technology.2
5. Establishing Branching Strategy and Workflow: A simple Git branching strategy, such as GitFlow or a main-branch workflow, will be established. All work will be done on feature branches and merged into the main branch via pull requests. This enforces good version control hygiene from the outset and prepares the project for automated checks and workflows that trigger on pull requests.3

Modules 6-10: Mastering the VSCode + Foam Environment

With the repository structured, the focus shifts to configuring the local development and note-taking environment. VSCode, augmented with the Foam extension, provides a powerful, free, and open-source platform for creating and navigating a graph-based knowledge base.8

6. VSCode and Foam Workspace Setup: The process begins by cloning the newly created GitHub repository to a local machine. Following the official Foam documentation, the foam-template project will be used to scaffold the necessary workspace configuration within the repository.8 This involves setting up the
   .vscode/settings.json and .vscode/extensions.json files, which define the workspace's behavior and recommend essential extensions.8
7. Core Foam Features - Linking and Graphing: This module is a deep dive into Foam's core functionality. The focus will be on creating atomic notes—single files dedicated to a single topic—and connecting them using [[wikilinks]].9 Practical exercises will involve creating a few sample notes and linking them to observe how the knowledge graph is built. The
   Foam: Show Graph command will be used to visualize these connections, providing a tangible representation of the relationships between ideas.9
8. Navigation and Discovery with Backlinks: Understanding connections is a two-way street. This module will explore Foam's backlinking capabilities. The Backlinks Panel will be used to see which other notes reference the currently active note, providing crucial context and aiding in the discovery of emergent themes and relationships within the knowledge base.9
9. Installation and Review of Recommended Extensions: The foam-template recommends a set of VSCode extensions to enhance the Markdown editing experience.8 This module involves installing and reviewing this list, which typically includes tools like
   Markdown All In One, Prettier for formatting, and extensions for Mermaid diagrams and emoji support.12 Understanding the role of each extension is key to customizing the environment for maximum productivity.
10. Customizing VSCode Settings: The default Foam settings provide a great starting point, but personalization is key. This module involves editing the .vscode/settings.json file to tweak the user experience. This could include changing editor fonts, setting rulers for line length, or customizing how wikilinks are rendered in the editor, ensuring the environment is perfectly tailored to the user's workflow.8

Modules 11-15: mdBook Configuration and Initial Build

The next step is to configure mdBook, the Rust-based tool that will transform the collection of Markdown notes into a clean, searchable, and publishable static website.14

11. Installing mdBook and Initializing the Book: mdBook will be installed using Rust's package manager, Cargo. Once installed, the mdbook init command will be run within the /book_src directory of the repository. This command creates the initial file structure for the book, including the src directory for content and the all-important SUMMARY.md file, which defines the book's navigation structure.14
12. Configuring book.toml: The book.toml file is the heart of an mdBook project's configuration. This module involves a thorough exploration of its key options.15 The book's title and author will be set, and the HTML renderer options will be configured. This includes enabling or disabling section labels, adding a link to the source GitHub repository, and selecting a default theme.15
13. Structuring the SUMMARY.md: The SUMMARY.md file dictates the table of contents and navigation hierarchy of the final website. This module will focus on understanding its syntax. A basic structure will be created, linking to the sample notes created in the Foam modules. This establishes the initial organization of the public-facing knowledge base.
14. Enabling and Configuring Search: One of mdBook's most powerful features is its built-in, client-side search functionality. In the book.toml file, the search feature will be explicitly enabled and configured.15 Options like
    limit-results, use-boolean-and, and boost-title will be explored to understand how to fine-tune the search experience for users of the knowledge base.15
15. Performing the First Manual Build: With the initial configuration in place, the mdbook build command will be run from the command line. This compiles the Markdown files from the src directory into a static HTML site in a new /book directory. The resulting site will be opened locally in a browser to verify that the configuration is correct, the links work as expected, and the overall structure is sound. This manual build serves as the baseline for the automated pipeline to come.16

Modules 16-20: The First Automated CI/CD Pipeline

This is the capstone of Phase I, where the manual processes of building and deploying are automated using GitHub Actions. This creates a Continuous Integration/Continuous Deployment (CI/CD) pipeline that ensures the published knowledge base is always in sync with the latest notes.17

16. Creating the First Workflow File: A new workflow file will be created at .github/workflows/deploy-book.yml. This YAML file will define the automation steps. The workflow will be configured to trigger on a push event to the main branch, meaning it will run automatically every time new changes are committed.16
17. Configuring the GitHub Actions Job: The workflow will contain a single job, build-and-deploy. This job will be configured to run on an ubuntu-latest runner. The first steps within the job will be to use the actions/checkout action to check out the repository's code onto the runner.17
18. Installing mdBook on the Runner: To build the book, mdBook must be available on the CI runner. The most efficient method is to download a pre-compiled binary from the GitHub Releases page, which is fast and avoids the need to install the entire Rust toolchain.16 A workflow step will use
    curl to download and extract the mdBook executable.16
19. Building and Deploying to GitHub Pages: The core of the workflow involves two steps. First, a step will run the mdbook build command, generating the static site in the /book directory. Second, a community action like peaceiris/actions-gh-pages will be used to deploy the contents of the /book directory to a special gh-pages branch in the repository.18 Repository settings will be configured to enable GitHub Pages and set the
    gh-pages branch as the deployment source.19
20. Identifying the "Impedance Mismatch" and a Manual Workaround: Upon the first successful deployment, a critical challenge will become apparent. The [[wikilinks]] used for fluid navigation within Foam and VSCode are not standard Markdown links and will be broken in the final mdBook output.8 This "impedance mismatch" between the authoring environment and the publishing tool is a central technical hurdle of the chosen stack. Foam provides a command,
    Foam: Create markdown references for [[wikilinks]], which converts these links into a format that mdBook can understand.9 This module concludes by documenting this issue and establishing the manual execution of this command as a temporary workaround. This deliberate identification of a problem creates a clear and compelling motivation for developing a more sophisticated, automated scripting solution in later phases, transforming a potential frustration into a core learning objective of the 100-day plan.

Phase II: Architecting the Knowledge Graph (Modules 21-40)

Focus: Developing a systematic approach to knowledge capture, organization, and presentation. This phase moves from "getting the tools to work" to "using the tools effectively."

Modules 21-25: Knowledge Ingestion Framework

With the foundational infrastructure in place, the focus now shifts to establishing a structured process for exploring the 150 bucket-list topics. This involves leveraging GitHub's project management tools to create a systematic knowledge ingestion pipeline.

21. Creating the "Topic Exploration" Project Board: A new GitHub Project will be created specifically for managing the 150 learning topics. This project will be configured as a Kanban board, providing a visual workflow for tracking topics as they move from idea to exploration.2
22. Designing a Standardized Issue Template for Topics: To ensure consistency, a GitHub Issue template will be designed for new topics. This template, stored as a Markdown file in the .github/ISSUE_TEMPLATE directory, will pre-populate new issues with a standardized structure.3 Sections will include "Topic Summary," "Key Questions to Answer," "Initial Resources," and "Potential Connections," guiding the initial phase of research for any new subject.
23. Populating the Backlog with Initial Topics: As a practical exercise, the first 10-15 topics from the user-provided list of 150 will be created as new Issues using the template designed in the previous module. These issues will form the initial "backlog" in the "Topic Exploration" project board.3
24. Using Custom Fields for Topic Metadata: The project board will be enhanced with custom fields tailored for knowledge exploration. Fields like "Topic Category" (e.g., "Technology," "History," "Science"), "Priority" (e.g., "High," "Medium," "Low"), and "Status" (e.g., "Backlog," "Researching," "Synthesizing," "Published") will be added to provide richer metadata for each topic.5
25. Linking Issues to a Milestone: To group related learning goals, a GitHub Milestone will be created, for example, "Q3 Learning Goals." A subset of the topic issues will be assigned to this milestone. This introduces another layer of organization, allowing for tracking progress against larger, time-bound objectives.2

Modules 26-30: Advanced Foam Techniques

This section moves beyond the basics of Foam to leverage its more powerful features for structuring and maintaining a high-quality knowledge graph.9

26. Creating and Using Note Templates: To standardize the format of different types of notes, Foam's template feature will be implemented. Templates for various knowledge artifacts—such as book summaries, biographies, project overviews, or technology explainers—will be created. Using the Foam: Create New Note from Template command will then become the standard workflow, ensuring consistency and reducing repetitive work.9
27. Mastering the Tag Explorer and Hierarchical Tags: Tags are a crucial tool for non-hierarchical organization. This module focuses on using the Tag Explorer panel to navigate the knowledge base. A tagging convention will be established, and the power of hierarchical tags (e.g., #tech/python/automation) will be explored to create more granular and organized connections between notes.9
28. Managing Orphans and Placeholders: A healthy knowledge graph is a connected one. This module addresses graph maintenance by focusing on the "Orphans" and "Placeholders" panels in Foam.9 Orphans (notes with no links) and Placeholders (links to non-existent notes) will be regularly reviewed. A workflow will be established to either integrate orphaned notes into the graph or create new notes for placeholders, ensuring the knowledge base remains coherent and interconnected.10
29. Embedding Note Content: To create composite documents and avoid content duplication, Foam's note embedding feature (![[note-name]]) will be utilized. This allows the content of one note to be dynamically included within another. This is particularly useful for creating "Maps of Content" (MOCs) or summary pages that pull in information from multiple atomic notes.9
30. Leveraging Section Linking and Aliases: For more precise connections, linking to specific sections within a note (]) will be practiced.9 Additionally, link aliasing (
    [[note-name|custom display text]]) will be used to make links more readable and context-friendly within the body of a note, improving the overall narrative flow of the written content.9

Modules 31-35: Python for PKM - The First Scripts

This section marks the introduction of custom automation with Python. The initial scripts will focus on automating common maintenance and organization tasks within the knowledge base, demonstrating the power of scripting to manage the PKM at scale.21

31. Setting Up the Python Environment: A local Python development environment will be configured. This includes installing a recent version of Python and using a virtual environment manager like venv to isolate project dependencies. The first script will be a simple "hello world" to verify the setup.
32. Script 1: File Organizer based on Frontmatter: The first practical script will be a file organizer. This Python script will iterate through all Markdown files in the /notes directory. It will parse the YAML frontmatter of each file to read metadata (e.g., category: 'Technology'). Based on this metadata, the script will automatically move the file into a corresponding subdirectory (e.g., /notes/technology/). This automates a tedious organization task and introduces file system operations with Python's os module.22
33. Script 2: Batch Tagging Utility: Building on the previous script, a batch tagging utility will be created. This script will take a directory and a tag as command-line arguments. It will then scan all files in that directory and append the specified tag to their frontmatter tag list. This is useful for applying a new project tag or category to a group of existing notes simultaneously.21
34. Reading and Consolidating Notes: A script will be developed to demonstrate content processing. This script will read multiple text files (e.g., daily log files named YYYY-MM-DD.md) and consolidate their content into a single weekly or monthly summary file. This introduces file reading and writing operations and is a foundational step for more complex content analysis later on.21
35. Integrating Scripts with the Command Line: The scripts will be enhanced to be more user-friendly by using Python's argparse module to handle command-line arguments. This makes them more flexible and reusable, transforming them from simple scripts into proper command-line tools for PKM management.

Modules 36-40: Enhancing mdBook Presentation

The final part of this phase focuses on customizing the appearance and functionality of the public-facing mdBook site, ensuring it is not just a repository of information but a polished and professional presentation of knowledge.

36. Creating a Custom Theme: While mdBook comes with default themes, creating a custom look is essential for personalization. This module involves creating a theme directory and adding custom CSS files to override the default styles. This could involve changing colors, fonts, and layout to match a personal aesthetic.15
37. Adding Custom JavaScript for Interactivity: To add dynamic behavior, custom JavaScript files will be integrated. This could be used for simple enhancements like adding a "back to top" button, or more complex features like integrating an external analytics service or adding interactive UI elements.15
38. Integrating Preprocessors for Rich Content: mdBook's functionality can be extended with preprocessors. This module will explore adding support for features not natively included in Markdown. For example, the mdbook-mermaid preprocessor will be configured to allow for the rendering of Mermaid.js diagrams and flowcharts directly from code blocks, and MathJax support will be enabled for rendering complex mathematical equations.15
39. Configuring a Professional Deployment: To ensure the deployed site functions correctly, especially with custom domains or subdirectories, the site-url option in book.toml will be properly configured. This is crucial for ensuring that links, CSS, and JavaScript files load correctly on the live server.16
40. Customizing the 404 Error Page: A professional site needs a helpful error page. A custom 404.md file will be created in the src directory. mdBook will automatically convert this into a 404.html page that provides better navigation and user experience for visitors who encounter a broken link, which is a significant improvement over a generic server error.16

Phase III: AI Augmentation - The Intelligent Assistant (Modules 41-60)

Focus: Integrating a multi-tiered AI strategy to automate content processing and generate new insights. This is the core "AI-ification" phase.

Modules 41-45: AI Gateway Setup - OpenRouter & Google AI Studio

This section lays the groundwork for all future AI integration by setting up access to powerful, flexible AI models through API gateways. This approach provides access to a wide variety of models without being locked into a single provider.

41. Creating an OpenRouter Account: OpenRouter serves as a unified API gateway to hundreds of AI models from various providers like Anthropic, Google, and Meta.23 An account will be created, and the dashboard will be explored to understand its features, including model availability, pricing, and usage tracking.24
42. Generating and Securing API Keys: An API key will be generated from the OpenRouter dashboard. To maintain security best practices, this key will not be hard-coded into any scripts. Instead, it will be stored as an encrypted "secret" in the GitHub repository settings.1 This allows GitHub Actions workflows to securely access the key at runtime without exposing it in the codebase.
43. Introduction to Google AI Studio: Google AI Studio is a web-based tool for rapidly prototyping prompts and experimenting with Google's Gemini family of models.26 It provides an intuitive interface for testing different prompting strategies without writing any code, making it an ideal environment for initial exploration and "vibe coding".26
44. Prototyping PKM Prompts in AI Studio: Using Google AI Studio, several prompts tailored for PKM tasks will be developed and tested. This includes crafting system prompts for an AI assistant that can summarize long articles, extract key entities (people, places, concepts), generate a list of questions about a topic, or rephrase complex text into simpler terms. The iterative nature of the AI Studio playground allows for quick refinement of these prompts.28
45. Understanding API Quotas and Billing: A crucial part of using cloud-based AI is managing costs. This module involves reviewing the billing and quota systems for both OpenRouter and Google AI. A budget will be set, and the prepaid credit system of OpenRouter will be explored as a way to control spending.23 Understanding the per-token pricing for different models is essential for making cost-effective choices later on.24

Modules 46-50: Your First AI-Powered Python Script

With API access established, the next step is to bring AI capabilities into the local development environment through Python scripting.

46. Setting up the Python Environment for API Calls: The Python environment will be prepared by installing necessary libraries, such as requests for making HTTP calls or a provider-specific SDK like openai which is compatible with the OpenRouter API endpoint.23

47. Script 3: The AI Summarizer: The first AI-powered script will be a text summarizer. This Python script will:
    a. Read the content of a specified Markdown file from the /notes directory.
    b. Construct a prompt using the text content.
    c. Make a POST request to the OpenRouter API endpoint (/api/v1/chat/completions), passing the prompt and selecting a powerful general-purpose model like anthropic/claude-3.5-sonnet or meta-llama/llama-3.1-405b-instruct.24

    d. Parse the JSON response to extract the generated summary.
    e. Print the summary to the console.

48. Handling API Keys and Responses in Python: The summarizer script will be refactored to securely access the API key from an environment variable rather than hard-coding it. Error handling will also be added to gracefully manage potential API issues, such as network errors, authentication failures, or rate limiting.30

49. Writing Summaries Back to Files: The script will be enhanced to be more useful. Instead of just printing the summary, it will be modified to write the summary back into the original Markdown file. A good practice is to add it to the YAML frontmatter under a summary: key or in a dedicated ## AI Summary section at the end of the file.

50. Exploring OpenRouter Parameters: The OpenRouter API offers numerous parameters to control model behavior, such as temperature, max_tokens, and top_p.30 This module involves experimenting with these parameters in the Python script to observe their effect on the quality, length, and creativity of the generated summaries, allowing for fine-tuning of the AI's output.

Modules 51-55: Specialized Models with Hugging Face

While API gateways are excellent for general-purpose tasks, some tasks benefit from specialized, fine-tuned models. Hugging Face is the leading platform for accessing these models.32

51. Introduction to the Hugging Face Hub and Transformers Library: This module provides an overview of the Hugging Face ecosystem. The Hugging Face Hub will be explored to find models specifically fine-tuned for summarization. The transformers Python library, which provides a high-level API for using these models, will be installed.32

52. Implementing the Summarization Pipeline: The transformers library offers a pipeline abstraction that simplifies the process of using a model for a specific task.34 A new Python script will be created that initializes a
    summarization pipeline, specifying a well-regarded model like facebook/bart-large-cnn.32

53. Script 4: Hugging Face Summarizer: This script will use the initialized pipeline to summarize a piece of text. The code is often simpler than a direct API call:
    Python
    from transformers import pipeline

    # Load the summarization pipeline with a specific model
    summarizer = pipeline("summarization", model="facebook/bart-large-cnn")

    ARTICLE = """ Your long text content here... """
    summary = summarizer(ARTICLE, max_length=150, min_length=40, do_sample=False)
    print(summary)

    This script will be tested on the same notes used in the OpenRouter module to compare results.32

54. Comparing General vs. Specialized Models: This module involves a qualitative analysis comparing the summaries generated by the general-purpose model via OpenRouter and the specialized BART model from Hugging Face. The comparison will focus on aspects like factual accuracy, coherence, conciseness, and relevance to the source text. This provides a practical understanding of the trade-offs between using large, general models and smaller, task-specific ones.

55. Integrating Hugging Face into the Workflow: The Hugging Face summarizer script will be integrated into the existing PKM workflow. It will be adapted to read from and write to files, just like the OpenRouter script, making it a viable alternative for the summarization task within the broader system.

Modules 56-60: Developing a Tiered AI Strategy

This section synthesizes the experiences from the previous modules into a coherent, strategic framework for using AI. Instead of treating each AI service as an isolated tool, the system will be designed to use them as a portfolio of resources, deployed intelligently based on the task's requirements.

56. Defining the Tiers: Cost, Speed, Privacy, Capability: The AI resources available (OpenRouter, Hugging Face, and soon, local models via Ollama) will be categorized into tiers. For example:
    • Tier 1 (Local/Fast): Local Ollama models for low-cost, private, and fast tasks like simple text formatting or brainstorming.
    • Tier 2 (Specialized/Efficient): Hugging Face models for specific, well-defined tasks like summarization where a fine-tuned model excels.
    • Tier 3 (Powerful/Cloud): State-of-the-art models via OpenRouter for complex reasoning, high-quality content generation, or tasks requiring the largest context windows.
57. Building a Python "Router" Function: A Python function or class will be created to encapsulate this tiered logic. This AIManager will have a method like process_text(task_type, text, priority). Based on the task_type (e.g., 'summarize', 'generate_questions') and priority, this function will decide which AI service and model to call.
58. Implementing the Routing Logic: The AIManager will be implemented. For a 'summarize' task, it might default to the Hugging Face pipeline. For a 'brainstorm' task, it might use a local Ollama model. For a high-priority 'analyze_complex_document' task, it would route the request to a top-tier model through OpenRouter. This elevates the system from making simple API calls to making intelligent, resource-aware decisions.
59. Creating a Reusable AI Toolkit: The AIManager and its related functions will be organized into a reusable Python module within the /scripts directory. This toolkit will be imported by all future automation scripts, ensuring that the tiered AI strategy is applied consistently across the entire PKM system.
60. Formalizing the Model Selection Framework: The decision-making logic will be documented in a table. This framework serves as a quick reference for choosing the right tool for any given knowledge work task, moving from a reactive "what can this model do?" mindset to a proactive "what is the best model for this job?" approach.

Phase IV: Hyper-Automation and Advanced Workflows (Modules 61-80)

Focus: Creating proactive, fully automated pipelines that require minimal manual intervention. This phase builds the "intelligent nervous system" of the PKM.

Modules 61-70: Advanced GitHub Actions Workflows

This section focuses on creating a sophisticated, multi-stage GitHub Action that fully automates the process of content enrichment, connecting the file system, Python scripts, AI models, and the deployment pipeline.

61. Designing the "Content Enrichment" Workflow: A new, more advanced GitHub Actions workflow will be designed. The goal is to create a system that automatically processes a new note, enriches it with AI-generated content, and deploys the result without any manual steps.
62. Triggering Workflows with Path Filters and Tags: The workflow will be configured to trigger conditionally. It will run on pushes to the main branch but only when files in the /notes directory are modified. A convention will be established where adding a specific tag, like #summarize, to a note's frontmatter signals the workflow to process that specific file.
63. Workflow Step: Identifying Target Files: The first step in the Action's job will be to identify which files have been changed in the latest commit and need processing. A simple shell script or a dedicated GitHub Action can be used to get the list of modified files.
64. Workflow Step: Running the AI Python Script: The workflow will then set up the Python environment and run the AIManager script developed in Phase III. The script will be called with the path to the modified file as an argument.
65. Workflow Step: Committing Changes Back to the Repository: After the Python script runs and modifies the note file (e.g., by adding a summary), the GitHub Action must commit this change back to the repository. This requires configuring Git within the action, setting a user and email, and using git commit and git push. A special commit message like "chore(AI): Add summary to [filename]" will be used to denote automated changes.
66. Handling Recursive Workflow Triggers: A critical challenge in this setup is that the workflow pushes a commit, which would normally trigger the workflow again, creating an infinite loop. This will be prevented by adding a condition to the commit step or the workflow trigger to ignore commits made by the Actions bot itself (e.g., by checking the commit message).
67. Chaining Workflows: Instead of putting everything in one massive file, the content enrichment workflow will be configured to trigger the existing mdBook deployment workflow upon its successful completion. This can be done using the workflow_run event or by using a reusable "callable" workflow, which is a more modern approach.
68. Adding an Issue Commenting Step: To provide feedback, a final step will be added to the workflow. Using an action like peter-evans/create-or-update-comment, the workflow will find the corresponding GitHub Issue for the topic and post a comment indicating that the note has been automatically updated and a new version has been deployed, including a link to the published page.
69. Full End-to-End Test: A full test of the pipeline will be conducted. A new note will be created locally, tagged for summarization, and pushed to GitHub. The process will be monitored in the GitHub Actions tab, from the initial trigger to the AI processing, the commit back, the mdBook deployment, and the final comment on the issue.
70. Refactoring for Reusability: The workflow will be refactored to make it more modular. The Python script execution and the mdBook deployment steps will be broken into separate, reusable composite actions or callable workflows, making the main workflow file cleaner and easier to maintain.7

Modules 71-75: Local LLMs with Ollama

This section introduces local large language models using Ollama, adding a powerful, private, and cost-effective tier to the AI strategy.35

71. Installing and Configuring Ollama: Ollama will be installed on the local machine. The command-line interface will be used to pull down a versatile, medium-sized model like Llama 3 (ollama pull llama3) or a smaller, efficient model like Phi-2 (ollama pull phi-2).35
72. Interacting with Local Models via CLI and API: The first interactions will be through the command line using ollama run llama3. This provides a feel for the model's performance and personality. Subsequently, the Ollama REST API, which runs locally on port 11434, will be explored. A tool like curl or Postman will be used to send requests to the API, demonstrating how to interact with the local model programmatically.36
73. Creating a Custom Model with a Modelfile: To tailor a model for specific PKM tasks, a Modelfile will be created.37 This file defines a custom model based on a parent model (e.g.,
    FROM llama3). It will include a SYSTEM prompt to give the model a specific persona, such as a "Socratic Inquisitor" whose role is to respond to any text by generating three probing questions to deepen understanding. Parameters like temperature can also be set to control creativity.38
74. Building and Running the Custom Model: The ollama create command will be used to build the custom model from the Modelfile, giving it a unique name (e.g., socratic-inquisitor). This new model will then be available to run via ollama run socratic-inquisitor and through the API.37
75. Integrating Ollama into the Python AI Toolkit: The AIManager Python module will be updated to include Ollama as a new AI provider. A new function will be added that makes API calls to the local Ollama server. The routing logic will be updated to use the local model for specific tasks, such as brainstorming or generating questions, officially adding the "Tier 1 (Local)" capability to the system.36

Modules 76-80: Containerization with Docker

To ensure the PKM system's environment is consistent, portable, and reproducible, this section introduces containerization using Docker. This brings professional DevOps practices to the personal project.

76. Introduction to Docker Concepts: The core concepts of Docker will be reviewed: images, containers, Dockerfiles, and volumes. The benefits of containerization for creating isolated and predictable environments will be discussed.
77. Running Ollama in a Docker Container: As a first practical step, instead of running Ollama directly on the host machine, it will be run inside a Docker container using the official ollama/ollama image.35 This involves running the container, mapping the necessary ports, and using a volume to persist the downloaded models, ensuring they are not lost when the container stops.
78. Writing a Dockerfile for the Python Scripts: A Dockerfile will be written for the PKM's Python automation tools. This file will define a custom image that:
    a. Starts from a base Python image.
    b. Copies the requirements.txt file and installs the dependencies.
    c. Copies the /scripts directory into the image.
    d. Sets up any necessary environment variables.
79. Building and Running the Custom Python Container: The docker build command will be used to create an image from the Dockerfile. Then, docker run will be used to start a container from this image and execute one of the automation scripts, demonstrating that the entire toolchain can run in a self-contained environment.
80. Exploring Other Self-Hosted PKM Tools: Docker makes it easy to experiment with other open-source tools. This module involves exploring the Docker images for other self-hosted PKM platforms like Memos or Siyuan.39 By running these tools locally in containers, new ideas and features can be discovered and potentially incorporated into the custom PKM system, all without polluting the host machine with new dependencies.

Phase V: Frontier Exploration and Custom Tooling (Modules 81-100)

Focus: Pushing the boundaries of PKM by building high-performance, custom components and exploring next-generation AI platforms.

Modules 81-90: High-Performance PKM with Rust

This section directly addresses the "impedance mismatch" problem identified in Phase I by building a custom, high-performance command-line utility in Rust. This provides a tangible, valuable project that motivates learning a new, more complex language and demonstrates a clear progression in technical capability.

81. Setting up the Rust Development Environment: The Rust toolchain, including rustup and cargo, will be installed. A new binary crate will be created using cargo new foam-link-converter. The basics of the Rust language will be explored, focusing on concepts relevant to this project: file system operations, string manipulation, and error handling.
82. Designing the Link Conversion Utility: The command-line tool's logic will be designed. It will need to:
    a. Accept a directory path as a command-line argument.
    b. Recursively walk through the directory to find all .md files.
    c. For each file, read its content into a string.
    d. Use regular expressions to find all instances of Foam's [[wikilink]] syntax.
    e. For each found wikilink, determine the correct relative path to the target file.
    f. Replace the [[wikilink]] with a standard Markdown link ([wikilink](./path/to/file.md)).
    g. Write the modified content back to the file.
83. Implementing File System Traversal in Rust: The first part of the implementation will focus on safely and efficiently traversing the notes directory. Rust libraries like walkdir will be used for this purpose.
84. Parsing and Replacing Links with Regex: Rust's powerful regex crate will be used to implement the core link-finding and replacement logic. This module will focus on crafting a robust regular expression that can handle simple links, aliases, and section links.
85. Handling Edge Cases and Path Logic: A simple replacement is not enough. The tool must be intelligent. For a link like [[my-note]], the tool needs to find the file my-note.md within the directory structure and calculate the correct relative path from the source file to the target file. This involves path manipulation using Rust's standard library.
86. Compiling for Performance: The Rust code will be compiled in release mode (cargo build --release). The performance of this compiled binary will be compared to a hypothetical Python script performing the same task, highlighting the significant speed advantage of a compiled language like Rust for I/O- and CPU-intensive tasks. This provides a concrete demonstration of moving up the "performance ladder" from interpreted to compiled languages.
87. Integrating the Rust Tool into the GitHub Action: The compiled binary will be checked into the repository or built as part of the CI process. The main GitHub Actions workflow will be modified to run this custom utility as a build step before mdbook build is called. This completely automates the solution to the wikilink problem.
88. Exploring Other Rust-Based PKM Tools: To gain further inspiration from the Rust ecosystem, notable open-source PKM tools written in Rust, such as AppFlowy and Joplin, will be reviewed.41 Examining their architecture and feature sets can provide ideas for future enhancements to the custom system.
89. Publishing the Crate (Optional): As an extension, the foam-link-converter utility can be published to crates.io, Rust's public package registry. This provides experience with the full lifecycle of creating and sharing an open-source tool.
90. Finalizing the Automated Linking Workflow: The end-to-end workflow is now complete. A user can write notes in VSCode using fluid [[wikilinks]], push the changes to GitHub, and the automated pipeline will use a custom-built, high-performance Rust utility to seamlessly convert the links for publication with mdBook. This represents a significant engineering achievement within the PKM project.

Modules 91-95: Exploring the Modular Platform (Mojo & MAX)

This section ventures into the cutting edge of AI infrastructure, exploring the Modular Platform to understand how to achieve state-of-the-art performance for AI tasks.42

91. Introduction to Modular, Mojo, and MAX: The Modular ecosystem will be introduced. Mojo is a programming language that combines the usability of Python with the performance of C and Rust, designed specifically for AI developers.43 MAX is Modular's suite of AI libraries and tools for high-performance inference.45
92. Installing the Modular SDK: The Modular SDK will be installed, providing access to the Mojo compiler and MAX tools. The native VSCode extension for Mojo will also be installed to get syntax highlighting and language support.42
93. Writing "Hello World" in Mojo: The first Mojo program will be written and compiled. This will introduce Mojo's syntax, which is a superset of Python, and concepts like strong typing with var and fn for function definitions.44
94. Running a Pre-Optimized Model with MAX Serving: The power of the MAX platform will be demonstrated by running a pre-optimized model from the Modular model repository. Using the max serve command, an OpenAI-compatible API endpoint will be started locally, serving a model like Llama 3.45 The performance (tokens per second) of this endpoint will be observed and compared to other inference methods, showcasing the benefits of Modular's optimizations.43
95. Experimenting with a Mojo Script: A simple Mojo script will be written to interact with the MAX-served model. This provides a glimpse into how Mojo can be used to write the high-performance "glue code" for AI applications, bridging the gap between Python's ease of use and the need for speed in production AI systems.43

Modules 96-100: Capstone Project - The "Topic Delver" Agent

This final project synthesizes all the skills and components developed over the previous 95 days into a single, powerful, and fully automated "agent" that actively assists in the knowledge exploration process.

96. Designing the "Topic Delver" Agent Workflow: A master GitHub Action will be designed. This workflow will trigger when a GitHub Issue on the "Topic Exploration" project board is moved into the "Researching" column. This project management action becomes the starting signal for the automated agent.1
97. Step 1: Initial Information Gathering (Python + OpenRouter): The workflow will trigger a Python script. This script will take the title of the GitHub Issue as input. It will use the OpenRouter API to query a powerful model, instructing it to perform a simulated web search to find 3-5 key articles, videos, or papers related to the topic.23
98. Step 2: Generating Foundational Questions (Python + Ollama): The script will then take the gathered resources and the issue summary and pass them to the custom "socratic-inquisitor" model running locally via Ollama. The model's task is to generate a list of 5-10 foundational questions that should be answered to gain a deep understanding of the topic.35
99. Step 3: Creating the "Topic Hub" Note: The Python script will then create a new Markdown file in the /notes directory. The filename will be based on the issue title. This file will be pre-populated using a template that includes the list of resources gathered by OpenRouter and the foundational questions generated by Ollama.
100. Step 4: Finalizing and Notifying (Rust, mdBook, GitHub API): The workflow will then execute the custom Rust foam-link-converter utility to ensure all links are correct. It will commit the new note file to the repository, which in turn triggers the mdBook deployment workflow. As a final step, the workflow will use the GitHub API to post a comment back to the original Issue, stating: "The Topic Hub has been created. You can view the note here:," completing the automated loop from task management to knowledge creation. This capstone project exemplifies a truly AI-augmented PKM system, where the system itself becomes an active partner in the process of learning and exploration.

Works cited

1. Automating Projects using Actions - GitHub Docs, accessed September 1, 2025, https://docs.github.com/en/issues/planning-and-tracking-with-projects/automating-your-project/automating-projects-using-actions
2. Planning and tracking with Projects - GitHub Docs, accessed September 1, 2025, https://docs.github.com/en/issues/planning-and-tracking-with-projects
3. GitHub Issues · Project planning for developers, accessed September 1, 2025, https://github.com/features/issues
4. Using GitHub issues to manage my tasks because I got tired of all the markdown files. : r/ClaudeAI - Reddit, accessed September 1, 2025, https://www.reddit.com/r/ClaudeAI/comments/1mozlq0/using_github_issues_to_manage_my_tasks_because_i/
5. About Projects - GitHub Docs, accessed September 1, 2025, https://docs.github.com/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects
6. kamranahmedse/developer-roadmap: Interactive roadmaps, guides and other educational content to help developers grow in their careers. - GitHub, accessed September 1, 2025, https://github.com/kamranahmedse/developer-roadmap
7. I saved 10+ of repetitive manual steps using just 4 GitHub Actions workflows - Reddit, accessed September 1, 2025, https://www.reddit.com/r/devops/comments/1jbajbr/i_saved_10_of_repetitive_manual_steps_using_just/
8. A personal knowledge management and sharing system for VSCode - Foam, accessed September 1, 2025, https://foambubble.github.io/foam/
9. foambubble/foam: A personal knowledge management and sharing system for VSCode - GitHub, accessed September 1, 2025, https://github.com/foambubble/foam
10. Foam - Visual Studio Marketplace, accessed September 1, 2025, https://marketplace.visualstudio.com/items?itemName=foam.foam-vscode
11. Recommended Extensions | Foam, accessed September 1, 2025, https://foam-template-gatsby-kb.vercel.app/recommended-extensions
12. Recommended Extensions - Foam, accessed September 1, 2025, https://foambubble.github.io/foam/user/getting-started/recommended-extensions.html
13. Visual Studio Code Extensions - thecrumb, accessed September 1, 2025, https://www.thecrumb.com/posts/2022-12-21-my-vscode-extensions/
14. Introduction - mdBook Documentation, accessed September 1, 2025, https://rust-lang.github.io/mdBook/
15. Renderers - mdBook Documentation - GitHub Pages, accessed September 1, 2025, https://rust-lang.github.io/mdBook/format/configuration/renderers.html
16. Continuous Integration - mdBook Documentation - GitHub Pages, accessed September 1, 2025, https://rust-lang.github.io/mdBook/continuous-integration.html
17. Creating Your First CI/CD Pipeline Using GitHub Actions | by Brandon Kindred - Medium, accessed September 1, 2025, https://brandonkindred.medium.com/creating-your-first-ci-cd-pipeline-using-github-actions-81c668008582
18. peaceiris/actions-gh-pages: GitHub Actions for GitHub Pages Deploy static files and publish your site easily. Static-Site-Generators-friendly., accessed September 1, 2025, https://github.com/peaceiris/actions-gh-pages
19. Step by step to publish mdBook in gh-pages · Issue #1803 - GitHub, accessed September 1, 2025, https://github.com/rust-lang/mdBook/issues/1803
20. How to build mdBook with Github Actions | by katopz | Medium - Level Up Coding, accessed September 1, 2025, https://levelup.gitconnected.com/how-to-build-mdbook-with-github-actions-eb9899e55d7e
21. Beginner's Guide To Python Automation Scripts (With Code ..., accessed September 1, 2025, https://zerotomastery.io/blog/python-automation-scripts-beginners-guide/
22. 19 Super-Useful Python Scripts to Automate Your Daily Tasks - Index.dev, accessed September 1, 2025, https://www.index.dev/blog/python-automation-scripts
23. OpenRouter: A unified interface for LLMs | by Dagang Wei | Medium, accessed September 1, 2025, https://medium.com/@weidagang/openrouter-a-unified-interface-for-llms-eda4742a8aa4
24. Community Providers: OpenRouter - AI SDK, accessed September 1, 2025, https://ai-sdk.dev/providers/community-providers/openrouter
25. Models - OpenRouter, accessed September 1, 2025, https://openrouter.ai/models
26. Google AI Studio | Gemini API | Google AI for Developers, accessed September 1, 2025, https://ai.google.dev/aistudio
27. Google AI Studio, accessed September 1, 2025, https://aistudio.google.com/
28. Google AI Studio quickstart - Gemini API, accessed September 1, 2025, https://ai.google.dev/gemini-api/docs/ai-studio-quickstart
29. Google AI Studio for Beginners - YouTube, accessed September 1, 2025, https://www.youtube.com/watch?v=IHOJUJjZbzc
30. OpenRouter API Reference | Complete API Documentation ..., accessed September 1, 2025, https://openrouter.ai/docs/api-reference/overview
31. Completion | OpenRouter | Documentation, accessed September 1, 2025, https://openrouter.ai/docs/api-reference/completion
32. Summarizing Text Using Hugging Face's BART Model - DEV Community, accessed September 1, 2025, https://dev.to/dm8ry/summarizing-text-using-hugging-faces-bart-model-14p5
33. How to Build A Text Summarizer Using Huggingface Transformers - freeCodeCamp, accessed September 1, 2025, https://www.freecodecamp.org/news/how-to-build-a-text-summarizer-using-huggingface-transformers/
34. Pipelines - Hugging Face, accessed September 1, 2025, https://huggingface.co/docs/transformers/main_classes/pipelines
35. How to Run LLMs Locally with Ollama - Medium, accessed September 1, 2025, https://medium.com/cyberark-engineering/how-to-run-llms-locally-with-ollama-cb00fa55d5de
36. Running LLM Locally: A Beginner's Guide to Using Ollama | by Arun Patidar | Medium, accessed September 1, 2025, https://medium.com/@arunpatidar26/running-llm-locally-a-beginners-guide-to-using-ollama-8ea296747505
37. ollama/ollama: Get up and running with OpenAI gpt-oss ... - GitHub, accessed September 1, 2025, https://github.com/ollama/ollama
38. Learn Ollama in 15 Minutes - Run LLM Models Locally for FREE - YouTube, accessed September 1, 2025, https://www.youtube.com/watch?v=UtSSMs6ObqY
39. usememos/memos: A modern, open-source, self-hosted knowledge management and note-taking platform designed for privacy-conscious users and organizations. - GitHub, accessed September 1, 2025, https://github.com/usememos/memos
40. siyuan-note/siyuan: A privacy-first, self-hosted, fully open source personal knowledge management software, written in typescript and golang. - GitHub, accessed September 1, 2025, https://github.com/siyuan-note/siyuan
41. Best Open Source Personal Knowledge ... - OpenAlternative, accessed September 1, 2025, https://openalternative.co/categories/personal-knowledge-management-pkm/using/rust
42. Modular: A Fast, Scalable Gen AI Inference Platform, accessed September 1, 2025, https://www.modular.com/
43. Modular Documentation | Modular, accessed September 1, 2025, https://docs.modular.com/
44. Get started with Mojo - Modular docs, accessed September 1, 2025, https://docs.modular.com/mojo/manual/get-started/
45. The Modular Platform (includes MAX & Mojo) - GitHub, accessed September 1, 2025, https://github.com/modular/modular

Why are trying to accomplish with developing this PKM OR how are we trying to improve our personal knowledge management toolchain?

Continuous Self-Improvement

Not knowledge for knowledge's sake -- we want or need better information for continuous self-improvement... to improve our investing and better investments, not just money but of our time ... to improve how we spend our time making progress with better business opportunities or better employment ... to improve our stewardship of our time, everything in our lives, our attention, energy, ambitions ... to improve how we align our time, resources, energies with our Creator's purpose or will for our lives.

The whole PKM thing is geared toward managing knowledge to have better, more relevant information at the time we need it ... which involves personal transformation and renewal ... transcending just accepting what information one gets just from different extraneous recommendation engines [which are part of our tracked lives], but instead being more proactive and systematic in tracking the origin, history, and context of one's information sources and one's notes on one's sources.

Better information is about transforming a chaotic or adhoc PKM, moving from a simple collection of information and gathering of intelligence into a more systematic, reliable, verifiable [or auditable] base knowledge ... not just know what one thinks one knows, but knowing precisely where the ideas came from and how likely to be true, realistic and actionable those ideas are.

Thus far, the actions that we have take toward the bigger objective might be summarized by the following:

1. Establishment of PKM System: The daily journals document the thinking behind the setup of a comprehensive Personal Knowledge Management (PKM) system using mdBook for publishing, Foam for notetaking with P.A.R.A. architecture, and GitHub Projects for managing a 100-day project across five phases, incorporating Rust development and considering future Python/Mojo integrations.

2. AI Coding Assistants and Tools: Extensive exploration of AI coding agents like Cline, Devin, and Codex, including their integration with OpenRouter, browser extensions, and productivity tools such as Zen and Dia browsers, emphasizing fundamental dev tasks and competitive analysis in the evolving toolscape.

3. Automation and Protocols: Focus on building automation infrastructure with MCP (Model Context Protocol) and A2A (Agent-to-Agent) protocols for secure, interoperable agentic workflows, including GitHub Actions for CI/CD, and understanding mechanics behind task automation and data flows.

4. Monetization and Economics: Deep dive into data as currency, micropayments, and economic models for AI services, including kernel-level tolling in CloudKernelOS, verifiable computation (zkML/opML), and secure payment protocols like x402, with emphasis on avoiding abuse of information technologies.

5. Productivity and Human-AI Collaboration: Emphasis on effective use of browsers and tools for productivity, exploring human-in-the-loop AI collaboration, browser-based development environments, and the need for integrated knowledge engineering environments to foster relationships and knowledge sharing.

Daily Journal Notes

• 100 Pathways to Cognitive Health
• Attention Economy of Artificial Intelligence
• Comparing the fractal efficiency of Bitcoin against risky assets
• Curated "Hall of Fame" for (1980–2010) tech writing that defined internet culture
• Gamified interactions from ludic economics to challenge assumptions
• Affordable and Open-Source Tech for Small-Scale Neuroarchitecture Research
• Biophilic Design Benefits: A Neuroarchitectural Perspective
• The Fractal Geometry of Hype, Drought, and Floods
• Simulation and Estimation of Fractional Brownian Motion
• R&D Funding Sources for Scientists, Engineers, and Tinkerers Across the Innovation Ecosystem
• The Neurograin Ecosystem
• The MelonCave Podcast Plan
• 100 Topics in Neuroarchitecture and Improving Cognitive Health
• Developing Podcasting Proficiency Using A Toastmasters-Inspired Approach
• 100 ways to SIMPLIFY, yet improve my life
• 100 SMARTER gamechangers for podcasting from the last few years
• Podcastering update, assistance with telling stories
• 100 personal sabotage habits from ESPN's spectator-focus
• 100 personal development habits from wrestling
• MelonCave Podcast Strategy Synthesis III: Neuroarchitecture & Letting AI Experts Do AI
• MelonCave Podcast Strategy Synthesis II: Neuroarchitecture & Letting AI Experts Do AI
• MelonCave Podcast Strategy Synthesis: Neuroarchitecture & Letting AI Experts Do AI
• GEO/AIO tool backgrounders and infrastructure of podcast business engineering
• Transcript structuring is now the most important part of podcast engineering
• Annotification and the importance of SIMPLE, human-readable, AI-optimized, curated, annotated lists
• 100 candidate list projects
• THINK MORE, build less. More research, better input data, stop OVERshipping!
• Surveying the landscape of truly open AI research
• What's in your melon? Understanding something about cognitive inference processes
• Local dual 7900 XTXs run 70B tasks for less than 1¢/hour vs. cloud-ideal at $3+/hr
• Refactoring Refactoring
• Refactoring Projects
• BrowserOS it is ... along with Upstage.AI's Solar Pro 2
• Strawberry Browser OR BrowserOS
• 100 MINIMALLY VIABLE CATEGORIES sitting in the Projects STAGING bin
• Lifestyle self-programming through daily tasks improving built/landscaped environment
• VERY long long-term project planning for personal lifelong projects
• Thinking about scaffolding structure using the thoughts behind a simple flood wall
• The role of experience and hisy in understanding PKM
• Recovery programs for individuals overcoming substance abuse and all kinds of bad habits
• Ludic economic research and playfulness
• For thinking about thinking ... how do we go beyond just brainrot scrolling
• Project List Categories ... Models, Datasets, Objects, Properties, Links, Actions
• Information as Entropic Change: Thermodynamic Sampling For Comparison, Inference
• Computerized data visualization tools illustrate how AI works or doesn't
• The Steward's Second Brain: Purpose-Driven Personal Knowledge Management (PKM)
• In the realm of PKM, self-defense has to be seen as an OBLIGATION
• Key differentiators of automated Browser-as-a-Service (BaaS) platforms
• Yes, it's a mess -- but right now, it's just preliminary scaffolding to re-build future scaffolding
• Thinkering: The HARD, knuckle-skinning mechanical stepping-through of a thought process
• Project STAGING per BASB P.A.R.A. PKM dev methodology
• Refocus/refactoring in PKM dev methodology
• Simplification and continuous improvment in PKM dev methodology
• Revisit basic PKM for consistency in daily ToDo lists for Portfolio Lifestyle
• PKE is enabling technology for The Sovereign Individual
• Exercise is not complicated; find ways to exercise more, whereas health insurance is ...
• The Digital Saloon: open source dev, preprints by gunslingers and other dangerous ideas
• Adapting screening methods to PKE screening of scientific research discovery trends
• Blueprint for a Community-Driven, Open-Source Agricultural Enterprise
• The POINT of PKM/PKE is better knowledge ... to attain more perfect anonymity
• Deeper into DeepWiki for peer-reviewed interrogation of bottlenecks and constraints
• NVIDIA's memory bandwidth superiority and its GROWING "AI software ecosystem lead"
• Disposable hackery is here to stay; so is dependable, peer-reviewed code
• GauntletAI is redefining education; emergent learning communities are another example
• Deeper push into incentivized DeSci and collaborative intelligence gathering
• Multi-Agent AI Systems (MAS): from optimized prompting to decentralized science (DeSci)
• Toward data-driven iterative context engineering, building on manual prompting techniques
• Implementation of prioritization techniques
• First experts doubt their own expertise, before understanding what truly might just work
• Competitively building out ventures for intelligence gathering
• Side-hustles, gigs, startups, auctioneering, being market savvy
• EVEN more on the P.A.R.A. structured PKM/PKE projects
• MORE on developing P.A.R.A. structured PKE workflows
• A Project, to dev separate repos each with its own P.A.R.A. structure, for EVERY Area
• Wafer-scale integration (WSI) / wafer-scale engineering (WSE) performance advantages for AI
• The future and HISTORY of GPUs, AI and scientific compute
• BEYOND compute, we'll need higher quality data, better algorithms, better dev communities
• Sguaba: Type-safe spatial math in Rust
• Models, cliches, root causes, likely suspects
• Best platform for building Rust-based AI Agents, APIs, tools
• mdBook functionality for exploration of model and algorithmic frontiers
• Primary mdBook functionality built on AlphaXiv direction
• Building an AI-Assisted Static "Public Square" for Asynch Discussions
• Drilling deeper with middleware, going beyond shallow agents
• AI-assisted deep research intelligence gathering
• The ol' bait-and-switch ... why the singularity ain't gonna happen
• Be Better At Asking Questions, Understanding, Organizing Information
• Cline Browser Extension Challenges In The Evolving Toolscape for Agents
• Cline, Devin, Codex, Other Agentic Tools ... like the Zen or Dia web browsers
• CloudKernelOS Foundation As a Micropayments Commission Agent
• Practicing Fundamental Dev Tasks ... using Cline, et al
• Monetization is key to securing MCP
• Introduction to Cline and OpenRouter
• Understanding GitHub Actions Workflows and Task Automation
• Mechanics Behind Automation For MCP and A2A
• Use or Abuse Of Information Technologies
• Thinking Through ALL of the Modules In Five Phases of GitHub Projects
• Initating The Top Level GitHub Projects Framework
• P.A.R.A. Foundations and Foam Notetaking IDE Extension
• Rust For PKM Dev; Setting Up The mdBook Repository

Personal Knowledge Management (PKM) ... which some might dismiss as just more efficient notetaking and simply better organization of notes ... because even a portion of that topic is worth the effort to master. Better note organization and even small gains in proficiency in the development of skills for things like summary automation pays one back quicky over very little time.

A big portion of the payback from investing time in development of PKM is in the improvement of how one is aware of how one thinks oneself. It's not only important to know what one doesn't know, it's important to know something about one's limits in beginning to fathom new waves of information, eg it is vitally important to shut off certain streams of noise entirely -- one needs to understand why certain kinds of noise is so deleterious!

100-Day Foundational Devlopment BEFORE PKM

The first 100-day AncientGuy Fitness push of our preparation for this larger program was FOUNDATIONAL and involved better understanding how we might improve in ten different aspect of fitness as foundational building blocks, necessary for the foundation to continually sustain our capabilities to durably work, be ready to serve, capable of exploring new levels of knowledge and understanding, including:

• Christian Spiritual Health
• Strength Training
• Cardiovascular Training
• Nutrition And Gardening
• Developing Intelligence
• Social Connections
• Rest, Recovery, Readiness
• Stress Optimization
• Hydration, Meridians
• Mobility, Coordination.

Although these ten areas are FOUNDATIONAL, they must be continually addressed and improved.

If ANYTHING, 100 days of delving deeply into these foundational topics has reaffirmed our conviction that much of what we are told is at least not exactly appropriate, worthy of extreme skepticism and more than likely just flat out wrong in the worst possible way that something can be wrong, ie many aspects are PARTIALLY right or make sense in certain contexts but not all contexts. Much of the information on diet, health, fitness that has become part of the conventional wisdom is like the 1992 USDA Food Pyramid -- comfortable, addictively deleterious to health, longevitity and effectiveness and enjoyment, especially after 65.

COMFORT KILLS! Mostly, it's the complacency and entitlement to comfort that so extensively weakens the ability to provide for one's sustenance or security.

If anyone follows the conventional wisdom, the best that they can expect is to have a lifespan that matches the Social Security actuarial tables AND in the final years of their lives, they will generally be unhealthy and unfit, addicted to prescription medicines and in constant need of medical care and attention.

After having the foundation material in place, it is time for the second 100-day push. Thus, the purpose driving this site is a 100-day curriculum or Personal Knowledge Management (PKM) system. The PKM system that we will develop is not exactly going to be an end in and of itself ... although it sort of could be -- the larger purpose of this 100-day curriculum is to build a base, for the third 100-day push to build a Personal Knowledge Engineering (PKE) system. These first 300 days will shape the next 100-day day pushes which are likely about deeper tech-assisted contemplation and deeper investigations of what recovery, rehabilitation and continual rejuvenation are about.

Background Information Shaping This 100-Day Development Plan

Serious Personal Knowledge Management is not the final destination, but is a gigantic first step toward serious context engineering necessary for full-blown AI-assisted Personal Knowledge Engineering (PKE). PKM and PKE are fundamentally about ACCELERATING the learning of/by AI-assisted knowledge management and engineering systems -- because we are going live in an economy and culture that is characterized by a superabundance of compute. We might be and should be astounded by the capabilities of our supercomputers now, no other form of technology has come close to keeping up with compute ... and none other has increased as long, as consistently for as long ... now we can be quite sure that the long-term trend, since 1900,* WILL CONTINUE!!! In every five year period, there has been and will continue to be roughly 10X more compute available for every dollar spent.

There's no question any more that this will change things dramatically. The real question is how can WE best exploit FOR OURSELVES the full advantage of this compute to accelerate how human systems learn?

It's an exciting time to be alive, with almost too much in the way of knowledge management and engineering development happening too rapidly.

Somehow, we have gravitated toward sources like the Latent Space Pod with Lance Martin of LangChain discussing his training exercises for LangChain's Open Deep Research framework, various AI Engineer videos and especially Hyung Won Chung's work on how to algorithmically think about incentivization or design-for-more-compute, or avoid designing for being constrained by the scale of our current thinking. We need to change the architecture of our LLM implmentations. Deep Agent applications like "Langchain Open Deep Research", “Manus”, and “Claude Code” have gotten around this limitation by implementing a combination of four things: a planning tool, sub agents, access to a file system, and a detailed prompt.

The 100-Day Architect: A Blueprint for an AI-Augmented Personal Knowledge Management System

You can, and probably should, use your own preferences and needs for a PKM to develop a better system for you for accomplishing this objective ... the important thing however, is to just get started with some sort of viable 100-day plan and then just steadily work at it. You can tear the plan up and start over after 30 days, but it's important to just get a plan to together that breaks down the work into manageable daily chunks and then get after it.

Introduction: The PKM as a Development Project

This report outlines a 100-day, 100-module plan for the systematic overhaul and AI-augmentation of a Personal Knowledge Management (PKM) system. The core philosophy of this endeavor is to treat the PKM not as a static repository of notes, but as a dynamic, evolving software project. This approach transforms the act of knowledge management from passive collection into an active process of system architecture, development, and continuous improvement. The 100-day journey is structured as a comprehensive development lifecycle, progressing from foundational infrastructure setup to the implementation of advanced, custom-built, AI-driven features.

The architecture of this system is organized into five distinct phases, each building upon the capabilities established in the previous one. This creates a layered "stack" of functionality, starting with a solid, version-controlled foundation and culminating in a highly intelligent, automated environment for learning and exploration.

A central architectural decision underpins this entire plan: the positioning of the GitHub ecosystem as the core operating system for the PKM. The user's goal to gain experience with GitHub Actions, Issues, Projects, and Discussions is not treated as a separate learning objective but as the strategic foundation for the entire system.1 This unified platform provides the necessary components to manage a complex, multi-tool environment. GitHub Issues will serve as the primary interface for managing the lifecycle of each knowledge topic, from initial idea to completed exploration.3 GitHub Projects will provide the high-level roadmaps and Kanban boards for tracking progress across all learning endeavors.5 Most critically, GitHub Actions will function as the system's central automation engine—its "kernel"—orchestrating every other component, from note processing and AI analysis to the final publication of the knowledge base.1 This integrated approach ensures that all disparate tools work in concert, managed by a single, powerful, and version-controlled platform.

Technology Stack and Phased Integration

The following table provides a strategic overview of the technologies to be integrated throughout this 100-day project. It outlines each component's primary role within the PKM ecosystem and the specific phases during which it will be introduced and mastered. This serves as a high-level roadmap, clarifying not only what will be learned, but when and why it is being introduced into the system architecture.

Phase I: The Developer's Knowledge Foundation (Modules 1-20)

Focus: Establishing a rock-solid, automated foundation for the PKM. This phase is about building the "scaffolding" and the core "DevOps" pipeline for your knowledge.

Modules 1-5: Project Scaffolding with GitHub

The initial modules focus on establishing the project's central repository, which will serve as the single source of truth for all knowledge, code, and configuration. This is the foundational step in treating the PKM as a formal development project.

1. Repository Creation and Initialization: A new private repository will be created on GitHub. This repository will house the entire PKM system, including Markdown notes, automation scripts, configuration files, and the mdBook source. Initializing the repository with a README.md file, a .gitignore file (configured for Python, Node.js, and Rust build artifacts), and a clear directory structure (/notes, /scripts, /book_src) is the first task.
2. GitHub Projects for Meta-Tracking: Before managing knowledge topics, the system must manage itself. A GitHub Project will be created to track the progress of this 100-day plan.5 This project will be configured with a Kanban board layout, with columns such as "To Do," "In Progress," and "Done".2 This provides immediate, practical experience with the project management tools that will later be applied to learning topics.
3. Structuring the 100-Day Plan as GitHub Issues: Each of the 100 modules in this plan will be created as a distinct GitHub Issue.3 This modularizes the work and allows for detailed tracking. Using GitHub's issue creation features, each module can be documented, discussed, and managed individually.2
4. Custom Fields and Project Views: The GitHub Project will be enhanced with custom fields to add rich metadata to each module's Issue. Fields such as "Phase" (e.g., "I: Foundation"), "Status" (e.g., "Not Started"), and "Technology" (e.g., "GitHub Actions") will be created.3 This allows for the creation of powerful, filtered views, such as a roadmap layout to visualize the timeline or a table view to group modules by technology.2
5. Establishing Branching Strategy and Workflow: A simple Git branching strategy, such as GitFlow or a main-branch workflow, will be established. All work will be done on feature branches and merged into the main branch via pull requests. This enforces good version control hygiene from the outset and prepares the project for automated checks and workflows that trigger on pull requests.3

Modules 6-10: Mastering the VSCode + Foam Environment

With the repository structured, the focus shifts to configuring the local development and note-taking environment. VSCode, augmented with the Foam extension, provides a powerful, free, and open-source platform for creating and navigating a graph-based knowledge base.8

6. VSCode and Foam Workspace Setup: The process begins by cloning the newly created GitHub repository to a local machine. Following the official Foam documentation, the foam-template project will be used to scaffold the necessary workspace configuration within the repository.8 This involves setting up the
   .vscode/settings.json and .vscode/extensions.json files, which define the workspace's behavior and recommend essential extensions.8
7. Core Foam Features - Linking and Graphing: This module is a deep dive into Foam's core functionality. The focus will be on creating atomic notes—single files dedicated to a single topic—and connecting them using [[wikilinks]].9 Practical exercises will involve creating a few sample notes and linking them to observe how the knowledge graph is built. The
   Foam: Show Graph command will be used to visualize these connections, providing a tangible representation of the relationships between ideas.9
8. Navigation and Discovery with Backlinks: Understanding connections is a two-way street. This module will explore Foam's backlinking capabilities. The Backlinks Panel will be used to see which other notes reference the currently active note, providing crucial context and aiding in the discovery of emergent themes and relationships within the knowledge base.9
9. Installation and Review of Recommended Extensions: The foam-template recommends a set of VSCode extensions to enhance the Markdown editing experience.8 This module involves installing and reviewing this list, which typically includes tools like
   Markdown All In One, Prettier for formatting, and extensions for Mermaid diagrams and emoji support.12 Understanding the role of each extension is key to customizing the environment for maximum productivity.
10. Customizing VSCode Settings: The default Foam settings provide a great starting point, but personalization is key. This module involves editing the .vscode/settings.json file to tweak the user experience. This could include changing editor fonts, setting rulers for line length, or customizing how wikilinks are rendered in the editor, ensuring the environment is perfectly tailored to the user's workflow.8

Modules 11-15: mdBook Configuration and Initial Build

The next step is to configure mdBook, the Rust-based tool that will transform the collection of Markdown notes into a clean, searchable, and publishable static website.14

11. Installing mdBook and Initializing the Book: mdBook will be installed using Rust's package manager, Cargo. Once installed, the mdbook init command will be run within the /book_src directory of the repository. This command creates the initial file structure for the book, including the src directory for content and the all-important SUMMARY.md file, which defines the book's navigation structure.14
12. Configuring book.toml: The book.toml file is the heart of an mdBook project's configuration. This module involves a thorough exploration of its key options.15 The book's title and author will be set, and the HTML renderer options will be configured. This includes enabling or disabling section labels, adding a link to the source GitHub repository, and selecting a default theme.15
13. Structuring the SUMMARY.md: The SUMMARY.md file dictates the table of contents and navigation hierarchy of the final website. This module will focus on understanding its syntax. A basic structure will be created, linking to the sample notes created in the Foam modules. This establishes the initial organization of the public-facing knowledge base.
14. Enabling and Configuring Search: One of mdBook's most powerful features is its built-in, client-side search functionality. In the book.toml file, the search feature will be explicitly enabled and configured.15 Options like
    limit-results, use-boolean-and, and boost-title will be explored to understand how to fine-tune the search experience for users of the knowledge base.15
15. Performing the First Manual Build: With the initial configuration in place, the mdbook build command will be run from the command line. This compiles the Markdown files from the src directory into a static HTML site in a new /book directory. The resulting site will be opened locally in a browser to verify that the configuration is correct, the links work as expected, and the overall structure is sound. This manual build serves as the baseline for the automated pipeline to come.16

Modules 16-20: The First Automated CI/CD Pipeline

This is the capstone of Phase I, where the manual processes of building and deploying are automated using GitHub Actions. This creates a Continuous Integration/Continuous Deployment (CI/CD) pipeline that ensures the published knowledge base is always in sync with the latest notes.17

16. Creating the First Workflow File: A new workflow file will be created at .github/workflows/deploy-book.yml. This YAML file will define the automation steps. The workflow will be configured to trigger on a push event to the main branch, meaning it will run automatically every time new changes are committed.16
17. Configuring the GitHub Actions Job: The workflow will contain a single job, build-and-deploy. This job will be configured to run on an ubuntu-latest runner. The first steps within the job will be to use the actions/checkout action to check out the repository's code onto the runner.17
18. Installing mdBook on the Runner: To build the book, mdBook must be available on the CI runner. The most efficient method is to download a pre-compiled binary from the GitHub Releases page, which is fast and avoids the need to install the entire Rust toolchain.16 A workflow step will use
    curl to download and extract the mdBook executable.16
19. Building and Deploying to GitHub Pages: The core of the workflow involves two steps. First, a step will run the mdbook build command, generating the static site in the /book directory. Second, a community action like peaceiris/actions-gh-pages will be used to deploy the contents of the /book directory to a special gh-pages branch in the repository.18 Repository settings will be configured to enable GitHub Pages and set the
    gh-pages branch as the deployment source.19
20. Identifying the "Impedance Mismatch" and a Manual Workaround: Upon the first successful deployment, a critical challenge will become apparent. The [[wikilinks]] used for fluid navigation within Foam and VSCode are not standard Markdown links and will be broken in the final mdBook output.8 This "impedance mismatch" between the authoring environment and the publishing tool is a central technical hurdle of the chosen stack. Foam provides a command,
    Foam: Create markdown references for [[wikilinks]], which converts these links into a format that mdBook can understand.9 This module concludes by documenting this issue and establishing the manual execution of this command as a temporary workaround. This deliberate identification of a problem creates a clear and compelling motivation for developing a more sophisticated, automated scripting solution in later phases, transforming a potential frustration into a core learning objective of the 100-day plan.

Phase II: Architecting the Knowledge Graph (Modules 21-40)

Focus: Developing a systematic approach to knowledge capture, organization, and presentation. This phase moves from "getting the tools to work" to "using the tools effectively."

Modules 21-25: Knowledge Ingestion Framework

With the foundational infrastructure in place, the focus now shifts to establishing a structured process for exploring the 150 bucket-list topics. This involves leveraging GitHub's project management tools to create a systematic knowledge ingestion pipeline.

21. Creating the "Topic Exploration" Project Board: A new GitHub Project will be created specifically for managing the 150 learning topics. This project will be configured as a Kanban board, providing a visual workflow for tracking topics as they move from idea to exploration.2
22. Designing a Standardized Issue Template for Topics: To ensure consistency, a GitHub Issue template will be designed for new topics. This template, stored as a Markdown file in the .github/ISSUE_TEMPLATE directory, will pre-populate new issues with a standardized structure.3 Sections will include "Topic Summary," "Key Questions to Answer," "Initial Resources," and "Potential Connections," guiding the initial phase of research for any new subject.
23. Populating the Backlog with Initial Topics: As a practical exercise, the first 10-15 topics from the user-provided list of 150 will be created as new Issues using the template designed in the previous module. These issues will form the initial "backlog" in the "Topic Exploration" project board.3
24. Using Custom Fields for Topic Metadata: The project board will be enhanced with custom fields tailored for knowledge exploration. Fields like "Topic Category" (e.g., "Technology," "History," "Science"), "Priority" (e.g., "High," "Medium," "Low"), and "Status" (e.g., "Backlog," "Researching," "Synthesizing," "Published") will be added to provide richer metadata for each topic.5
25. Linking Issues to a Milestone: To group related learning goals, a GitHub Milestone will be created, for example, "Q3 Learning Goals." A subset of the topic issues will be assigned to this milestone. This introduces another layer of organization, allowing for tracking progress against larger, time-bound objectives.2

Modules 26-30: Advanced Foam Techniques

This section moves beyond the basics of Foam to leverage its more powerful features for structuring and maintaining a high-quality knowledge graph.9

26. Creating and Using Note Templates: To standardize the format of different types of notes, Foam's template feature will be implemented. Templates for various knowledge artifacts—such as book summaries, biographies, project overviews, or technology explainers—will be created. Using the Foam: Create New Note from Template command will then become the standard workflow, ensuring consistency and reducing repetitive work.9
27. Mastering the Tag Explorer and Hierarchical Tags: Tags are a crucial tool for non-hierarchical organization. This module focuses on using the Tag Explorer panel to navigate the knowledge base. A tagging convention will be established, and the power of hierarchical tags (e.g., #tech/python/automation) will be explored to create more granular and organized connections between notes.9
28. Managing Orphans and Placeholders: A healthy knowledge graph is a connected one. This module addresses graph maintenance by focusing on the "Orphans" and "Placeholders" panels in Foam.9 Orphans (notes with no links) and Placeholders (links to non-existent notes) will be regularly reviewed. A workflow will be established to either integrate orphaned notes into the graph or create new notes for placeholders, ensuring the knowledge base remains coherent and interconnected.10
29. Embedding Note Content: To create composite documents and avoid content duplication, Foam's note embedding feature (![[note-name]]) will be utilized. This allows the content of one note to be dynamically included within another. This is particularly useful for creating "Maps of Content" (MOCs) or summary pages that pull in information from multiple atomic notes.9
30. Leveraging Section Linking and Aliases: For more precise connections, linking to specific sections within a note (]) will be practiced.9 Additionally, link aliasing (
    [[note-name|custom display text]]) will be used to make links more readable and context-friendly within the body of a note, improving the overall narrative flow of the written content.9

Modules 31-35: Python for PKM - The First Scripts

This section marks the introduction of custom automation with Python. The initial scripts will focus on automating common maintenance and organization tasks within the knowledge base, demonstrating the power of scripting to manage the PKM at scale.21

31. Setting Up the Python Environment: A local Python development environment will be configured. This includes installing a recent version of Python and using a virtual environment manager like venv to isolate project dependencies. The first script will be a simple "hello world" to verify the setup.
32. Script 1: File Organizer based on Frontmatter: The first practical script will be a file organizer. This Python script will iterate through all Markdown files in the /notes directory. It will parse the YAML frontmatter of each file to read metadata (e.g., category: 'Technology'). Based on this metadata, the script will automatically move the file into a corresponding subdirectory (e.g., /notes/technology/). This automates a tedious organization task and introduces file system operations with Python's os module.22
33. Script 2: Batch Tagging Utility: Building on the previous script, a batch tagging utility will be created. This script will take a directory and a tag as command-line arguments. It will then scan all files in that directory and append the specified tag to their frontmatter tag list. This is useful for applying a new project tag or category to a group of existing notes simultaneously.21
34. Reading and Consolidating Notes: A script will be developed to demonstrate content processing. This script will read multiple text files (e.g., daily log files named YYYY-MM-DD.md) and consolidate their content into a single weekly or monthly summary file. This introduces file reading and writing operations and is a foundational step for more complex content analysis later on.21
35. Integrating Scripts with the Command Line: The scripts will be enhanced to be more user-friendly by using Python's argparse module to handle command-line arguments. This makes them more flexible and reusable, transforming them from simple scripts into proper command-line tools for PKM management.

Modules 36-40: Enhancing mdBook Presentation

The final part of this phase focuses on customizing the appearance and functionality of the public-facing mdBook site, ensuring it is not just a repository of information but a polished and professional presentation of knowledge.

36. Creating a Custom Theme: While mdBook comes with default themes, creating a custom look is essential for personalization. This module involves creating a theme directory and adding custom CSS files to override the default styles. This could involve changing colors, fonts, and layout to match a personal aesthetic.15
37. Adding Custom JavaScript for Interactivity: To add dynamic behavior, custom JavaScript files will be integrated. This could be used for simple enhancements like adding a "back to top" button, or more complex features like integrating an external analytics service or adding interactive UI elements.15
38. Integrating Preprocessors for Rich Content: mdBook's functionality can be extended with preprocessors. This module will explore adding support for features not natively included in Markdown. For example, the mdbook-mermaid preprocessor will be configured to allow for the rendering of Mermaid.js diagrams and flowcharts directly from code blocks, and MathJax support will be enabled for rendering complex mathematical equations.15
39. Configuring a Professional Deployment: To ensure the deployed site functions correctly, especially with custom domains or subdirectories, the site-url option in book.toml will be properly configured. This is crucial for ensuring that links, CSS, and JavaScript files load correctly on the live server.16
40. Customizing the 404 Error Page: A professional site needs a helpful error page. A custom 404.md file will be created in the src directory. mdBook will automatically convert this into a 404.html page that provides better navigation and user experience for visitors who encounter a broken link, which is a significant improvement over a generic server error.16

Phase III: AI Augmentation - The Intelligent Assistant (Modules 41-60)

Focus: Integrating a multi-tiered AI strategy to automate content processing and generate new insights. This is the core "AI-ification" phase.

Modules 41-45: AI Gateway Setup - OpenRouter & Google AI Studio

This section lays the groundwork for all future AI integration by setting up access to powerful, flexible AI models through API gateways. This approach provides access to a wide variety of models without being locked into a single provider.

41. Creating an OpenRouter Account: OpenRouter serves as a unified API gateway to hundreds of AI models from various providers like Anthropic, Google, and Meta.23 An account will be created, and the dashboard will be explored to understand its features, including model availability, pricing, and usage tracking.24
42. Generating and Securing API Keys: An API key will be generated from the OpenRouter dashboard. To maintain security best practices, this key will not be hard-coded into any scripts. Instead, it will be stored as an encrypted "secret" in the GitHub repository settings.1 This allows GitHub Actions workflows to securely access the key at runtime without exposing it in the codebase.
43. Introduction to Google AI Studio: Google AI Studio is a web-based tool for rapidly prototyping prompts and experimenting with Google's Gemini family of models.26 It provides an intuitive interface for testing different prompting strategies without writing any code, making it an ideal environment for initial exploration and "vibe coding".26
44. Prototyping PKM Prompts in AI Studio: Using Google AI Studio, several prompts tailored for PKM tasks will be developed and tested. This includes crafting system prompts for an AI assistant that can summarize long articles, extract key entities (people, places, concepts), generate a list of questions about a topic, or rephrase complex text into simpler terms. The iterative nature of the AI Studio playground allows for quick refinement of these prompts.28
45. Understanding API Quotas and Billing: A crucial part of using cloud-based AI is managing costs. This module involves reviewing the billing and quota systems for both OpenRouter and Google AI. A budget will be set, and the prepaid credit system of OpenRouter will be explored as a way to control spending.23 Understanding the per-token pricing for different models is essential for making cost-effective choices later on.24

Modules 46-50: Your First AI-Powered Python Script

With API access established, the next step is to bring AI capabilities into the local development environment through Python scripting.

46. Setting up the Python Environment for API Calls: The Python environment will be prepared by installing necessary libraries, such as requests for making HTTP calls or a provider-specific SDK like openai which is compatible with the OpenRouter API endpoint.23

47. Script 3: The AI Summarizer: The first AI-powered script will be a text summarizer. This Python script will:
    a. Read the content of a specified Markdown file from the /notes directory.
    b. Construct a prompt using the text content.
    c. Make a POST request to the OpenRouter API endpoint (/api/v1/chat/completions), passing the prompt and selecting a powerful general-purpose model like anthropic/claude-3.5-sonnet or meta-llama/llama-3.1-405b-instruct.24

    d. Parse the JSON response to extract the generated summary.
    e. Print the summary to the console.

48. Handling API Keys and Responses in Python: The summarizer script will be refactored to securely access the API key from an environment variable rather than hard-coding it. Error handling will also be added to gracefully manage potential API issues, such as network errors, authentication failures, or rate limiting.30

49. Writing Summaries Back to Files: The script will be enhanced to be more useful. Instead of just printing the summary, it will be modified to write the summary back into the original Markdown file. A good practice is to add it to the YAML frontmatter under a summary: key or in a dedicated ## AI Summary section at the end of the file.

50. Exploring OpenRouter Parameters: The OpenRouter API offers numerous parameters to control model behavior, such as temperature, max_tokens, and top_p.30 This module involves experimenting with these parameters in the Python script to observe their effect on the quality, length, and creativity of the generated summaries, allowing for fine-tuning of the AI's output.

Modules 51-55: Specialized Models with Hugging Face

While API gateways are excellent for general-purpose tasks, some tasks benefit from specialized, fine-tuned models. Hugging Face is the leading platform for accessing these models.32

51. Introduction to the Hugging Face Hub and Transformers Library: This module provides an overview of the Hugging Face ecosystem. The Hugging Face Hub will be explored to find models specifically fine-tuned for summarization. The transformers Python library, which provides a high-level API for using these models, will be installed.32

52. Implementing the Summarization Pipeline: The transformers library offers a pipeline abstraction that simplifies the process of using a model for a specific task.34 A new Python script will be created that initializes a
    summarization pipeline, specifying a well-regarded model like facebook/bart-large-cnn.32

53. Script 4: Hugging Face Summarizer: This script will use the initialized pipeline to summarize a piece of text. The code is often simpler than a direct API call:
    Python
    from transformers import pipeline

    # Load the summarization pipeline with a specific model
    summarizer = pipeline("summarization", model="facebook/bart-large-cnn")

    ARTICLE = """ Your long text content here... """
    summary = summarizer(ARTICLE, max_length=150, min_length=40, do_sample=False)
    print(summary)

    This script will be tested on the same notes used in the OpenRouter module to compare results.32

54. Comparing General vs. Specialized Models: This module involves a qualitative analysis comparing the summaries generated by the general-purpose model via OpenRouter and the specialized BART model from Hugging Face. The comparison will focus on aspects like factual accuracy, coherence, conciseness, and relevance to the source text. This provides a practical understanding of the trade-offs between using large, general models and smaller, task-specific ones.

55. Integrating Hugging Face into the Workflow: The Hugging Face summarizer script will be integrated into the existing PKM workflow. It will be adapted to read from and write to files, just like the OpenRouter script, making it a viable alternative for the summarization task within the broader system.

Modules 56-60: Developing a Tiered AI Strategy

This section synthesizes the experiences from the previous modules into a coherent, strategic framework for using AI. Instead of treating each AI service as an isolated tool, the system will be designed to use them as a portfolio of resources, deployed intelligently based on the task's requirements.

56. Defining the Tiers: Cost, Speed, Privacy, Capability: The AI resources available (OpenRouter, Hugging Face, and soon, local models via Ollama) will be categorized into tiers. For example:
    • Tier 1 (Local/Fast): Local Ollama models for low-cost, private, and fast tasks like simple text formatting or brainstorming.
    • Tier 2 (Specialized/Efficient): Hugging Face models for specific, well-defined tasks like summarization where a fine-tuned model excels.
    • Tier 3 (Powerful/Cloud): State-of-the-art models via OpenRouter for complex reasoning, high-quality content generation, or tasks requiring the largest context windows.
57. Building a Python "Router" Function: A Python function or class will be created to encapsulate this tiered logic. This AIManager will have a method like process_text(task_type, text, priority). Based on the task_type (e.g., 'summarize', 'generate_questions') and priority, this function will decide which AI service and model to call.
58. Implementing the Routing Logic: The AIManager will be implemented. For a 'summarize' task, it might default to the Hugging Face pipeline. For a 'brainstorm' task, it might use a local Ollama model. For a high-priority 'analyze_complex_document' task, it would route the request to a top-tier model through OpenRouter. This elevates the system from making simple API calls to making intelligent, resource-aware decisions.
59. Creating a Reusable AI Toolkit: The AIManager and its related functions will be organized into a reusable Python module within the /scripts directory. This toolkit will be imported by all future automation scripts, ensuring that the tiered AI strategy is applied consistently across the entire PKM system.
60. Formalizing the Model Selection Framework: The decision-making logic will be documented in a table. This framework serves as a quick reference for choosing the right tool for any given knowledge work task, moving from a reactive "what can this model do?" mindset to a proactive "what is the best model for this job?" approach.

Phase IV: Hyper-Automation and Advanced Workflows (Modules 61-80)

Focus: Creating proactive, fully automated pipelines that require minimal manual intervention. This phase builds the "intelligent nervous system" of the PKM.

Modules 61-70: Advanced GitHub Actions Workflows

This section focuses on creating a sophisticated, multi-stage GitHub Action that fully automates the process of content enrichment, connecting the file system, Python scripts, AI models, and the deployment pipeline.

61. Designing the "Content Enrichment" Workflow: A new, more advanced GitHub Actions workflow will be designed. The goal is to create a system that automatically processes a new note, enriches it with AI-generated content, and deploys the result without any manual steps.
62. Triggering Workflows with Path Filters and Tags: The workflow will be configured to trigger conditionally. It will run on pushes to the main branch but only when files in the /notes directory are modified. A convention will be established where adding a specific tag, like #summarize, to a note's frontmatter signals the workflow to process that specific file.
63. Workflow Step: Identifying Target Files: The first step in the Action's job will be to identify which files have been changed in the latest commit and need processing. A simple shell script or a dedicated GitHub Action can be used to get the list of modified files.
64. Workflow Step: Running the AI Python Script: The workflow will then set up the Python environment and run the AIManager script developed in Phase III. The script will be called with the path to the modified file as an argument.
65. Workflow Step: Committing Changes Back to the Repository: After the Python script runs and modifies the note file (e.g., by adding a summary), the GitHub Action must commit this change back to the repository. This requires configuring Git within the action, setting a user and email, and using git commit and git push. A special commit message like "chore(AI): Add summary to [filename]" will be used to denote automated changes.
66. Handling Recursive Workflow Triggers: A critical challenge in this setup is that the workflow pushes a commit, which would normally trigger the workflow again, creating an infinite loop. This will be prevented by adding a condition to the commit step or the workflow trigger to ignore commits made by the Actions bot itself (e.g., by checking the commit message).
67. Chaining Workflows: Instead of putting everything in one massive file, the content enrichment workflow will be configured to trigger the existing mdBook deployment workflow upon its successful completion. This can be done using the workflow_run event or by using a reusable "callable" workflow, which is a more modern approach.
68. Adding an Issue Commenting Step: To provide feedback, a final step will be added to the workflow. Using an action like peter-evans/create-or-update-comment, the workflow will find the corresponding GitHub Issue for the topic and post a comment indicating that the note has been automatically updated and a new version has been deployed, including a link to the published page.
69. Full End-to-End Test: A full test of the pipeline will be conducted. A new note will be created locally, tagged for summarization, and pushed to GitHub. The process will be monitored in the GitHub Actions tab, from the initial trigger to the AI processing, the commit back, the mdBook deployment, and the final comment on the issue.
70. Refactoring for Reusability: The workflow will be refactored to make it more modular. The Python script execution and the mdBook deployment steps will be broken into separate, reusable composite actions or callable workflows, making the main workflow file cleaner and easier to maintain.7

Modules 71-75: Local LLMs with Ollama

This section introduces local large language models using Ollama, adding a powerful, private, and cost-effective tier to the AI strategy.35

71. Installing and Configuring Ollama: Ollama will be installed on the local machine. The command-line interface will be used to pull down a versatile, medium-sized model like Llama 3 (ollama pull llama3) or a smaller, efficient model like Phi-2 (ollama pull phi-2).35
72. Interacting with Local Models via CLI and API: The first interactions will be through the command line using ollama run llama3. This provides a feel for the model's performance and personality. Subsequently, the Ollama REST API, which runs locally on port 11434, will be explored. A tool like curl or Postman will be used to send requests to the API, demonstrating how to interact with the local model programmatically.36
73. Creating a Custom Model with a Modelfile: To tailor a model for specific PKM tasks, a Modelfile will be created.37 This file defines a custom model based on a parent model (e.g.,
    FROM llama3). It will include a SYSTEM prompt to give the model a specific persona, such as a "Socratic Inquisitor" whose role is to respond to any text by generating three probing questions to deepen understanding. Parameters like temperature can also be set to control creativity.38
74. Building and Running the Custom Model: The ollama create command will be used to build the custom model from the Modelfile, giving it a unique name (e.g., socratic-inquisitor). This new model will then be available to run via ollama run socratic-inquisitor and through the API.37
75. Integrating Ollama into the Python AI Toolkit: The AIManager Python module will be updated to include Ollama as a new AI provider. A new function will be added that makes API calls to the local Ollama server. The routing logic will be updated to use the local model for specific tasks, such as brainstorming or generating questions, officially adding the "Tier 1 (Local)" capability to the system.36

Modules 76-80: Containerization with Docker

To ensure the PKM system's environment is consistent, portable, and reproducible, this section introduces containerization using Docker. This brings professional DevOps practices to the personal project.

76. Introduction to Docker Concepts: The core concepts of Docker will be reviewed: images, containers, Dockerfiles, and volumes. The benefits of containerization for creating isolated and predictable environments will be discussed.
77. Running Ollama in a Docker Container: As a first practical step, instead of running Ollama directly on the host machine, it will be run inside a Docker container using the official ollama/ollama image.35 This involves running the container, mapping the necessary ports, and using a volume to persist the downloaded models, ensuring they are not lost when the container stops.
78. Writing a Dockerfile for the Python Scripts: A Dockerfile will be written for the PKM's Python automation tools. This file will define a custom image that:
    a. Starts from a base Python image.
    b. Copies the requirements.txt file and installs the dependencies.
    c. Copies the /scripts directory into the image.
    d. Sets up any necessary environment variables.
79. Building and Running the Custom Python Container: The docker build command will be used to create an image from the Dockerfile. Then, docker run will be used to start a container from this image and execute one of the automation scripts, demonstrating that the entire toolchain can run in a self-contained environment.
80. Exploring Other Self-Hosted PKM Tools: Docker makes it easy to experiment with other open-source tools. This module involves exploring the Docker images for other self-hosted PKM platforms like Memos or Siyuan.39 By running these tools locally in containers, new ideas and features can be discovered and potentially incorporated into the custom PKM system, all without polluting the host machine with new dependencies.

Phase V: Frontier Exploration and Custom Tooling (Modules 81-100)

Focus: Pushing the boundaries of PKM by building high-performance, custom components and exploring next-generation AI platforms.

Modules 81-90: High-Performance PKM with Rust

This section directly addresses the "impedance mismatch" problem identified in Phase I by building a custom, high-performance command-line utility in Rust. This provides a tangible, valuable project that motivates learning a new, more complex language and demonstrates a clear progression in technical capability.

81. Setting up the Rust Development Environment: The Rust toolchain, including rustup and cargo, will be installed. A new binary crate will be created using cargo new foam-link-converter. The basics of the Rust language will be explored, focusing on concepts relevant to this project: file system operations, string manipulation, and error handling.
82. Designing the Link Conversion Utility: The command-line tool's logic will be designed. It will need to:
    a. Accept a directory path as a command-line argument.
    b. Recursively walk through the directory to find all .md files.
    c. For each file, read its content into a string.
    d. Use regular expressions to find all instances of Foam's [[wikilink]] syntax.
    e. For each found wikilink, determine the correct relative path to the target file.
    f. Replace the [[wikilink]] with a standard Markdown link ([wikilink](./path/to/file.md)).
    g. Write the modified content back to the file.
83. Implementing File System Traversal in Rust: The first part of the implementation will focus on safely and efficiently traversing the notes directory. Rust libraries like walkdir will be used for this purpose.
84. Parsing and Replacing Links with Regex: Rust's powerful regex crate will be used to implement the core link-finding and replacement logic. This module will focus on crafting a robust regular expression that can handle simple links, aliases, and section links.
85. Handling Edge Cases and Path Logic: A simple replacement is not enough. The tool must be intelligent. For a link like [[my-note]], the tool needs to find the file my-note.md within the directory structure and calculate the correct relative path from the source file to the target file. This involves path manipulation using Rust's standard library.
86. Compiling for Performance: The Rust code will be compiled in release mode (cargo build --release). The performance of this compiled binary will be compared to a hypothetical Python script performing the same task, highlighting the significant speed advantage of a compiled language like Rust for I/O- and CPU-intensive tasks. This provides a concrete demonstration of moving up the "performance ladder" from interpreted to compiled languages.
87. Integrating the Rust Tool into the GitHub Action: The compiled binary will be checked into the repository or built as part of the CI process. The main GitHub Actions workflow will be modified to run this custom utility as a build step before mdbook build is called. This completely automates the solution to the wikilink problem.
88. Exploring Other Rust-Based PKM Tools: To gain further inspiration from the Rust ecosystem, notable open-source PKM tools written in Rust, such as AppFlowy and Joplin, will be reviewed.41 Examining their architecture and feature sets can provide ideas for future enhancements to the custom system.
89. Publishing the Crate (Optional): As an extension, the foam-link-converter utility can be published to crates.io, Rust's public package registry. This provides experience with the full lifecycle of creating and sharing an open-source tool.
90. Finalizing the Automated Linking Workflow: The end-to-end workflow is now complete. A user can write notes in VSCode using fluid [[wikilinks]], push the changes to GitHub, and the automated pipeline will use a custom-built, high-performance Rust utility to seamlessly convert the links for publication with mdBook. This represents a significant engineering achievement within the PKM project.

Modules 91-95: Exploring the Modular Platform (Mojo & MAX)

This section ventures into the cutting edge of AI infrastructure, exploring the Modular Platform to understand how to achieve state-of-the-art performance for AI tasks.42

91. Introduction to Modular, Mojo, and MAX: The Modular ecosystem will be introduced. Mojo is a programming language that combines the usability of Python with the performance of C and Rust, designed specifically for AI developers.43 MAX is Modular's suite of AI libraries and tools for high-performance inference.45
92. Installing the Modular SDK: The Modular SDK will be installed, providing access to the Mojo compiler and MAX tools. The native VSCode extension for Mojo will also be installed to get syntax highlighting and language support.42
93. Writing "Hello World" in Mojo: The first Mojo program will be written and compiled. This will introduce Mojo's syntax, which is a superset of Python, and concepts like strong typing with var and fn for function definitions.44
94. Running a Pre-Optimized Model with MAX Serving: The power of the MAX platform will be demonstrated by running a pre-optimized model from the Modular model repository. Using the max serve command, an OpenAI-compatible API endpoint will be started locally, serving a model like Llama 3.45 The performance (tokens per second) of this endpoint will be observed and compared to other inference methods, showcasing the benefits of Modular's optimizations.43
95. Experimenting with a Mojo Script: A simple Mojo script will be written to interact with the MAX-served model. This provides a glimpse into how Mojo can be used to write the high-performance "glue code" for AI applications, bridging the gap between Python's ease of use and the need for speed in production AI systems.43

Modules 96-100: Capstone Project - The "Topic Delver" Agent

This final project synthesizes all the skills and components developed over the previous 95 days into a single, powerful, and fully automated "agent" that actively assists in the knowledge exploration process.

96. Designing the "Topic Delver" Agent Workflow: A master GitHub Action will be designed. This workflow will trigger when a GitHub Issue on the "Topic Exploration" project board is moved into the "Researching" column. This project management action becomes the starting signal for the automated agent.1
97. Step 1: Initial Information Gathering (Python + OpenRouter): The workflow will trigger a Python script. This script will take the title of the GitHub Issue as input. It will use the OpenRouter API to query a powerful model, instructing it to perform a simulated web search to find 3-5 key articles, videos, or papers related to the topic.23
98. Step 2: Generating Foundational Questions (Python + Ollama): The script will then take the gathered resources and the issue summary and pass them to the custom "socratic-inquisitor" model running locally via Ollama. The model's task is to generate a list of 5-10 foundational questions that should be answered to gain a deep understanding of the topic.35
99. Step 3: Creating the "Topic Hub" Note: The Python script will then create a new Markdown file in the /notes directory. The filename will be based on the issue title. This file will be pre-populated using a template that includes the list of resources gathered by OpenRouter and the foundational questions generated by Ollama.
100. Step 4: Finalizing and Notifying (Rust, mdBook, GitHub API): The workflow will then execute the custom Rust foam-link-converter utility to ensure all links are correct. It will commit the new note file to the repository, which in turn triggers the mdBook deployment workflow. As a final step, the workflow will use the GitHub API to post a comment back to the original Issue, stating: "The Topic Hub has been created. You can view the note here:," completing the automated loop from task management to knowledge creation. This capstone project exemplifies a truly AI-augmented PKM system, where the system itself becomes an active partner in the process of learning and exploration.

Works cited

1. Automating Projects using Actions - GitHub Docs, accessed September 1, 2025, https://docs.github.com/en/issues/planning-and-tracking-with-projects/automating-your-project/automating-projects-using-actions
2. Planning and tracking with Projects - GitHub Docs, accessed September 1, 2025, https://docs.github.com/en/issues/planning-and-tracking-with-projects
3. GitHub Issues · Project planning for developers, accessed September 1, 2025, https://github.com/features/issues
4. Using GitHub issues to manage my tasks because I got tired of all the markdown files. : r/ClaudeAI - Reddit, accessed September 1, 2025, https://www.reddit.com/r/ClaudeAI/comments/1mozlq0/using_github_issues_to_manage_my_tasks_because_i/
5. About Projects - GitHub Docs, accessed September 1, 2025, https://docs.github.com/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects
6. kamranahmedse/developer-roadmap: Interactive roadmaps, guides and other educational content to help developers grow in their careers. - GitHub, accessed September 1, 2025, https://github.com/kamranahmedse/developer-roadmap
7. I saved 10+ of repetitive manual steps using just 4 GitHub Actions workflows - Reddit, accessed September 1, 2025, https://www.reddit.com/r/devops/comments/1jbajbr/i_saved_10_of_repetitive_manual_steps_using_just/
8. A personal knowledge management and sharing system for VSCode - Foam, accessed September 1, 2025, https://foambubble.github.io/foam/
9. foambubble/foam: A personal knowledge management and sharing system for VSCode - GitHub, accessed September 1, 2025, https://github.com/foambubble/foam
10. Foam - Visual Studio Marketplace, accessed September 1, 2025, https://marketplace.visualstudio.com/items?itemName=foam.foam-vscode
11. Recommended Extensions | Foam, accessed September 1, 2025, https://foam-template-gatsby-kb.vercel.app/recommended-extensions
12. Recommended Extensions - Foam, accessed September 1, 2025, https://foambubble.github.io/foam/user/getting-started/recommended-extensions.html
13. Visual Studio Code Extensions - thecrumb, accessed September 1, 2025, https://www.thecrumb.com/posts/2022-12-21-my-vscode-extensions/
14. Introduction - mdBook Documentation, accessed September 1, 2025, https://rust-lang.github.io/mdBook/
15. Renderers - mdBook Documentation - GitHub Pages, accessed September 1, 2025, https://rust-lang.github.io/mdBook/format/configuration/renderers.html
16. Continuous Integration - mdBook Documentation - GitHub Pages, accessed September 1, 2025, https://rust-lang.github.io/mdBook/continuous-integration.html
17. Creating Your First CI/CD Pipeline Using GitHub Actions | by Brandon Kindred - Medium, accessed September 1, 2025, https://brandonkindred.medium.com/creating-your-first-ci-cd-pipeline-using-github-actions-81c668008582
18. peaceiris/actions-gh-pages: GitHub Actions for GitHub Pages Deploy static files and publish your site easily. Static-Site-Generators-friendly., accessed September 1, 2025, https://github.com/peaceiris/actions-gh-pages
19. Step by step to publish mdBook in gh-pages · Issue #1803 - GitHub, accessed September 1, 2025, https://github.com/rust-lang/mdBook/issues/1803
20. How to build mdBook with Github Actions | by katopz | Medium - Level Up Coding, accessed September 1, 2025, https://levelup.gitconnected.com/how-to-build-mdbook-with-github-actions-eb9899e55d7e
21. Beginner's Guide To Python Automation Scripts (With Code ..., accessed September 1, 2025, https://zerotomastery.io/blog/python-automation-scripts-beginners-guide/
22. 19 Super-Useful Python Scripts to Automate Your Daily Tasks - Index.dev, accessed September 1, 2025, https://www.index.dev/blog/python-automation-scripts
23. OpenRouter: A unified interface for LLMs | by Dagang Wei | Medium, accessed September 1, 2025, https://medium.com/@weidagang/openrouter-a-unified-interface-for-llms-eda4742a8aa4
24. Community Providers: OpenRouter - AI SDK, accessed September 1, 2025, https://ai-sdk.dev/providers/community-providers/openrouter
25. Models - OpenRouter, accessed September 1, 2025, https://openrouter.ai/models
26. Google AI Studio | Gemini API | Google AI for Developers, accessed September 1, 2025, https://ai.google.dev/aistudio
27. Google AI Studio, accessed September 1, 2025, https://aistudio.google.com/
28. Google AI Studio quickstart - Gemini API, accessed September 1, 2025, https://ai.google.dev/gemini-api/docs/ai-studio-quickstart
29. Google AI Studio for Beginners - YouTube, accessed September 1, 2025, https://www.youtube.com/watch?v=IHOJUJjZbzc
30. OpenRouter API Reference | Complete API Documentation ..., accessed September 1, 2025, https://openrouter.ai/docs/api-reference/overview
31. Completion | OpenRouter | Documentation, accessed September 1, 2025, https://openrouter.ai/docs/api-reference/completion
32. Summarizing Text Using Hugging Face's BART Model - DEV Community, accessed September 1, 2025, https://dev.to/dm8ry/summarizing-text-using-hugging-faces-bart-model-14p5
33. How to Build A Text Summarizer Using Huggingface Transformers - freeCodeCamp, accessed September 1, 2025, https://www.freecodecamp.org/news/how-to-build-a-text-summarizer-using-huggingface-transformers/
34. Pipelines - Hugging Face, accessed September 1, 2025, https://huggingface.co/docs/transformers/main_classes/pipelines
35. How to Run LLMs Locally with Ollama - Medium, accessed September 1, 2025, https://medium.com/cyberark-engineering/how-to-run-llms-locally-with-ollama-cb00fa55d5de
36. Running LLM Locally: A Beginner's Guide to Using Ollama | by Arun Patidar | Medium, accessed September 1, 2025, https://medium.com/@arunpatidar26/running-llm-locally-a-beginners-guide-to-using-ollama-8ea296747505
37. ollama/ollama: Get up and running with OpenAI gpt-oss ... - GitHub, accessed September 1, 2025, https://github.com/ollama/ollama
38. Learn Ollama in 15 Minutes - Run LLM Models Locally for FREE - YouTube, accessed September 1, 2025, https://www.youtube.com/watch?v=UtSSMs6ObqY
39. usememos/memos: A modern, open-source, self-hosted knowledge management and note-taking platform designed for privacy-conscious users and organizations. - GitHub, accessed September 1, 2025, https://github.com/usememos/memos
40. siyuan-note/siyuan: A privacy-first, self-hosted, fully open source personal knowledge management software, written in typescript and golang. - GitHub, accessed September 1, 2025, https://github.com/siyuan-note/siyuan
41. Best Open Source Personal Knowledge ... - OpenAlternative, accessed September 1, 2025, https://openalternative.co/categories/personal-knowledge-management-pkm/using/rust
42. Modular: A Fast, Scalable Gen AI Inference Platform, accessed September 1, 2025, https://www.modular.com/
43. Modular Documentation | Modular, accessed September 1, 2025, https://docs.modular.com/
44. Get started with Mojo - Modular docs, accessed September 1, 2025, https://docs.modular.com/mojo/manual/get-started/
45. The Modular Platform (includes MAX & Mojo) - GitHub, accessed September 1, 2025, https://github.com/modular/modular

Methodology

Projects, Areas, Resources, Archive Architecture

We will use the P.A.R.A. method (Projects, Areas, Resources, Archive) as a conceptual guide to organize the top-level chapters and sections within this mdBook's src directory as the foundational information architecture for your mdBook project. In contrast to a freeform approach OR generally adaptible mdBook approach that fits appropriately to the software being documented and implemented simultaneously, this mdBook is somewhat self-referential in terms of developing a PKE, thus following the PARA structured, hierarchical approach from the outset makes sense for developing a PARA-influence PKE.

In general, an issue-driven approach will be followed as we progress working through the daily modules in this mdBook's PKE development process, using the Zettelkasten concept of atomic notes. Each new issue that arises will be given it's own self-contained piece of research or issue#.md page. At first the issue#.md page will be in the 1.Projects folder until they are dispatched or dispositioned appropriately within the book's structure, all will be linked hierarchically by the SUMMARY.md file.

The 1.Projects folder will be the landing place for new issues and thereafter for short-term, less than one week efforts which are currently underway and should be regarded as under HEAVY construction. Issues that take on a larger life as much larger, ongoing effort will go to the 2.Areas folder. Issues that are developed and completed will go to he 3.Resources folder. Issues that are dismissed, after even a minor expenditure of dev effort, will go to the 4.Archive folder.

The 2.Areas folder will be for longer-term development and ongoing efforts that will stay open, perhaps indefinitely as perhaps usable, but under ongoing development. Areas that are developed for some time and eventually completed will go to he 3.Resources folder.

The 3.Resources folder will be for usable references and material that's that have been either curated or developed and although curation might continue to add things, these items should be regarded as stable enough to be considered usable, as good as complete. In some cases, a Project or Area might graduate to being in its own development repository, but page linking to that effort will be maintained in the Resources folder.

The 4.Archive folder will be for things that in the back Area 51 parking lot and might still be valuable for informational purposes, but are basically not something anyone should use.

Knowledge Management For PrePrints

The contemporary academic landscape is defined by an unprecedented acceleration in the dissemination of scientific knowledge, driven largely by the proliferation of scholarly pre-print archives such as arXiv, bioRxiv, and medRxiv.1 This paradigm shift presents a fundamental duality for the modern researcher: the "Velocity vs. Veracity" problem. On one hand, pre-prints offer immediate access to cutting-edge findings, dramatically shortening the cycle from discovery to communication and enabling researchers to build upon new work months or even years before formal publication.2 This velocity was instrumental during the COVID-19 pandemic, where rapid data sharing was paramount.2 On the other hand, this speed comes at the cost of the traditional gatekeeping function of peer review. Pre-prints are, by definition, preliminary reports that have not been certified by this critical process, introducing a significant risk of engaging with work that may be flawed, misinterpreted, or ultimately unpublishable.2

This deluge of unevaluated information threatens to transform from a professional opportunity into a state of chronic information exhaustion.8 The challenge for today's researcher is to develop a systematic methodology that transcends passive consumption and information triage. A strategic response is required to move beyond the mere management of information overload and toward the active, deliberate construction of a unique and valuable body of knowledge—an intellectual asset. This is the core promise of "Building a Second Brain," a methodology for creating an external, digital repository for one's ideas, insights, and learnings.9 Such a system allows the biological brain to be freed from the burden of perfect recall, enabling it to focus on its highest-value functions: imagination, synthesis, and creation.9

This report argues that by systematically integrating Tiago Forte's 'Building a Second Brain' (BASB) methodology with a modern, local-first technical stack and a deliberate strategy for public engagement, a researcher can construct not just a personal knowledge repository, but a powerful engine for accelerating research, generating novel insights, and building a distinguished professional brand. The user's query for such a system is not merely a request for productivity enhancement; it reflects a sophisticated understanding of the current academic environment. It recognizes that the rise of pre-prints shifts the burden of quality assessment onto the individual, while the digital landscape simultaneously opens new avenues for establishing professional reputation outside of traditional metrics. The proposed system is therefore an integrated strategy to thrive in this new paradigm: it internalizes the review process, accelerates personal learning cycles, and strategically leverages the resulting intellectual output for public credibility and collaborative advancement.

BASB and the Pre-print Ecosystem

Chapter 1: Architecting the Second Brain for Scholarly Inquiry

1.1 The CODE Framework in a Research Context

The Building a Second Brain methodology is built upon a four-step process known as CODE: Capture, Organize, Distill, and Express.9 While these principles are universally applicable, their implementation within a scholarly research context requires specific adaptation to address the unique challenges and workflows of academic inquiry.

Capture: Building a Systematic Intake Funnel

The first step, Capture, involves saving information that resonates with the researcher. In the context of pre-print investigation, this moves beyond haphazardly downloading PDFs. It necessitates the creation of systematic, semi-automated pipelines for monitoring the flow of new literature. This can be achieved by leveraging the programmatic access points provided by major archives. For instance, a researcher can set up RSS feeds for specific subject categories (e.g., "bioRxiv Biophysics") or for custom keyword and author searches.11 More advanced systems can directly query the APIs of services like arXiv to programmatically retrieve metadata for newly posted articles that match complex criteria.14

The guiding principle for capture, however, is not comprehensiveness but "resonance".9 The researcher should be selective, capturing only those pre-prints that are genuinely inspiring, surprising, useful, or directly personal to their ongoing work.10 This selective intake is crucial for preventing the Second Brain from becoming a "digital junkyard," ensuring that the time of one's future self is respected.10 Each captured item is a potential building block for future creative work, and its selection should be a conscious, intuitive act.10

Organize: The PARA Method for Action-Oriented Research

Once captured, information must be organized. The BASB system employs the PARA method, which stands for Projects, Areas, Resources, and Archive.9 The central innovation of PARA is its departure from traditional, topic-based filing systems (e.g., folders for "Genetics," "Immunology," "Statistics"). Instead, it organizes information based on its actionability, creating a dynamic system geared toward execution.15

This philosophical shift is particularly potent in an academic setting, where the tendency to collect information endlessly can stifle progress. A paper is not filed based on what it is about, but on how it will be used.

• Projects: These are the most actionable items. A project is a series of tasks aimed at a specific outcome with a deadline.10 For a researcher, this translates to concrete endeavors such as "Literature Review for Grant X," "Manuscript on Topic Y," "Conference Presentation Z," or "Preparing for comprehensive exams." A captured pre-print directly relevant to one of these efforts is filed in the corresponding project folder.
• Areas: These are long-term areas of responsibility that require constant upkeep but have no fixed end date.10 Examples include "My Research Field (e.g., Computational Neuroscience)," "Lab Management," "Teaching Duties (e.g., BIOL-101)," and "Professional Development." An interesting pre-print that broadens one's general expertise but isn't for a specific project would be filed under the relevant Area.
• Resources: This is a catch-all for topics of interest that are not related to an active Project or Area.10 This is where a researcher might store information on a new statistical method, a paper from a tangential field that sparked an idea, or notes on the history of science. It is a repository for potential future utility.
• Archive: This folder holds all inactive items from the other three categories.9 When a project is completed or an area of responsibility becomes dormant, its associated materials are moved to the Archive, keeping the active workspace clean and focused while preserving the information for future reference.

By prioritizing organization by actionability, the PARA method ensures that the most relevant information for current work is always the most accessible, reducing friction and promoting consistent forward momentum.

Distill: Progressive Summarization of Scholarly Work

The Distill step is where the true value of the Second Brain is created. It is the process of extracting the essential essence of captured information, making it more discoverable and useful for the future.10 The primary technique for this is "Progressive Summarization." When applied to a scholarly pre-print, this involves creating a multi-layered summary within an atomic note.

1. Layer 1: The initial note is created, containing the full abstract, key metadata (authors, title, DOI, link), and any passages highlighted during the first reading.
2. Layer 2: On a second pass, the researcher reviews the note and bolds the most important sentences and phrases within the highlighted passages.
3. Layer 3: On a subsequent review, the researcher reads only the bolded text and highlights the most critical points within that selection.
4. Layer 4: Finally, the researcher synthesizes the highlighted points into a one- or two-sentence executive summary in their own words at the top of the note.

Each time a note is revisited, it is enriched and made more concise, leaving behind a more valuable asset for the future.10 This layered approach allows the researcher to engage with the material at the appropriate level of depth—from a quick glance at the executive summary to a deep dive into the original highlighted text—on demand.

Express: The Recombination and Creation of New Knowledge

The final step, Express, is the output stage. It is where the captured, organized, and distilled building blocks are used to create new work.9 This is not a separate activity but the natural culmination of the preceding steps. With a growing collection of distilled, atomic notes, the process of writing a paper, preparing a presentation, or drafting a grant proposal shifts from a daunting task of starting from a blank page to a more manageable process of assembling and connecting pre-existing components.8 The Express stage is the ultimate purpose of the Second Brain: to consistently turn information consumed into creative output and concrete results.9 This report will further expand this concept to include public-facing expressions designed for professional brand management, such as blog posts, social media threads, and collaborative reviews.

1.2 The Atomic Note as the Quantum of Knowledge

The fundamental unit of this entire system is the Markdown-based atomic note. The principle of atomicity dictates that each note should contain a single, discrete idea, concept, finding, or critique derived from a source.10 For a pre-print, this means that instead of creating one monolithic note for the entire paper, the researcher creates multiple smaller notes. One note might capture the central hypothesis, another might detail a specific methodological innovation, a third could critique the statistical analysis, and a fourth might summarize a key result from Figure 3.

Each atomic note is a self-contained, reusable "building block" of knowledge.10 It must be enriched with metadata to ensure its context is preserved: the source (pre-print DOI, authors, title), relevant tags (e.g.,

#methodology, #topic-X, #critique), and, crucially, links to other related atomic notes within the system. This practice of interlinking transforms a simple collection of notes into a dense, navigable network of ideas, enabling the discovery of unexpected connections across different papers, disciplines, and time periods.10 This networked structure is the foundation for generating novel insights and hypotheses, which is a core function of advanced scholarly work.

Chapter 2: The Technical Substrate - Leveraging Rust, Markdown, and Git

The choice of technology for a Second Brain is not a trivial implementation detail; it is a philosophical commitment to a set of principles. While the BASB methodology is officially tool-agnostic, the user's specification of a stack comprising Markdown, a Rust-based static site generator (SSG), and Git reflects a deliberate choice for durability, performance, data sovereignty, and transparency.8 This toolchain, common in the world of professional open-source software development, treats the personal knowledge base as a serious, long-term project to be managed with professional-grade tools.

2.1 Why Markdown? The Principle of Plain Text

Markdown is a lightweight markup language for creating formatted text using a plain-text editor. Its selection as the format for atomic notes is foundational. The primary advantage of plain text is its longevity and portability. Unlike proprietary file formats (.docx, .pages, .one), Markdown files are not tied to any specific application or company. They are human-readable, can be opened and edited by countless applications on any operating system, and will remain accessible decades from now. This ensures that the intellectual asset being built is future-proof and free from vendor lock-in, giving the researcher complete ownership and control over their knowledge base in perpetuity.

2.2 Why a Rust-Based Static Site Generator? Performance, Sovereignty, and Durability

The user's preference for a Rust-based tool like mdBook points to a desire for a local-first, high-performance system. Static site generators like mdBook and Zola take a collection of plain text files (in this case, Markdown notes) and compile them into a set of simple, static HTML files.17 This approach stands in stark contrast to complex, database-driven, cloud-based platforms like Notion or the commercial version of GitBook.19

The advantages of this architecture are manifold:

• Performance: Rust-based SSGs are exceptionally fast. A typical site can be built in under a second, providing an instantaneous, frictionless experience for the user.17
• Data Sovereignty: The entire knowledge base consists of plain text files in a folder on the user's local machine. There is no reliance on a third-party server, no risk of a service shutting down, and no privacy concerns associated with storing sensitive intellectual work on a corporate cloud.19 The system is offline-first by design.
• Durability and Simplicity: The output is a set of static HTML files. This is the simplest, most robust form of web content, requiring no database or complex server-side processing to serve. It is highly secure, infinitely scalable, and can be hosted for free or at very low cost on numerous platforms.17
• Structure: mdBook, in particular, is designed to create book-like structures from Markdown files.18 This is an ideal paradigm for organizing complex research topics, allowing a researcher to structure their knowledge into coherent chapters and sections, complete with a table of contents and navigation.

2.3 Why Git? Versioning Knowledge and Enabling Collaboration

Integrating Git, a distributed version control system, elevates the PKM system from a simple collection of files to a robust, versioned project. Traditionally used for managing source code, Git is perfectly suited for tracking the evolution of intellectual work.22

By initializing a Git repository in the root directory of the Second Brain, the researcher gains several powerful capabilities:

• Complete History: Every change, addition, or deletion of a note is recorded as a "commit." This creates an indelible history of the knowledge base's evolution, allowing the researcher to see how their understanding of a topic has changed over time.
• Reversibility: Mistakes can be easily undone. If a set of notes is edited in a way that proves unhelpful, the researcher can revert the repository to any previous state, ensuring that no work is ever truly lost.22
• Atomic Changes: Git encourages the practice of making small, logical commits, which aligns perfectly with the principle of atomic notes. Each new idea or analysis can be committed with a descriptive message, creating a clear and understandable log of intellectual progress.24
• Branching: Git's branching capabilities are central to enabling collaborative workflows. A baseline workflow for a personal system would involve a main branch, representing the stable, "published" state of the knowledge base, and temporary feature branches for drafting new notes or synthesizing ideas.24 This isolates work-in-progress from the clean main branch, providing a structured environment for development that forms the basis for the advanced collaborative models discussed in Part II.

This technical substrate—Markdown for content, a Rust SSG for presentation, and Git for versioning—creates a powerful, sovereign, and durable foundation for a researcher's Second Brain. It is a system built not for ephemeral convenience, but for the long-term cultivation of a life's work.

Part II: Five Models for a Pre-print Investigation System

Introduction to Part II and Comparative Table

The foundational frameworks of Building a Second Brain and a robust technical stack provide the "what" and the "how" of a personal knowledge management system. This section addresses the "why"—the strategic purpose. The following five models represent distinct, actionable strategies for applying this system to the investigation of scholarly pre-prints. They are not mutually exclusive but represent a spectrum of approaches, each balancing the depth of private analysis with the breadth of public outreach and collaboration. A researcher might adopt one model for a specific project, or evolve from one to another over the course of their career.

To provide a strategic overview and guide the selection process, the models are first presented in a comparative table. This allows for a high-level assessment of each model's primary goal, methodological focus, collaborative intensity, technical complexity, and ideal user profile, enabling a researcher to identify the approach most aligned with their immediate needs and long-term professional objectives.

Table 1: Comparison of Pre-print Investigation Models

Chapter 3: The "Pre-print Digest" Model: Automated Curation and Public Dissemination

3.1 Concept

This model positions the researcher as a trusted curator and signal-booster for their specific field. The core activity is the systematic scanning of pre-print archives to identify the most significant, interesting, or impactful new papers. The primary output is a regular publication—such as a weekly or bi-weekly "digest"—that summarizes these findings and provides brief, insightful commentary. The goal is to build a reputation as a knowledgeable and reliable source, attracting a broad audience of peers and establishing a strong professional brand through consistent, high-value curation.

3.2 BASB Workflow

The workflow for the Pre-print Digest model is optimized for speed and consistency, emphasizing automation in the initial stages to allow the researcher to focus their limited time on the high-value tasks of selection and commentary.

• Capture: This stage is heavily automated to create a wide funnel of potentially relevant papers. The researcher would write simple scripts (e.g., in Python or Rust) to query the APIs of arXiv, bioRxiv, and other relevant servers on a daily basis for pre-prints matching a predefined set of keywords, authors, or subject categories.14 Concurrently, they would subscribe to RSS feeds from these archives and from journal alerts, using an RSS aggregator like Feedly to centralize the incoming stream.12 The metadata for each captured pre-print (title, authors, abstract, DOI) is automatically formatted into a new Markdown file and placed in a dedicated "Triage" folder within the
  Resources section of the Second Brain.
• Organize/Distill: The researcher dedicates a specific time block each week to process the "Triage" folder. This involves quickly scanning the titles and abstracts of the captured papers. Those deemed most interesting are moved from the generic Resources/Triage folder into a time-bound Project folder, such as Projects/Digest-Week-34-2025. For each of these selected papers, the researcher performs a rapid distillation, creating a single atomic note. This note does not require deep, multi-layered summarization; instead, it focuses on a concise, one-paragraph summary of the key finding and a crucial "Why it matters" sentence that provides the researcher's unique insight or context.
• Express: At the end of the weekly cycle, the distilled summaries from the project folder are compiled into a single, longer Markdown document. This document is structured with clear headings for each paper. The mdBook tool is then used to render this Markdown file, along with any previous digests, into a clean, professional, and easily navigable website. Each digest becomes a new "chapter" in the public-facing knowledge base.

3.3 Social Outreach and Collaboration

The social component of this model is primarily about public broadcast and brand building. Once the new digest is published to the mdBook site, the URL is shared widely across relevant professional networks.

• Dissemination: A link to the digest is posted on social media platforms like X, often accompanied by a thread that highlights the most exciting paper from that week's collection. The link can also be shared on platforms like Hacker News, relevant subreddits, or academic mailing lists to reach a broader audience.
• Ambient Collaboration: Collaboration in this model is ambient and indirect. It occurs through the public feedback received on these platforms—replies, quote tweets, comments, and discussions. This feedback serves as a valuable signal, indicating which papers are generating the most interest or controversy in the community. This public response is, in itself, a form of information that can be captured back into the Second Brain. For example, a particularly insightful critique from another researcher in a reply can be saved as a new atomic note and linked to the original pre-print summary, enriching the knowledge base. This creates a virtuous cycle where public expression leads to new private knowledge, which in turn improves future public expressions.

3.4 Technical Implementation

The technical setup for this model is straightforward, focusing on automation and simple deployment.

• Knowledge Base: mdBook serves as the core tool for managing the private notes and generating the public-facing digest website.18
• Automation Scripts: Python (with libraries like requests and feedparser) or Rust can be used to write the scripts that interact with pre-print APIs and parse RSS feeds. These scripts would be scheduled to run automatically (e.g., using a cron job).
• Deployment: A simple Continuous Integration/Continuous Deployment (CI/CD) pipeline, easily configured using GitHub Actions, can be set up. This pipeline automatically triggers whenever a new digest is committed and pushed to the main branch of the Git repository. The action will run the mdbook build command and deploy the resulting static HTML files to a hosting service like GitHub Pages, ensuring the public site is always up-to-date with minimal manual intervention.

Chapter 4: The "Deep Dive" Model: Focused Literature Review as a Living Project

4.1 Concept

This model is tailored for the intensive, focused effort of conducting a comprehensive literature review for a single, high-stakes academic project. This could be a thesis chapter, a grant proposal, a systematic review article, or preparation for a qualifying exam. In this model, the Second Brain is not a broad surveillance tool but a dedicated project space. The key innovation is transforming the traditionally private and static literature review process into a semi-public, dynamic, and "living" document that evolves over time and benefits from targeted collaborative feedback.

4.2 BASB Workflow

The workflow is characterized by manual curation and deep, iterative synthesis, reflecting the focused nature of the project.

• Capture: The capture process is manual, deliberate, and highly selective. Pre-prints are not captured automatically based on keywords but are actively sought out and chosen based on their direct and profound relevance to the specific research question at the heart of the project. The researcher is building a curated collection, not casting a wide net.
• Organize: All captured materials, notes, and drafts are consolidated within a single, dedicated Project folder, for example, Projects/NSF-Grant-2025-Background. This creates a self-contained intellectual workspace, ensuring all relevant information is co-located and easily accessible, minimizing context switching.
• Distill: This is the most critical activity in the Deep Dive model. Each selected pre-print is subjected to a rigorous and deep distillation process. The researcher creates a detailed set of atomic notes for each paper, covering its core hypothesis, experimental design, key results, statistical methods, stated limitations, and potential future directions. The technique of Progressive Summarization is applied meticulously to these notes over multiple sessions. Crucially, as the notes are distilled, they are heavily interlinked, creating a dense conceptual map of the literature within the project folder.
• Express: The distilled atomic notes are not left as isolated fragments. They are continuously synthesized into a coherent narrative within a single, long-form Markdown document, such as literature_review.md, which serves as the central "index" page for the project in the mdBook structure. This document is not a final product but a "living" synthesis that is updated in real-time as new pre-prints are analyzed and new connections between ideas are discovered. mdBook renders this document and all its supporting atomic notes into a navigable website, representing the current state of the researcher's understanding.

4.3 Social Outreach and Collaboration

The collaborative component of this model moves beyond public broadcast to a more intimate and structured form of feedback, leveraging modern web annotation technologies.

• Targeted Sharing: The URL for the "living" literature review, generated by mdBook, is shared not with the general public, but with a select group of trusted individuals—a thesis advisor, lab mates, a program officer, or a small circle of expert colleagues.
• Hypothesis Integration: The key collaborative tool is a web annotation service like Hypothesis.26 A small JavaScript snippet is added to the mdBook site's theme, enabling the Hypothesis sidebar on every page. This allows invited collaborators to engage with the text directly and asynchronously. They can highlight a specific sentence, paragraph, or figure and leave a comment, question, or critique anchored to that precise location.28
• Structured Dialogue: This process transforms the feedback loop. Instead of receiving a single email with high-level comments, the researcher receives a series of targeted, in-context annotations. A collaborator can question a specific interpretation of a result, suggest a missing citation directly where it should go, or debate a methodological critique right next to the text in question. This creates a rich, structured dialogue that is far more actionable and efficient than traditional feedback methods. It turns the solitary, often arduous process of a literature review into a dynamic, social, and iterative conversation, significantly improving the rigor and quality of the final scholarly product while strengthening the researcher's professional network.

4.4 Technical Implementation

The technical requirements for this model are relatively light, focusing on content structure and the integration of a third-party tool.

• Knowledge Base: mdBook is used to structure the project, with the main literature_review.md file serving as the core text and individual atomic notes for each paper organized as sub-pages.18
• Hosting: The static site generated by mdBook needs to be hosted on a simple web server to be accessible to collaborators. This can be easily accomplished using services like GitHub Pages, Netlify, or a personal server.
• Annotation Layer: The Hypothesis client is integrated by adding its universal embed script to the <head> section of the mdBook HTML template. This is a one-time modification to the theme that enables the annotation functionality across the entire site.27 The researcher can then create a private Hypothesis group and share the invitation link with their chosen collaborators, ensuring the conversation remains confidential.

Chapter 5: The "Heuristic Filter" Model: Quality Assessment and Collaborative Vetting

5.1 Concept

This model directly confronts the "veracity" problem inherent in the pre-print ecosystem.2 Its purpose is to move beyond passive consumption and establish a rigorous, transparent, and collaborative framework for assessing the quality and credibility of pre-print research. The researcher develops a personal or group-based set of heuristics for evaluation and then applies this framework in a structured process modeled directly on the peer review systems used in professional software development. The output is not just a summary of a paper, but a detailed, public, and citable assessment of its strengths and weaknesses. This model is ideal for researchers interested in meta-science, reproducibility, or for organizing a high-level journal club.

5.2 BASB Workflow

The workflow is methodical and structured, culminating in a formal assessment document that is itself subjected to peer review.

• Capture: A single pre-print is selected for a deep, critical vetting. The selection might be based on its potential impact, its controversial claims, or its relevance to an ongoing debate in the field.
• Organize: A new, dedicated Project is created for the assessment, for example, Projects/Vetting-Smith-et-al-2025.
• Distill: This stage involves a critical analysis of the pre-print through the lens of a predefined set of quality heuristics. These heuristics are themselves a key intellectual asset stored within the Resources section of the researcher's Second Brain. They are developed over time by synthesizing best practices from the literature on research assessment.7 Key heuristic categories include:
  • Author and Institutional Reputation: Examining the authors' track records and affiliations, while being mindful of potential biases against early-career researchers.4
  • Openness and Transparency Cues: Checking for the public availability of data, analysis code, and study pre-registration, which are strong signals of credibility.31
  • Methodological Soundness: Assessing whether the abstract formulates a clear hypothesis, if the experiments are well-designed to test it, and if appropriate controls are used.30
  • Independent Verification Cues: Evaluating the consistency of the findings with other independent sources in the literature.31
  • Citation Analysis: Looking at the cited references to ensure they are relevant and up-to-date.7
• Express: The researcher's analysis is not kept as a series of fragmented notes. It is synthesized and formally written up as a structured Markdown document, assessment.md, within the project folder. This document methodically steps through the heuristics, providing evidence-based commentary on how the pre-print performs on each dimension.

5.3 Social Outreach and Collaboration: The "Pull Request for Peer Review"

This model's core innovation is its collaborative component, which repurposes the robust and highly effective code review workflow from software engineering for academic peer review.32 This "Pull Request (PR) for Peer Review" process takes place on a platform like GitHub.

• Step 1: The "Issue": The process begins by opening a new Issue in a dedicated GitHub repository. This issue serves as a public proposal to vet a specific pre-print, allowing for initial high-level discussion and for others to signal their interest in participating.
• Step 2: The "Branch": The primary researcher creates a new Git branch locally, named something like review/smith-et-al-2025. On this branch, they add their drafted assessment.md file. This isolates the work-in-progress from the main, published body of assessments.24
• Step 3: The "Pull Request": The researcher pushes the branch to GitHub and opens a Pull Request. A PR is a formal request to merge the changes from their review branch into the main branch of the repository. In the PR description, they provide a summary of their assessment and explicitly request reviews from two or three trusted colleagues by @-mentioning their GitHub usernames.32
• Step 4: The "Review": The invited collaborators receive a notification and can now review the assessment within the GitHub web interface. This is a powerful, structured environment for feedback. They can view the "diff," which highlights every addition and change. They can leave comments directly on specific lines of the assessment.md file, asking for clarification, suggesting alternative phrasing, or challenging a particular interpretation. This creates an asynchronous, threaded conversation anchored precisely to the text being reviewed.32
• Step 5: The "Merge": The primary researcher incorporates the feedback, pushing new commits to the branch which automatically update the PR. Once all collaborators have approved the changes and a consensus is reached, the Pull Request is "merged." This action incorporates the finalized assessment.md into the main branch, where it becomes a permanent part of the public knowledge base.

This workflow transforms peer review from an opaque, private process into a transparent, collaborative, and educational one. The entire history of the discussion is preserved, and the final product is a community-vetted piece of scholarship.

5.4 Technical Implementation

This is the most technically intensive model, requiring the tight integration of several tools. The following table outlines the configuration.

Table 2: Toolchain Configuration for the Heuristic Filter Model

Chapter 6: The "Emergent Synthesis" Model: Zettelkasten for Novel Hypothesis Generation

6.1 Concept

This model is optimized for creativity, serendipity, and the generation of novel research hypotheses. It draws inspiration from the Zettelkasten (slip-box) method, treating the Second Brain not as an organized library of papers, but as a dynamic, interconnected network of individual ideas. The primary goal is to foster surprising connections between concepts, often from disparate fields, that can spark new lines of inquiry. This approach is less about systematically covering a field and more about cultivating a rich intellectual environment from which original thought can emerge organically.

6.2 BASB Workflow

The workflow prioritizes breadth of input and density of connections over hierarchical organization.

• Capture: The capture process is broad, opportunistic, and interdisciplinary. The researcher makes a conscious effort to capture pre-prints and other materials from well outside their core Area of expertise. An immunologist might capture a pre-print from computer science on network theory, or a historian might save an article from quantitative biology. These diverse inputs are typically placed in the Resources folder, seeding the system with varied conceptual raw material.
• Organize/Distill: This is where the Zettelkasten philosophy is most apparent. The focus is on creating extremely atomic, single-idea notes. For each captured pre-print, the researcher breaks it down into its constituent conceptual parts, with each part becoming a separate Markdown file. The most critical activity during this stage is the creation of explicit, bi-directional links between notes. Using simple Markdown link syntax (e.g., ]), the researcher actively connects new ideas to existing ones in the system. A note on a new machine learning technique might be linked to a previous note on a biological problem it could potentially solve. This process, over time, creates a dense, non-hierarchical web of interconnected knowledge.10
• Express: The expression stage in this model is exploratory and generative. The researcher periodically and intentionally "gets lost" in their network of notes. They might start with one note and follow the chain of links, observing the path they take. The goal is to identify surprising adjacencies and emergent clusters of connected ideas. When a group of linked notes suggests a novel connection or a potential new hypothesis, the researcher creates a "Synthesis Note." This is a short, often speculative essay that articulates the emergent idea, explains the connection between the constituent notes, and outlines a potential research question.

6.3 Social Outreach and Collaboration

The social strategy for this model is to "think in public" and use external feedback as a catalyst for refining nascent ideas.

• Sharing Speculative Ideas: The Synthesis Notes, once drafted, are published on the mdBook site. These are not presented as finished research but as explorations in progress. They are then shared on platforms that encourage deep, thoughtful discussion, such as a personal research blog, a relevant Substack newsletter, or specialized academic forums.
• Conceptual Resonance Testing: The goal of sharing is not to claim a discovery but to test the conceptual resonance of the new idea. The researcher is effectively asking the community: "Is this an interesting line of thought? Has someone already explored this connection? What critical perspective or piece of literature am I missing?"
• Feedback as Fuel: The feedback received—whether it's supportive, critical, or points to related work—is immensely valuable. This external input is captured back into the Second Brain as new atomic notes, which are then linked to the original Synthesis Note and its sources. This creates a feedback loop where public discourse directly informs and refines the private network of ideas, helping to mature a speculative thought into a viable, well-grounded research hypothesis.

6.4 Technical Implementation

The technical setup is similar to other models but may benefit from customizations that enhance the visibility of the note network.

• Knowledge Base: mdBook provides the basic structure for publishing the notes.18 The organizational hierarchy of the
  SUMMARY.md file is less important here than the network of links within the notes themselves.
• Link Visualization: To better support the exploratory nature of this model, the mdBook theme can be customized. A common and highly effective customization is to add a "Backlinks" section to the bottom of each page. This section would be dynamically populated (using a small script during the build process) with a list of all other notes in the system that link to the current note. This makes the network bi-directionally navigable and greatly enhances the ability to discover connections.
• Organization: While PARA is still used for high-level organization, the primary structure of the knowledge base is emergent, defined by the dense web of inter-note links rather than a rigid folder hierarchy.

Chapter 7: The "Pedagogical Pathway" Model: Transforming Research into Educational Resources

7.1 Concept

This model is centered on the act of translation: transforming the dense, complex, and often jargon-laden research presented in pre-prints into clear, accessible, and effective educational materials. The primary user of this system is a researcher who is also an educator, mentor, or passionate science communicator. The goal is to leverage the Second Brain not only for personal understanding but also as a factory for producing high-quality teaching resources for students, junior colleagues, or even a scientifically curious lay audience. This process has a dual benefit: it creates a valuable public good and, in the process of teaching, deeply solidifies the researcher's own understanding of the material.

7.2 BASB Workflow

The workflow is structured around the pedagogical goal of clarification and simplification.

• Capture: The researcher selectively captures pre-prints that are seminal, represent a significant breakthrough, or introduce a complex new technique or concept to the field. The criteria for selection are not just research relevance but pedagogical potential.
• Organize: Each educational resource is treated as a distinct Project. For example, a project might be named Projects/Module-Explaining-AlphaFold or Projects/Tutorial-CRISPR-Basics.
• Distill: This is the core of the pedagogical model. The distillation process goes beyond mere summarization; it is an act of translation. The researcher breaks down the complex pre-print into its fundamental conceptual components. For each component, they create atomic notes focused on answering key pedagogical questions: What is the core idea in the simplest possible terms? What is a good analogy or metaphor for this concept? How can this be visualized? What prerequisite knowledge is required to understand this? The goal is to strip away the jargon and reveal the elegant underlying principles.
• Express: The distilled and translated concepts are reassembled into a coherent pedagogical narrative. This narrative is structured as a lesson, tutorial, or module within mdBook. It might include sections like "Background Concepts," "The Central Problem," "The Core Innovation," "A Step-by-Step Walkthrough," and "Why This is a Breakthrough." The book-like format of mdBook is perfectly suited for this, allowing the creation of a structured, multi-page educational resource with clear navigation.18

7.3 Social Outreach and Collaboration

The collaborative component of this model is a closed-loop feedback system designed to test and refine the educational materials with a target audience.

• Targeted Feedback Loop: Instead of broadcasting to the public, the mdBook-generated educational module is shared with a specific group of learners. This could be the students in a graduate seminar, members of a lab journal club, or a group of undergraduate researchers.
• Clarity Review: The learners are tasked with a specific mission: to review the material not for scientific accuracy (which is the researcher's responsibility) but for clarity. They are encouraged to identify any points of confusion, ambiguous explanations, or sections that are difficult to follow.
• Feedback Mechanisms: The feedback can be collected through various channels. A simple, low-tech solution is a shared Google Doc where learners can leave comments. A more structured approach would be to use the repository's GitHub Issues, where each point of confusion can be logged as a separate issue. The most integrated solution would be to use a web annotation tool like Hypothesis, allowing learners to ask questions and flag confusing sentences directly within the context of the lesson.26
• Symbiotic Relationship: This process creates a powerful symbiotic relationship. The learners gain access to educational materials on cutting-edge topics that are far more current than any textbook. The researcher, in turn, receives invaluable feedback that allows them to refine their explanations and improve the quality of the resource. This act of teaching and refining solidifies their own mastery of the subject and builds their reputation as both a leading expert and an effective and dedicated educator. The final, polished module becomes a lasting contribution to the field's educational commons.

7.4 Technical Implementation

The technical setup for this model is straightforward and leverages the inherent strengths of the chosen toolchain.

• Knowledge Base: mdBook is the ideal tool for this model. Its native ability to create a structured, book-like website with chapters and sub-chapters maps directly onto the structure of a course module or a multi-part tutorial.18
• Collaboration Tools: The choice of collaboration tool can be tailored to the technical comfort of the learner audience. It can range from simple, universal tools like email or shared documents to more integrated platforms like GitHub Issues or Hypothesis, which provide a more structured feedback environment.26 No complex custom development is required.

Conclusion: Integrating the Second Brain into the Scholarly Workflow

This report has detailed five distinct models for developing a Personal Knowledge Management system tailored to the unique demands of investigating scholarly pre-print archives. These models—The Pre-print Digest, The Deep Dive, The Heuristic Filter, The Emergent Synthesis, and The Pedagogical Pathway—are not merely theoretical constructs. They are a portfolio of practical, actionable strategies that can be adopted, adapted, or combined to suit the specific needs of a researcher at different stages of a project or career. From the broad surveillance required when entering a new field to the deep focus needed for a grant proposal, and from the creative exploration that sparks novel hypotheses to the structured collaboration that ensures rigor, these frameworks provide a comprehensive toolkit for the modern scholar.

The central argument woven through these models is that a well-designed Second Brain, built upon the principles of CODE and PARA and implemented with a durable, sovereign technical stack, transcends its function as a mere organizational tool. It is not a passive filing system for papers or a glorified to-do list. It is a strategic asset. By systematically capturing, organizing, and distilling knowledge, it accelerates the fundamental feedback loops of research: learning, synthesis, and creation. Furthermore, by integrating a deliberate "Express" layer for social outreach and collaboration, it provides a mechanism for systematically translating private intellectual labor into public reputation, professional impact, and meaningful contributions to the scientific community.

Looking ahead, the potential for these systems is vast. The integration of advanced AI tools for automated summarization, concept extraction, and semantic search will likely further enhance the capabilities of the Second Brain. These technologies could automate the initial layers of progressive summarization or suggest novel connections between notes, acting as an intellectual amplifier. This evolution will further blur the line between the researcher's biological "first brain" and their digital "second brain," creating a powerful human-machine partnership that augments and accelerates the entire process of scientific discovery. Ultimately, the commitment to building and maintaining such a system is a commitment to a more intentional, productive, and impactful scholarly life.

Works cited

1. arXiv.org e-Print archive, accessed September 7, 2025, https://arxiv.org/
2. Preprints - Open Access Network, accessed September 7, 2025, https://open-access.network/en/information/publishing/preprints
3. bioRxiv.org - the preprint server for Biology, accessed September 7, 2025, https://www.biorxiv.org/
4. Preprints in Academic Assessment | DORA, accessed September 7, 2025, https://sfdora.org/2021/08/30/preprints-in-academic-assessment/
5. The Pros and Cons of Preprints - MDPI Blog, accessed September 7, 2025, https://blog.mdpi.com/2023/03/27/preprints-pros-cons/
6. medRxiv.org - the preprint server for Health Sciences, accessed September 7, 2025, https://www.medrxiv.org/
7. How to Approach Preprints for Quality Science Reporting? - ENJOI, accessed September 7, 2025, https://enjoiscicomm.eu/how-to-approach-preprints-for-quality-science-reporting/
8. Building a Second Brain, accessed September 7, 2025, https://www.buildingasecondbrain.com/
9. Building a Second Brain: The Definitive Introductory Guide - Forte Labs, accessed September 7, 2025, https://fortelabs.com/blog/basboverview/
10. Build a second brain - Workflowy guide, accessed September 7, 2025, https://workflowy.com/systems/build-a-second-brain
11. RSS Feeds Instructions for Databases · Library "How To" Guides, accessed September 7, 2025, https://library.concordia.ca/help/using/rss/exporting.php
12. How to use RSS to follow the Scientific Literature - Fraser Lab, accessed September 7, 2025, https://fraserlab.com/philosophy/rss_how_to/
13. Subscribe to Preprint RSS Feeds - OSF Support, accessed September 7, 2025, https://help.osf.io/article/185-subscribe-to-preprint-rss-feeds
14. arXiv API Access - arXiv info - About arXiv, accessed September 7, 2025, https://info.arxiv.org/help/api/index.html
15. Organize Your Second Brain: Part 1 — How to Use the PARA Method - Web Highlights, accessed September 7, 2025, https://web-highlights.com/blog/master-your-second-brain-part-1-how-to-use-the-para-method/
16. Building a Second Brain Resource Guide, accessed September 7, 2025, https://www.buildingasecondbrain.com/resources
17. Zola, accessed September 7, 2025, https://www.getzola.org/
18. myles/awesome-static-generators: A curated list of static web site generators. - GitHub, accessed September 7, 2025, https://github.com/myles/awesome-static-generators
19. GitBook vs mdBook: Choosing the Best Documentation Tool | by AI Rabbit | Medium, accessed September 7, 2025, https://medium.com/@airabbitX/my-journey-with-gitbook-and-mdbook-navigating-documentation-tools-5d653f76d58f
20. Shokunin, the fastest Rust-based Static Site Generator (SSG), accessed September 7, 2025, https://shokunin.one/
21. Open source alternatives to Gitbook, accessed September 7, 2025, https://opensourcealternative.to/alternativesto/gitbook
22. gitworkflows Documentation - Git, accessed September 7, 2025, https://git-scm.com/docs/gitworkflows
23. Academic Benefits of Using git and GitHub - Walking Randomly, accessed September 7, 2025, https://walkingrandomly.com/?p=6653
24. Resources on how to effectively use GitHub as an academic team - Reddit, accessed September 7, 2025, https://www.reddit.com/r/github/comments/1lcmne6/resources_on_how_to_effectively_use_github_as_an/
25. Git Workflow | Atlassian Git Tutorial, accessed September 7, 2025, https://www.atlassian.com/git/tutorials/comparing-workflows
26. hypothesis | Learning Technology Help Desk at PCC - Portland Community College, accessed September 7, 2025, https://www.pcc.edu/help-desk/student/hypothes-is/
27. ETS - Hypothesis | myUSF, accessed September 7, 2025, https://myusf.usfca.edu/ets/educational-technologies/hypothesis
28. Hypothes.is – Information Technology Services - Carleton College, accessed September 7, 2025, https://www.carleton.edu/its/services/learning/hypothesis/
29. Collaborative Annotation Tools: Hypothesis & Perusall - Teaching Support and Innovation, accessed September 7, 2025, https://teaching.uoregon.edu/collaborative-annotation-tools-hypothesis-perusall
30. 6 Heuristics for Assessing the Quality of a Publication - Francesco Lelli, accessed September 7, 2025, https://francescolelli.info/thesis/6-heuristics-for-assessing-the-quality-of-a-publication/
31. Credibility of preprints: an interdisciplinary survey of researchers ..., accessed September 7, 2025, https://pmc.ncbi.nlm.nih.gov/articles/PMC7657885/
32. GitHub Code Review, accessed September 7, 2025, https://github.com/features/code-review
33. Hypothesis: A Social Annotation Tool for Your Carmen Course | ASC Office of Distance Education - The Ohio State University, accessed September 7, 2025, https://ascode.osu.edu/hypothesis-social-annotation-tool-your-carmen-course

Miscellaneous References

1. How to Increase Knowledge Productivity: Combine the Zettelkasten ..., accessed August 12, 2025, https://zettelkasten.de/posts/building-a-second-brain-and-zettelkasten/
2. My Personal Knowledge Management System As a Software ..., accessed August 12, 2025, https://thewordyhabitat.com/my-personal-knowledge-management-system/
3. Personal Knowledge Management (PKM) - Data Engineering Blog, accessed August 12, 2025, https://www.ssp.sh/brain/personal-knowledge-management-pkm/
4. Combine Your Second Brain with Zettelkasten - Sudo Science, accessed August 12, 2025, https://sudoscience.blog/2024/12/27/combine-your-second-brain-with-zettelkasten/
5. FOR COMPARISON with mdBook ... Obsidian - Sharpen your thinking, accessed August 12, 2025, https://obsidian.md/
6. FOR COMPARISON with mdBook... Developers - Obsidian Help, accessed August 12, 2025, https://help.obsidian.md/developers
7. FOR COMPARISON with mdBook ... Home - Developer Documentation - Obsidian, accessed August 12, 2025, https://docs.obsidian.md/Home
8. Managing my personal knowledge base · tkainrad, accessed August 12, 2025, https://tkainrad.dev/posts/managing-my-personal-knowledge-base/
9. Engineering - Notion, accessed August 12, 2025, https://www.notion.com/help/guides/category/engineering
10. Junior to senior: An action plan for engineering career success ..., accessed August 12, 2025, https://github.com/readme/guides/engineering-career-success
11. AswinBarath/AswinBarath: A quick bio about myself - GitHub, accessed August 12, 2025, https://github.com/AswinBarath/AswinBarath
12. What Is Hugging Face? | Coursera, accessed August 12, 2025, https://www.coursera.org/articles/what-is-hugging-face
13. Hugging Face : Revolutionizing AI Collaboration in the Machine Learning Community | by Yuvraj kakkar | Medium, accessed August 12, 2025, https://medium.com/@yuvrajkakkar1/hugging-face-revolutionizing-ai-collaboration-in-the-machine-learning-community-28d9c6e94ddb
14. "Operator-Based Machine Intelligence: A Hilbert Space Framework ..., accessed August 12, 2025, https://www.reddit.com/r/singularity/comments/1mkwxzk/operatorbased_machine_intelligence_a_hilbert/
15. [2505.23723] ML-Agent: Reinforcing LLM Agents for Autonomous Machine Learning Engineering - arXiv, accessed August 12, 2025, https://arxiv.org/abs/2505.23723
16. Getting Started with Papers With Code – IT Exams Training ..., accessed August 12, 2025, https://www.pass4sure.com/blog/getting-started-with-papers-with-code/
17. Wolfram Mathematica: Modern Technical Computing, accessed August 12, 2025, https://www.wolfram.com/mathematica/
18. Mathematica & Wolfram Language Tutorial: Fast Intro for Math Students, accessed August 12, 2025, https://www.wolfram.com/language/fast-introduction-for-math-students/en/
19. How to start a tech blog in 6 steps - Wix.com, accessed August 12, 2025, https://www.wix.com/blog/how-to-start-a-tech-blog
20. How to Start a Tech Blog: Easy Guide for Beginners - WPZOOM, accessed August 12, 2025, https://www.wpzoom.com/blog/how-to-start-tech-blog/
21. Networking for Engineers: 8 Strategies to Expand Your Professional ..., accessed August 12, 2025, https://staffing.trimech.com/networking-for-engineers-8-strategies-to-expand-your-professional-circle/
22. Mastering Networking as a Software Developer: Strategies for Success : r/software_soloprenures - Reddit, accessed August 12, 2025, https://www.reddit.com/r/software_soloprenures/comments/1m363gv/mastering_networking_as_a_software_developer/
23. The Software Developer's Guide to Networking - Simple Programmer, accessed August 12, 2025, https://simpleprogrammer.com/software-developers-networking/
24. Participating in Open Source Communities - Linux Foundation, accessed August 12, 2025, https://www.linuxfoundation.org/resources/open-source-guides/participating-in-open-source-communities
25. How To Grow Your Career With a Software Engineering Mentor - Springboard, accessed August 12, 2025, https://www.springboard.com/blog/software-engineering/software-engineer-mentor/
26. Where to Find a Software Engineer Mentor (and How to Benefit From Them) | HackerNoon, accessed August 12, 2025, https://hackernoon.com/where-to-find-a-software-engineer-mentor-and-how-to-benefit-from-them
27. Improve your open source development impact | TODO Group // Talk ..., accessed August 12, 2025, https://todogroup.org/resources/guides/improve-your-open-source-development-impact/
28. Self-Directed Learning: A Four-Step Process | Centre for Teaching ..., accessed August 12, 2025, https://uwaterloo.ca/centre-for-teaching-excellence/catalogs/tip-sheets/self-directed-learning-four-step-process
29. 25 New Technology Trends for 2025 - Simplilearn.com, accessed August 12, 2025, https://www.simplilearn.com/top-technology-trends-and-jobs-article
30. Emerging Technology Trends - J.P. Morgan, accessed August 12, 2025, https://www.jpmorgan.com/content/dam/jpmorgan/documents/technology/jpmc-emerging-technology-trends-report.pdf
31. 5 AI Trends Shaping Innovation and ROI in 2025 | Morgan Stanley, accessed August 12, 2025, https://www.morganstanley.com/insights/articles/ai-trends-reasoning-frontier-models-2025-tmt
32. Llamaindex RAG Tutorial | IBM, accessed August 12, 2025, https://www.ibm.com/think/tutorials/llamaindex-rag
33. Build Your First AI Application Using LlamaIndex! - DEV Community, accessed August 12, 2025, https://dev.to/pavanbelagatti/build-your-first-ai-application-using-llamaindex-1f9
34. LlamaIndex - LlamaIndex, accessed August 12, 2025, https://docs.llamaindex.ai/
35. Fine-Tuning LLMs: A Guide With Examples | DataCamp, accessed August 12, 2025, https://www.datacamp.com/tutorial/fine-tuning-large-language-models
36. The Ultimate Guide to LLM Fine Tuning: Best Practices & Tools - Lakera AI, accessed August 12, 2025, https://www.lakera.ai/blog/llm-fine-tuning-guide
37. Fine-tuning LLMs Guide | Unsloth Documentation, accessed August 12, 2025, https://docs.unsloth.ai/get-started/fine-tuning-llms-guide
38. Building AI Agents Using LangChain and OpenAI APIs: A Step-by ..., accessed August 12, 2025, https://sen-abby.medium.com/building-ai-agents-using-langchain-47ba4012a8a1
39. LangGraph - LangChain, accessed August 12, 2025, https://www.langchain.com/langgraph
40. Build an Agent - ️ LangChain, accessed August 12, 2025, https://python.langchain.com/docs/tutorials/agents/
41. With AI at the core, Heizen has a new model for software development at scale, accessed August 12, 2025, https://economictimes.indiatimes.com/small-biz/security-tech/technology/with-ai-at-the-core-heizen-has-a-new-model-for-software-development-at-scale/articleshow/123156453.cms
42. 10 Best AI code generators in 2025 [Free & Paid] - Pieces App, accessed August 12, 2025, https://pieces.app/blog/9-best-ai-code-generation-tools
43. Generative AI In Software Development Life Cycle (SDLC) - V2Soft, accessed August 12, 2025, https://www.v2soft.com/blogs/generative-ai-in-sdlc
44. How an AI-enabled software product development life cycle will fuel innovation - McKinsey, accessed August 12, 2025, https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/how-an-ai-enabled-software-product-development-life-cycle-will-fuel-innovation
45. Generative AI in SDLC: Can GenAI Be Utilized throughout the Software Development Life Cycle? - EPAM Startups & SMBs, accessed August 12, 2025, https://startups.epam.com/blog/generative-ai-in-sdlc
46. Future of Data Engineering: Trends for 2025 - Closeloop Technologies, accessed August 12, 2025, https://closeloop.com/blog/data-engineering-key-trends-to-watch/
47. Tutorial - MLflow, accessed August 12, 2025, https://www.mlflow.org/docs/2.7.1/tutorials-and-examples/tutorial.html
48. 10 MLOps Projects Ideas for Beginners to Practice in 2025 - ProjectPro, accessed August 12, 2025, https://www.projectpro.io/article/mlops-projects-ideas/486
49. Tutorials and Examples - MLflow, accessed August 12, 2025, https://mlflow.org/docs/latest/ml/tutorials-and-examples/
50. Your First MLflow Model: Complete Tutorial, accessed August 12, 2025, https://mlflow.org/docs/latest/ml/getting-started/logging-first-model/
51. End-to-End MLOps Pipeline: A Comprehensive Project ..., accessed August 12, 2025, https://www.geeksforgeeks.org/machine-learning/end-to-end-mlops-pipeline-a-comprehensive-project/
52. Snowflake Data Mesh: The Ultimate Setup Guide (2025) - Atlan, accessed August 12, 2025, https://atlan.com/snowflake-data-mesh-how-to-guide/
53. What Is Data Mesh? Complete Tutorial - Confluent Developer, accessed August 12, 2025, https://developer.confluent.io/courses/data-mesh/intro/
54. Data Mesh Implementation: Your Blueprint for a Successful Launch - Ascend.io, accessed August 12, 2025, https://www.ascend.io/blog/data-mesh-implementation-your-blueprint-for-a-successful-launch
55. Ten More Top Emerging Technologies In 2025 - Forrester, accessed August 12, 2025, https://www.forrester.com/report/ten-more-top-emerging-technologies-in-2025/RES183100
56. What Is Quantum Computing? | IBM, accessed August 12, 2025, https://www.ibm.com/think/topics/quantum-computing
57. Introduction to Qiskit | IBM Quantum Documentation, accessed August 12, 2025, https://quantum.cloud.ibm.com/docs/guides/
58. Quantum computing - Wikipedia, accessed August 12, 2025, https://en.wikipedia.org/wiki/Quantum_computing
59. Introduction to quantum computing, accessed August 12, 2025, https://thequantuminsider.com/introduction-to-quantum-computing/
60. Introduction to Qiskit | IBM Quantum Documentation, accessed August 12, 2025, https://quantum.cloud.ibm.com/docs/guides
61. How do people do Open Source Contributions ? : r/csharp - Reddit, accessed August 12, 2025, https://www.reddit.com/r/csharp/comments/1bxprbo/how_do_people_do_open_source_contributions/
62. Good First Issue: Make your first open-source contribution, accessed August 12, 2025, https://goodfirstissue.dev/
63. For Good First Issue | Make your next open-source contribution matter. - GitHub, accessed August 12, 2025, https://forgoodfirstissue.github.com/
64. MunGell/awesome-for-beginners: A list of awesome beginners-friendly projects. - GitHub, accessed August 12, 2025, https://github.com/MunGell/awesome-for-beginners
65. For Good First Issue: Introducing a new way to contribute - The GitHub Blog, accessed August 12, 2025, https://github.blog/open-source/social-impact/for-good-first-issue-introducing-a-new-way-to-contribute/
66. How to Contribute to Open Source, accessed August 12, 2025, https://opensource.guide/how-to-contribute/
67. Find Open Source Projects to Contribute: A Developer's Guide, accessed August 12, 2025, https://osssoftware.org/blog/find-open-source-projects-to-contribute-a-developers-guide/
68. A Software Developer's Guide to Writing - DEV Community, accessed August 12, 2025, https://dev.to/tyaga001/a-software-developers-guide-to-writing-bgj
69. Building an Online Presence In Tech 101 - SheCanCode, accessed August 12, 2025, https://shecancode.io/building-an-online-presence-in-tech-101/
70. How to write a coding tutorial | Yost's Posts, accessed August 12, 2025, https://www.ryanjyost.com/how-to-write-a-coding-tutorial/
71. Creating the Best Video Programming Tutorials | Vue Mastery, accessed August 12, 2025, https://www.vuemastery.com/blog/creating-the-best-video-programming-tutorials/
72. A tutorial on creating coding tutorials - LogRocket Blog, accessed August 12, 2025, https://blog.logrocket.com/a-tutorial-on-creating-front-end-tutorials-2b13d8e94df9/
73. How to Create a Technical Video Tutorial | Elastic Blog, accessed August 12, 2025, https://www.elastic.co/blog/elastic-contributor-program-how-to-create-a-video-tutorial
74. How to Make Engaging Programming Videos - Real Python, accessed August 12, 2025, https://realpython.com/how-to-make-programming-videos/
75. One-on-one mentorship with software engineers - CodePath, accessed August 12, 2025, https://www.codepath.org/career-services/mentorship
76. Find a Software Engineering mentor - MentorCruise, accessed August 12, 2025, https://mentorcruise.com/filter/softwareengineering/
77. Logseq vs. Obsidian: first impressions - Share & showcase, accessed August 13, 2025, https://forum.obsidian.md/t/logseq-vs-obsidian-first-impressions/56854
78. 6 ways Logseq is the perfect Obsidian alternative - XDA Developers, accessed August 13, 2025, https://www.xda-developers.com/ways-logseq-is-the-perfect-obsidian-alternative/
79. Electron vs Tauri - Coditation, accessed August 13, 2025, https://www.coditation.com/blog/electron-vs-tauri
80. Framework Wars: Tauri vs Electron vs Flutter vs React Native - Moon Technolabs, accessed August 13, 2025, https://www.moontechnolabs.com/blog/tauri-vs-electron-vs-flutter-vs-react-native/
81. Modular: A Fast, Scalable Gen AI Inference Platform, accessed August 13, 2025, https://www.modular.com/
82. MAX: AI Compute Platform - Modular, accessed August 13, 2025, https://www.modular.com/max
83. apache beam vs apache kafka: Which Tool is Better for Your Next Project? - ProjectPro, accessed August 13, 2025, https://www.projectpro.io/compare/apache-beam-vs-apache-kafka
84. Apache Beam over Apache Kafka Stream processing - Codemia, accessed August 13, 2025, https://codemia.io/knowledge-hub/path/apache_beam_over_apache_kafka_stream_processing
85. Apache Beam: Introduction to Batch and Stream Data Processing - Confluent, accessed August 13, 2025, https://www.confluent.io/learn/apache-beam/
86. Quantum Programming Languages: A Beginner's Guide for 2025 - BlueQubit, accessed August 13, 2025, https://www.bluequbit.io/quantum-programming-languages
87. What are the best-known quantum programming languages (e.g., Qiskit, Quipper, Cirq)?, accessed August 13, 2025, https://milvus.io/ai-quick-reference/what-are-the-bestknown-quantum-programming-languages-eg-qiskit-quipper-cirq
88. Hello Many Worlds in Seven Quantum Languages - IonQ, accessed August 13, 2025, https://ionq.com/docs/hello-many-worlds-seven-quantum-languages
89. Neuromorphic Hardware Guide, accessed August 13, 2025, https://open-neuromorphic.org/neuromorphic-computing/hardware/
90. Embedded Neuromorphic Computing Systems - MCSoC-2025, accessed August 13, 2025, https://mcsoc-forum.org/site/index.php/embedded-neuromorphic-computing-systems/
91. OpenBCI – Open-source EEG, accessed August 13, 2025, https://www.opensourceimaging.org/project/openbci/
92. Community Page Projects - OpenBCI Documentation, accessed August 13, 2025, https://docs.openbci.com/Examples/CommunityPageProjects/
93. Example Projects - OpenBCI Documentation, accessed August 13, 2025, https://docs.openbci.com/Examples/ExamplesLanding/
94. EEG Headsets and Software for Education - EMOTIV, accessed August 13, 2025, https://www.emotiv.com/pages/education
95. EEG Monitoring – EMOTIV, accessed August 13, 2025, https://www.emotiv.com/blogs/glossary/eeg-monitoring
96. EEG Headset - Emotiv, accessed August 13, 2025, https://www.emotiv.com/blogs/glossary/eeg-headset
97. Developing AR/VR/MR/XR Apps with WebXR, Unity & Unreal - Coursera, accessed August 13, 2025, https://www.coursera.org/learn/develop-augmented-virtual-mixed-extended-reality-applications-webxr-unity-unreal
98. WebXR Academy, accessed August 13, 2025, https://webxracademy.com/
99. Top VR Education Companies in 2025 - Axon Park, accessed August 13, 2025, https://www.axonpark.com/top-vr-education-companies-in-2025/
100. The Future of VR in Education: Immersive Learning Experiences, accessed August 13, 2025, https://www.immersivelearning.news/2025/06/19/the-future-of-vr-in-education-immersive-learning-experiences/
101. Streamlit vs FastAPI: Choosing the Right Tool for Deploying Your Machine Learning Model | by Pelumi Ogunlusi | Jul, 2025 | Medium, accessed August 13, 2025, https://medium.com/@samuelogunlusi07/streamlit-vs-fastapi-choosing-the-right-tool-for-deploying-your-machine-learning-model-1d16d427e130
102. Compare Streamlit vs. Tauri in 2025, accessed August 13, 2025, https://slashdot.org/software/comparison/Streamlit-vs-Tauri/
103. Monica: Personal CRM done right, accessed August 13, 2025, https://www.monicahq.com/
104. monicahq/monica: Personal CRM. Remember everything about your friends, family and business relationships. - GitHub, accessed August 13, 2025, https://github.com/monicahq/monica
105. rust-lang/mdBook: Create book from markdown files. Like Gitbook but implemented in Rust, accessed August 13, 2025, https://github.com/rust-lang/mdBook
106. Freelancer API for Developers, accessed August 13, 2025, https://developers.freelancer.com/
107. API Developer Freelance Jobs: Work Remote & Earn Online - Upwork, accessed August 13, 2025, https://www.upwork.com/freelance-jobs/api-development/
108. How to Start a Podcast: Step-by-Step Guide & Free Checklist - Riverside, accessed August 13, 2025, https://riverside.com/blog/how-to-start-a-podcast

Project Overview

This landing page will feature a list of ongoing PROJECTS. We will develop a template after we have experience with several examples.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The BASB method systematically manages information differently than just notetaking apps ... PROJECTS, have goals, reqmts and deadlines ... AREAS are about roles/responsibilities or obligations or capabilities that need to be earnestly developed ... RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... ARCHIVES, inactive matl from P A R that shouldn't be used, except for informational purposes.

GitHub Discussion, Issue, Project Functionality

We will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy.

Please understand the GitHub progression from ... Discussions ...to... Issue ...to... Project.

Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

On GitHub a Project is an adaptable spreadsheet, task-board, and road map that integrates with your issues and pull requests on GitHub to help you plan and track your work effectively. You can create and customize multiple views by filtering, sorting, grouping your issues and pull requests, visualize work with configurable charts, and add custom fields to track metadata specific to your team. Rather than enforcing a specific methodology, a project provides flexible features you can customize to your team’s needs and processes.

title: "Christian Spiritual Health" type: project tags: goals alias: ideation

Christian Spiritual Health

This Project was created on 2025 10 27.

Remember, minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking. If one wants to optimize the machine-readability for automating notes in the future, it's necessary to to get practice with using things like using note properties, templates, and graph visualization. As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it..

GitHub Functionality For Discussions, Issues, Projects

We will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy.

Please understand the GitHub progression from ... Discussions ...to... Issue ...to... Project.

Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

On GitHub a Project is an adaptable task-board or road map that integrates with your issues and pull requests on GitHub to help you plan and track your work effectively. You can create and customize multiple views by filtering, sorting, grouping your issues and pull requests, visualize work with configurable charts, and add custom fields to track metadata specific to your team. Rather than enforcing a specific methodology, a project provides flexible features you can customize to your team’s needs and processes.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs, not hard ultimatums, as Requirements and Deadlines are.

Requirements

MINIMAL VIABILITY requirements for Project completion and advancement to Areas.

Deadlines

Time DEADLINES, not goals, but a drop-dead dates after which we don't bother anymore.

title: "Strength Training" type: project tags: goals alias: ideation

Strength Training

Summary

This Project was created on 2025 10 27

Remember, minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking. If one wants to optimize the machine-readability for automating notes in the future, it's necessary to to get practice with using things like using note properties, templates, and graph visualization. As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it..

GitHub Functionality For Discussions, Issues, Projects

We will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy.

Please understand the GitHub progression from ... Discussions ...to... Issue ...to... Project.

Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

On GitHub a Project is an adaptable task-board or road map that integrates with your issues and pull requests on GitHub to help you plan and track your work effectively. You can create and customize multiple views by filtering, sorting, grouping your issues and pull requests, visualize work with configurable charts, and add custom fields to track metadata specific to your team. Rather than enforcing a specific methodology, a project provides flexible features you can customize to your team’s needs and processes.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: "Cardiovascular Training" type: project tags: goals alias: ideation

Cardiovascular Training

Summary

This Project was created on 2025 10 27

Remember, minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking. If one wants to optimize the machine-readability for automating notes in the future, it's necessary to to get practice with using things like using note properties, templates, and graph visualization. As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it..

GitHub Functionality For Discussions, Issues, Projects

We will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy.

Please understand the GitHub progression from ... Discussions ...to... Issue ...to... Project.

Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

On GitHub a Project is an adaptable task-board or road map that integrates with your issues and pull requests on GitHub to help you plan and track your work effectively. You can create and customize multiple views by filtering, sorting, grouping your issues and pull requests, visualize work with configurable charts, and add custom fields to track metadata specific to your team. Rather than enforcing a specific methodology, a project provides flexible features you can customize to your team’s needs and processes.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: Nutrition Gardening type: project tags: goals alias: ideation

src/1.Projects/staging/04NutritionGardening

Metadata

This Project was created on 2025 10 27 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: "Developing Intelligence" type: project tags: goals alias: ideation

Developing Intelligence

Metadata

This Project was created on 2025 10 27 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: Social Connection type: project tags: goals alias: ideation

Social Connection

Metadata

This Project was created on 2025 10 27 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: "Rest, Recovery, Readiness" type: project tags: goals alias: ideation

Rest, Recovery, Readiness

Metadata

This Project was created on 2025 10 27 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: "Stress Optimization" type: project tags: goals alias: ideation

Stress Optimization

Metadata

This Project was created on 2025 10 27 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: Hydration, Circulation, and Energy Flow type: project tags: goals alias: ideation

Hydration, Circulation, and Energy Flow

Metadata

This Project was created on 2025 10 27 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: "Mobility, Flexibility, Balance and Coordination" type: project tags: goals alias: ideation

Mobility, Flexibility, Balance and Coordination

Metadata

This Project was created on 2025 10 27 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: "Time Optimization, Prioritization" type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

Time Optimization, Prioritization

Metadata

This Project was created on 2025 10 27 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: "Portfolio Lifestyle" type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

Portfolio Lifestyle

Metadata

This Project was created on 2025 10 27 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: 'AR/VR, Virtual Workflows/Events" type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

AR/VR, Virtual Workflows/Events

Metadata

This Project was created on 2025 10 27 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: "Neurohacking, Cognitive Optimization, Neuromorphic Computing" type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

Neurohacking, Cognitive Optimization, Neuromorphic Computing

Metadata

This Project was created on 2025 10 27 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: "Quantum Technologies" type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

Quantum Technologies

Metadata

This Project was created on 2025 10 27 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: "Martial Arts" type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

Martial Arts

Metadata

This Project was created on 2025 10 27 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: "Self Defense Weapons and Systems" type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

Self Defense Weapons and Systems

Metadata

This Project was created on 2025 10 27 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: "Robotic and AI Tech Education" type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

Robotic and AI Tech Education

Metadata

This Project was created on 2025 10 27 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: "Theses and Dissertations" type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

Theses and Dissertations

Metadata

This Project was created on 2025 10 27 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: "arXiv AI" type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

arXiv AI

Metadata

This Project was created on 2025 10 27 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: arXiv CS, not AI type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

arXiv CS, not AI

Metadata

This Project was created on 2025 10 28 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: arXiv Economics type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

arXiv Economics

Metadata

This Project was created on 2025 10 28 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: arXiv EE, Systems Science type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

arXiv EE, Systems Science

Metadata

This Project was created on 2025 10 28 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: arXiv Mathematics type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

arXiv Mathematics

Metadata

This Project was created on 2025 10 28 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: arXiv Physics type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

arXiv Physics

Metadata

This Project was created on 2025 10 28 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: arXiv Quantitative Biology type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

arXiv Quantitative Biology

Metadata

This Project was created on 2025 10 28 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: arXiv Quantitative Finance type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

arXiv Quantitative Finance

Metadata

This Project was created on 2025 10 28 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: arXiv Statistics type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

arXiv Statistics

Metadata

This Project was created on 2025 10 28 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: Domain Specific Logic type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

Domain Specific Logic

Metadata

This Project was created on 2025 10 31 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: bioRxiv Animal Behavior and Cognition type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

bioRxiv Animal Behavior and Cognition

Metadata

This Project was created on 2025 10 28 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: bioRxiv Biochemistry type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

bioRxiv Biochemistry

Metadata

This Project was created on 2025 10 28 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: bioRxiv Bioengineering type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

bioRxiv Bioengineering

Metadata

This Project was created on 2025 10 28 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: bioRxiv Bioinformatics type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

bioRxiv Bioinformatics

Metadata

This Project was created on 2025 10 28 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: bioRxiv Biophysics type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

bioRxiv Biophysics

Metadata

This Project was created on 2025 10 28 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: bioRxiv Cancer Biology type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

bioRxiv Cancer Biology

Metadata

This Project was created on 2025 10 28 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: bioRxiv Cell Biology type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

bioRxiv Cell Biology

Metadata

This Project was created on 2025 10 28 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: bioRxiv Developmental Biology type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

bioRxiv Developmental Biology

Metadata

This Project was created on 2025 10 28 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: biorxiv Ecology type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

biorxiv Ecology

Metadata

This Project was created on 2025 10 28 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: biorxiv Extremophile Engineering type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

biorxiv Extremophile Engineering

Metadata

This Project was created on 2025 10 28 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: biorxiv Gene Editing, Cell Therapies and Genetic Engineering type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

biorxiv Gene Editing, Cell Therapies and Genetic Engineering

Metadata

This Project was created on 2025 10 28 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: biorxiv Evolutionary Biology type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

biorxiv Evolutionary Biology

Metadata

This Project was created on 2025 10 28 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: biorxiv Genetics type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

biorxiv Genetics

Metadata

This Project was created on 2025 10 28 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: biorxiv Genomics type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

biorxiv Genomics

Metadata

This Project was created on 2025 10 30 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: biorxiv Immunology type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

biorxiv Immunology

Metadata

This Project was created on 2025 10 30 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: biorxiv Microbiology type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

biorxiv Microbiology

Metadata

This Project was created on 2025 10 30 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: biorxiv Molecular Biology type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

biorxiv Molecular Biology

Metadata

This Project was created on 2025 10 30 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: biorxiv Neuroscience type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

biorxiv Neuroscience

Metadata

This Project was created on 2025 10 30 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: biorxiv Paleontology type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

biorxiv Paleontology

Metadata

This Project was created on 2025 10 30 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: biorxiv Pathology type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

biorxiv Pathology

Metadata

This Project was created on 2025 10 30 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: biorxiv Pharmacology and Toxicology type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

biorxiv Pharmacology and Toxicology

Metadata

This Project was created on 2025 10 30 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: biorxiv Physiology type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

biorxiv Physiology

Metadata

This Project was created on 2025 10 30 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: biorxiv Plant Biology type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

biorxiv Plant Biology

Metadata

This Project was created on 2025 10 30 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: biorxiv Scientific Communication / Education Research and Technology type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

biorxiv Scientific Communication / Education Research and Technology

Metadata

This Project was created on 2025 10 30 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: biorxiv Synthetic Biology type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

biorxiv Synthetic Biology

Metadata

This Project was created on 2025 10 30 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: biorxiv Systems Biology type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

biorxiv Systems Biology

Metadata

This Project was created on 2025 10 30 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: biorxiv Zoology type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

biorxiv Zoology

Metadata

This Project was created on 2025 10 30 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: ChemRxiv Agriculture and Food Chemistry type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

ChemRxiv Agriculture and Food Chemistry

Metadata

This Project was created on 2025 10 30 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: ChemRxiv Analytical Chemistry type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

ChemRxiv Analytical Chemistry

Metadata

This Project was created on 2025 10 30 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: ChemRxiv Biological and Medicinal Chemistry type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

ChemRxiv Biological and Medicinal Chemistry

Metadata

This Project was created on 2025 10 30 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: ChemRxiv Catalysis type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

ChemRxiv Catalysis

Metadata

This Project was created on 2025 10 30 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: ChemRxiv Chemical Education type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

ChemRxiv Chemical Education

Metadata

This Project was created on 2025 10 31 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: ChemRxiv Chemical Education type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

ChemRxiv Chemical Education

Metadata

This Project was created on 2025 10 31 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: ChemRxiv Earth, Space, and Environmental Chemistry type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

ChemRxiv Earth, Space, and Environmental Chemistry

Metadata

This Project was created on 2025 10 31 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: ChemRxiv Energy type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

ChemRxiv Energy

Metadata

This Project was created on 2025 10 31 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: ChemRxiv Inorganic Chemistry type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

ChemRxiv Inorganic Chemistry

Metadata

This Project was created on 2025 10 31 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: ChemRxiv Materials Science type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

ChemRxiv Materials Science

Metadata

This Project was created on 2025 10 31 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: ChemRxiv Nanoscience type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

ChemRxiv Nanoscience

Metadata

This Project was created on 2025 10 31 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: ChemRxiv Organic Chemistry type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

ChemRxiv Organic Chemistry

Metadata

This Project was created on 2025 10 31 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: ChemRxiv Organometallic Chemistry type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

ChemRxiv Organometallic Chemistry

Metadata

This Project was created on 2025 10 31 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: ChemRxiv Physical Chemistry type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

ChemRxiv Physical Chemistry

Metadata

This Project was created on 2025 10 31 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: ChemRxiv Polymer Science type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

ChemRxiv Polymer Science

Metadata

This Project was created on 2025 10 31 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: ChemRxiv Theoretical and Computational Chemistry type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

ChemRxiv Theoretical and Computational Chemistry

Metadata

This Project was created on 2025 10 31 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: medRxiv type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

medRxiv

Metadata

This Project was created on 2025 10 31 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: SocArXiv, SSRN or Similar type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

SocArXiv, SSRN or Similar

Metadata

This Project was created on 2025 10 31 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: PsyArXiv type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

PsyArXiv

Metadata

This Project was created on 2025 10 31 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects

In addition to VS Code and the Foam extension, we will rely upon the GitHub Discussion and Issue functionality, BEFORE graduating something to "Project" status ... when something becomes a Project on GitHub, it will simultaneously become a PROJECT in our P.A.R.A. hierarchy. Please abide by the GitHub progression from ... Discussions ...to... Issue ...to... Project:

• Discussions are mainly for just discussing something, to clarify terminology or ask questions or for just generally speculative thinking out loud.

• Issues are for things that somebody really needs to look into and possibly turn into more of a Project.

• Projects are adaptable task-boards or roadmaps that integrates with your issues and pull requests on GitHub to help you plan, visualize and track your work effectively.

P.A.R.A. Project Mgmt Review

The holy grail of the PKM project investigations or emergent phenomena is possibly something like emergent neuromorphology or sparking something embryonic morphogenesis in complex organisms like humans which starts with cells migrate via gradients; then adhesion sorts types and shapes organs such that incredibly complex physiological lifeforms elegantly emerges from relatively simple cues. The patterns or behaviors we seek from new research discoveries would noteworthy when are not explicitly programmed or predictable from the properties of individual components, but rather emerge as a result of their interactions ... such that a better, more complete understanding of emergence OR new components might be useful.

A Project is the start of a bigger development commitment and the basis of the P.A.R.A. method of the Building a Second Brain (BASB) methodology. The P.A.R.A. methodological architecture systematically manages information differently than mere notetaking apps:

• PROJECTS, have SMART goals, minimal completion reqmts and deadlines
• AREAS are about roles/responsibilities or obligations or capabilities ... Areas are the preferred destination for Projects.
• RESOURCES, mostly finished AREAS, but also ongoing interests, assets, future inspiration, may req continual maintenance and refactoring but, for now, are backburnerable ... Resources are the preferred destination for Areas.
• ARCHIVES, inactive matl from P A R that is kept around only for informational purposes.

Project Goals

Specific, Measurable, Aggressive, Realistic, Timebound objectives ... these are GOALs for stretching what we hope to achieve, rather than non-negotiable, minimal-acceptable ultimatums as Requirements and Deadlines are.

Project Requirements

We aggressively manage the scope of Projects for MINIMAL VIABILITY requirements for completion and handed-off advancement to the Areas section..

Project Deadlines

Time DEADLINES are not goals, but rather firm drop-dead dates after which we don't bother anymore.

title: EarthArXiv type: project tags: goals, requirements, deadlines alias: ideation, planned, in-process, completed, reviewed

EarthArXiv

Metadata

This Project was created on 2025 10 31 with the template located at .foam/templates/projects.md in an attempt to optimize the machine-readability for automating notes in the future, using note properties, templates, and graph visualization.

As with most tools, Foam is like a bathtub -- what you get out of it depends on what you put into it each day.. Minimizing context-switching is a matter of daily repitition and discipline built upon reviewing and better using essential VS Code keybindings. This even goes beyond the Foam extension's VS Code shortcuts for note-taking.

GitHub Functionality For Discussions, Issues, Projects